Sorry to whine, but I still find it distressing that the only
operation Java programmers can use to release new objects is not
automatically treated as a release operation. (Yet the release
operation relied upon by VM implementors is.)
As a reminder, Josh's proposal comes from the opposite direction:
* First-publication is a release
* It is illegal for other threads to use unreleased fields
* Minimizing barriers is left to clever compilers and VMs.
I do understand (at least some of) the massive difficulties
encountered in optimizing away barriers. But I am sure that machines
will get these right more often than I can. (In the same way even
simple optimizers can kill more index bounds checks, and with higher
reliability than I can.)
But a compromise might be reached from this direction as well. Rather
than introducing a keyord that provides initialization safety as an
option, how about introducing a qualifier for fields that disables
this safety-first default. We could even hijack `transient'!
Programmers who want better performance can the take the extra steps
to learn to use it.
> > From: owner-javamemorymodel@cs.umd.edu
> > [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Dan Scales
> > 5) One way to support the initialize-once idiom so that it is
> > reasonably efficient on all types of machines is to add a new
> > keyword 'sync' that qualifies variables. Any read of a 'sync'
> > variable acts as an acquire and any write of a 'sync' variable
> > acts as a release. If a reference to a newly constructed object
> > is stored in a sync variable, then other processors reading the
> > variable will be guaranteed to see the correct contents of the new
> > object.
>
> Instead of adding a new keyword we could simply hijack 'volatile' to mean
> this. After all our general rule for accessing mutable fields is that it
Some people might remember this as John Rose's suggested hack a few
years ago. The usage consequences don't seem right to me though: The
only responsible way to use it is to use it everywhere. For example,
for the char-array ref of a String. In which case you hurt
performance on all accesses when all you really need is to protect
first-release.
Initialization issues aside, it is probably a good idea to change
semantics of volatile in this way. I could then kill passages in
CPJ/2e that warn people that accessing a volatile array variable does
not automatically provide access to its elements. Which no matter how
many times you tell people (including myself), is just too easy to
escape even careful review and cause errors. (As a couple of people
on this list will attest :-)
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/ ------------------------------- This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.To send a message to the list, email JavaMemoryModel@cs.umd.edu To send a request to the list, email majordomo@cs.umd.edu and put your request in the body of the message (use the request "help" for help). For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:16 EDT