[gclist] Question from a newbie

[Boehm, Hans]

> -----Original Message-----
> From: David Chase [mailto:chase@world.std.com]
> Sent: Sunday, May 11, 2003 7:09 PM
> To: gclist@lists.iecc.com
> Subject: Re: [gclist] Question from a newbie 
> 
> 
> At 05:42 PM 5/11/2003 -0400, I wrote:
> >The specification, unfortunately, is a little vague in places,
> >but I can tell you that in practice real programs don't
> >appear to depend on these various optimizations not being
> >done.
> 
> It occurred to me that the phrase "real programs" is a little
> vague.  It includes a variety of programs that use AWT, various
> J2EE servers and applications running within them, all the code
> in Sun's libraries exercised by all these programs, and numerous
> other applications.  The sort of things that they DO depend on
> include (or DID include):
> ...

[David and I had a separate off-line discussion ...]

Having spent some time looking at the finalization issue specifically , my conclusions are:

1) Much (in my experience most) code involving finalizers in Java is clearly broken.
(Given a strict interpretation of the current Java spec, all of it is broken, but that's fixable.)
In many cases, there is no clean and obvious way to fix the Java spec to make it correct.
In particular, it is almost always (perhaps always) necessary to synchronize a finalizer
and any possible last regular action on the object.  A lot of code doesn't.

2) You are unlikely to see an actual failure from any of this with current JVMs.  But
depending on the JVM, this is related to things like many JVMs collecting only at
safe points, many of us using X86 machines, which tend to push arguments on
the memory stack, etc.  Even if a failure is possible with the generated code, it usually
depends on unlikely GC timing.

Thus, in spite of the fact that Java software using finalizers continues to work nearly all
of the time, optimization or not, I think we're on thin ice here, and some of this
needs to be fixed.  We'll be moving to 64-bit architectures sooner or later, and none
of them are as register-poor as the X86.  Not all JVMs use safe points.  And certainly
you don't want to make safepoints part of the language semantics.

Of course, these issues aren't Java specific.  And it's not the fault of the optimizers;
they're clearly consistent with the spec.

There are a lot more details about the finalization issues in my POPL paper at

http://portal.acm.org/citation.cfm?doid=604131.604153

or

http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html

Hans