RE: JavaMemoryModel: Final and Volatile array classes

From: Miles Sabin (
Date: Thu Mar 23 2000 - 10:30:35 EST

Doug Lea wrote,
> I could not send varr to a method expecting an int[], at
> least not without giving up volatile properties. So I'd need
> to reparameterize (and in some cases therefore duplicate, so
> could apply to both flavors) methods like:
> void reverse(int[] a);
> void reverse((volatile int)[] va);
> Plus rules for casts in both directions. And so on.
> The net effect on programmers is just not all that different
> than the special-classes proposal.

I agree that exploiting a language change wouldn't always be
simply a matter of sprinkling a few extra volatiles and finals
around. But I'm not convinced that it wouldn't quite often be
that simple. I'm sure that there's a large body of code out
there which wouldn't be hurt by volatility being lost for the
duration of a method call; and I can't see existing code being
hurt by a similar gain of volatiltity.

Hmm ... perhaps implicit conversions from (volatile int)[] to
int[] _are_ too dangerous, but from int[] to (volatile int)[]
should be fine so long as you don't want to insist on complete
protection from aliasing problems. But that means existing code
could be fixed, at least temporarily, without duplication.

> The net effect on the language is a new, fairly large set of
> rules that would take a while to iron out and would prbably
> meet a lot of resistence.

That's fair comment. But then, assuming that some progress is
being made on the genericity proposal, there are going to be
significant type-related language changes happening anyway.

Having said that, generics would make your proposal quite a bit
more palatable. I'd be quite keen to see some collaboration
between that JSR and a future memory model one.



Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England

------------------------------- JavaMemoryModel mailing list -

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