[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