Re: JavaMemoryModel: Finalization idioms

From: Hans Boehm (
Date: Sun May 01 2005 - 01:50:53 EDT

Thanks. More details follow.

On Sat, 30 Apr 2005, Jeremy Manson wrote:

> Boehm, Hans wrote:
> > Opinions?
> Here are some of my thoughts:
> 1) You could consider showing them the code for keepAlive, and telling
> them to use it. You don't even necessarily have to go into that much
> detail about how it works. They will then litter their code with very
> sensible looking calls to their individual keepAlive() methods, which is
> what their code would look like if we actually gave them keepAlive().
How do you implement keepAlive in Java code? You really want to
ensure visibility of writes (to outside the object) from ordinary
methods to finalizer code. I think that means that without the
implicit volatile read in the finalizer, you need an explicit
read or other synchronization action in the finalizer, too.
> 2) Why is the volatile option uglier than enforcing mutual exclusion
> where none is necessary? Is it because volatiles are necessarily ugly
> (the answer to this may be yes)? Isn't it uglier to have empty sync
> blocks cluttering your code?
You usually end up with an otherwise unnecessary volatile field,
which either costs you space or potential contention (if you make
its static). And you end up with assignments everywhere you would
have the empty sync blocks.
> 3) If you do choose option number three (or even if you don't), don't
> forget to mention that finalizers can be run concurrently, so they may
> have to synchronize their finalizers anyway.
That's the preceding addition to a running example in the talk.
The problem is that synchronization usually protects a static data
structure, and hence the lock doesn't keep the object live.
> 4) We still should have some sort of built in keepAlive method. And a
> way of initializing final fields sensibly. This is neither here nor
> there, really :)

Agreed. But we're in much better shape than before JSR133.
And for now we need some (stop-gap?) programming guidelines.

JavaMemoryModel mailing list -

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