[concurrency-interest] Fences.keepAlive

Gregg Wonderly gergg at cox.net
Wed Jan 14 11:05:54 EST 2009


Doug Lea wrote:
> 
> [Same cross-post conventions as the last one.]
> 
> As another make-good for a long-standing problem, the
> Fences class should include what amounts to a fence with
> respect to the garbage collector. This addresses a problem that
> Hans Boehm has written and talked about for years.
> (Google finds his JavaOne 2005 slides at
> http://gceclub.sun.com.cn/java_one_online/2005/TS-3281/ts-3281.pdf)
> 
> This turns out not to be expressible using other kinds of
> fences. It tells the compiler/runtime that the ref in
> question must be considered as being used even if nothing in
> the program itself indicates it. (The suggested JVM implementation
> of this is an "opaque fence" that bypasses/evades any
> mechanics or optimizations that might cause ref to vanish.)

After reading Hans paper from J1, I'm not sure I understand why this fence is 
needed.  Phantom reference solves the issues that I see with trying to "clean 
up" due to GC finalization happening.  The ReferenceTracker class that I posted 
here works to defeat all the issues that Hans brought up I believe.

Would it make sense to include something like ReferenceTracker in lieu of this 
kind of fence?  Perhaps I'm not understanding how the problem Hans discusses 
turns out to be an issue for developers or JVM implementations?  Is it a problem 
if you use PhantomReference instead of finalize()?

Gregg Wonderly


More information about the Concurrency-interest mailing list