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 have noted concerns about optimisations that might be excluded by such a
model. However, I would much rather have to deal with a performance problem
in an application, than have a mission critical system that collapses in a
heap (usually when heavily loaded) at unexpected moments due to a subtle
finalization flaw that no one can see in the code. I can probably buy a new
processor next month that gives me back all the performance I lost anyway.
If this model prohibits tail call optimisations, then so be it. I'll live
without them. If hanging onto the _this_ pointer runs you out of registers,
then you'll have to use memory. To bad. Ditto other optimisations. If I
were that concerned about performance, I wouldn't be writing the stuff in
Java anyway.
How much would the performance hit be for real Java applications?
On the subject of synchronization in connection with finalizers, I think I
would have difficulty getting the developers to understand the need for
that. For all the claims that it's about concurrency, the typical
programmer's view is going to be that since the object is finalizer
reachable, there can't possibly be any other thread accessing it, and so
the need for synchronization is far from evident.
It's really another case of asking the developers to handle something we've
put into the too hard basket and thrown over the fence. They're likely to
take one sniff and throw it right back.
As I understand the issue, the problem is that the lack of synchronization
means that there has been no memory barrier between the last method call on
the object and the invocation of the finalizer. Well, let's put one there.
Isn't it true that most garbage collectors force all threads through a
barrier anyway before they do the collection? In that case, the job is
already done.
I have a similar issue with Thread.join(), and the
Thread.sleep()/Thread.interrupt() pair. There are probably barriers here
anyway, but they're not explicit. As things stand, it looks as if a
developer should use explicit synchronization before sharing data in these
situations.
I would like to take the really hardline with memory order too, but at the
moment I can't see how that can be achieved in a way that doesn't put an
upper limit on the achievable performance. I'm not worried about wasting
some performance, but bringing progress to a permanent halt might be too
much of a price to pay.
Sylvia.
BTW, does anyone optimise out my empty synchronized block?
-------------------------------
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