Bill wrote:
> At 11:26 AM -0400 7/24/99, Doug Lea wrote:
> >
> > * Disallow escape of `this' before assignment to finals in constructors.
> >
>
> That is going to be very tricky to require. The problem is that your
> super constructor could allow 'this' to escape (by storing it).
Ugh/thanks.
A purely local compile-time check could guarantee at most that clients
that do not do downcasts cannot see uninitialized values. While this
is probably too weak to embed in language rules, the check would still
catch most cases where programmers published by mistake.
>
> To disallow escape of `this' before assignment to finals in
> constructors, you would either need to assign to finals before the
> call to super, or just totally disallow the escape of this from a
> constructor.
>
> While these might be good language features, it isn't at all backward
> compatible with existing Java code.
Right. I should have stayed away from mentioning classloading-time
checks.
Maybe I have the wrong attitude about this, but blank finals (and
inner classes and inline array initialization) aren't even in the JLS,
so tunings that might possibly make existing code fail to recompile
might be tolerable, but that changes that make them fail to load/run
aren't, especially since there were no previous guarantees about
memory effects etc in the first place. (I think inner class specs are
being currently revamped for future JLS. Presumably people will face
similar issues.)
> No. volatile is always superfluous for single threaded code
> (excepting memory mapped IO). I consider the intuitive meaning of
> "volatile" to mean:
> "I'm going to have an unsynchronized data race on this variable"
Hmm. My take is that volatile is solely a performance tuning tool:
Volatile is useful when you want to improve performance over
synchronizing access to a single field, applying when
* the field need not obey any invariants wrt others
* all writes to the field do not depend on its initial value.
* no writer ever writes a (momentarily) illegal value wrt intended semantics.
* the actions of readers do not depend on values of other
non-volatile fields
Examples include setting `done' flags, and recording sensor inputs.
The range of applicability is very narrow, but on some systems anyway,
it provides enough of a performance improvement that it is worth
twisting around code to exploit it inside bottelnecks.
> If we decide that a data race allowing a thread to see the
> "non-final" value of a final variable is a safety violation, then
> "final volatile" is superfluous. But if we decide that it is simply
> surprising (and perhaps likely to result in an error (e.g., a
> NullPointerException)), then we can decide to allow the user to see
> surprising results arising from his undeclared unsynchronized data
> race. Declaring it as volatile would make it a declared data race, so
> in that case we should probably require that the thread see the
> correct final value.
Sorry to be so dense about this, and to keep asking/commenting about
variations on it, but are there any interesting cases where
programmers would NOT replace current `final' declarations with
`volatile final'? In which case, why introduce it?
-- 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:17 EDT