RE: JavaMemoryModel: Final and Volatile array classes

From: Miles Sabin (msabin@cromwellmedia.co.uk)
Date: Thu Mar 23 2000 - 08:25:46 EST


Doug Lea wrote,
> Nearly all of the decisions that I (and probably you) don't
> want to have to make about final and volatile semantics
> surround the fact that one cannot now declare that elements
> of an array are final or volatile.
>
> This underlying problem could be fixed. But there are lots of
> arguments for not changing the language syntax to do so.
> Instead, I'd like to get on the table a proposal to create
> simple array-holding classes with special semantics.

Hopefully I'm not retreading arguments that have been done to
death on this list already.

I think there are pragmatic arguments which favour a language
change. First, modifying array-using code to instead use
VolatileXXXArrays is very intrusive. It's not just declarations
which have to be changed, it's all uses as well. Worse, in the
case of VolatileObjectArray many (most?) accesses would have to
be followed by a cast, on pain of a severe weakening of type-
safety. Unless working programmers really understand the
rationale for these changes they simply won't happen. The type-
safety issue might even have the unfortunate consequence of
disuading the most conscientious developers from doing the
Right Thing.

Second, there are a several places in the standard APIs where
arrays are used as lightweight factories. And unless things
have changed recently, this mechanism is recommended for use in
GJ to work around the it's lack of support for type-
parametrized object creation. If GJ forms the basis of the
design for parameterized types in a future Java (which seems
likely) there might be scope for conflicts.

Third, many working programmers simply will not believe that
their compilers will be able to do a good enough job of
inlining these methods calls. And if they're that worried about
performance it's quite likely that they're the ones coding
data-races: ie. the very consituency the VolatileXXXArray
proposal is aimed at is likely to be the most resistant it.

Cheers,

Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT