> -----Original Message-----
> From: Sylvia Else [mailto:sylviae@optushome.com.au]
>
> I fully support David Holmes' desire for compliance with a simple and
> understandable model of reachability. Essentially the
> optimizers role is to
> speed up the program without changing the semantics of
> correct programs. I
> don't want 'correct' to have such a subtle meaning that I have to get
> senior developers to do code reviews of every piece of work,
> with a listing
> in one hand and copies of the JLS and VM spec in the other.
>
I personally think that it would be a good idea to have senior developers do code
reviews for any code that either
a) Uses shared variables without synchronization, or
b) Uses finalization.
Neither should be done casually or frequently. (This list probably isn't exhaustive.)
Given the cost of full sequential consistency on most common hardware,
and the fact that unsynchronized shared variables are tricky even then,
I don't see how we could possibly make (a) easy.
If someone wants to argue that we can make (b) easy, I would love to see
a complete proposal. I think what has been discussed so far has several
problems:
1) It doesn't address the interactions with the memory model. If a
reference becomes dead at a specific point, e.g. at the end of the
declaring block, is "deadness" ordered with respect to other memory
accesses? If so, I think we need lots of barriers. If not, I think
the property isn't useful.
2) It's easy to introduce either weird irregularities or large
optimization penalties. Keeping "this" live might be OK. But
what if the last access to an object is in a static method to
which the object was passed as a parameter? What if it was
instead passed to a method of a different class? What if the object
is only referenced by a compiler temporary?
In my opinion, even if you managed to deal with all of these issues,
finalization still won't be easy since Java doesn't use ordered
finalization. If I'm a malicious client of your trusted class,
I can always get your finalizer to run concurrently with any of
your public methods. (Define another class with a finalizer that
refers to your object. Have my finalizer call your public method
in a loop until your finalizer runs. If there is a single finalization
thread, instead notify a regular thread to run the loop instead.)
And for every object referenced from a finalizer, you have to consider
the possibility that that object may have been finalized first.
I think it's possible to design a language in which finalization
would be much easier to use. But I'm not sure it would look a lot
like Java, or be consistent with the performance-usability tradeoffs
made elsewhere for Java. I'm not sure I'd be willing to throw away
that much performance to improve the semantics of a (hopefully) rarely
used feature. I would however like to get to the point where finalization
is usable by "senior developers".
I agree that in principle ease of programming typically outweighs
performance considerations. But in practice, language constraints
that impose large performance penalties without an immediately visible
benefit (e.g. the original Java floating point constraints) seem to mostly
get ignored by many implementors. I would really like to avoid getting
into that sort of situation.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT