[concurrency-interest] Fences.keepAlive

Matthias Ernst matthias at mernst.org
Wed Jan 14 13:17:11 EST 2009


On Wed, Jan 14, 2009 at 6:45 PM, Gregg Wonderly <gregg at cytetech.com> wrote:
> Can someone elaborate why the reference on the stack as a local value would
> not maintain a reference that lasted until the method exits?

Why would it? The object will no longer be used in the rest of the
method, why keep it alive?
So it is totally conceivable that the stackmap will no longer announce
this reference to the GC even if the value is still somewhere on the
stack or in a register.
I would even expect a clever optimizer to reuse the storage, so the
reference is "physically" gone.

It is also important to note that this topic is very related to the
memory model. The last point of reachability is just as much subject
to reordering/inlining optimizations and an object can end up being
collected even earlier than its last lexical reference.

Matthias

> I can see
>
> work() {
>        someUnManagedMethod( new Foo() );
>        ...
>        ...
>        ...
>        someOtherUnmanagedMethodWhichErradicatesFooReference();
> }
>
> being a little more obvious of an issue, and I guess its interfaces to
> JNI/native things that make this issue boil up to be visible?  Are there any
> cases where 100% Java code has this lost reference problem?  It seems not to
> me...
>
> Gregg Wonderly
>
> Matthias Ernst wrote:
>>
>> For reference, this is the equivalent in .NET:
>>
>> http://msdn.microsoft.com/en-us/library/system.gc.keepalive.aspx
>>
>>
>> On Wed, Jan 14, 2009 at 3:20 PM, Doug Lea <dl at cs.oswego.edu> 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.)
>>>
>>> Here's a first pass at javadoc/spec. Comments welcome.
>>>
>>>   /**
>>>    * Ensures that object referenced by the given reference is not
>>>    * reclaimable by garbage collection until after the invocation of
>>>    * this method. Among other related usages, this method may assist
>>>    * efforts to ensure that finalization associated with garbage
>>>    * collection does not occur before the finalized resources have
>>>    * even been established.  For example:
>>>    *
>>>    * <pre>
>>>    * class Resource {
>>>    *   static NativeResource nativeResourceArray = ...
>>>    *   static void registerInArray(int index) { ... }
>>>    *   int myIndex;
>>>    *   void setup() {
>>>    *      int i = myIndex;
>>>    *      registerInArray(i);
>>>    *      keepAlive(this);
>>>    *   }
>>>    *   Resource(...) {
>>>    *     myIndex = ...
>>>    *     setup();
>>>    *   }
>>>    * }
>>>    * </pre>
>>>    * @param ref the reference
>>>    */
>>>   public static <T> keepAlive(T ref);
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>


More information about the Concurrency-interest mailing list