[concurrency-interest] Atomicity of clearing of WeakReferences

Karnok Dávid karnok at sztaki.hu
Wed Jul 15 02:14:57 EDT 2009

I would say, if a weak reference is immutable, then there should be only one
instance around each individual contained object and the JVM should
automagically return that on a new WeakReference(obj) call. I guess a

factory pattern would have helped here more, e.g.
WeakReference.to(myObject). What do you think?



Karnok Dávid 

Research Assistant 

Engineering and Management Intelligence laboratory, Computer and Automation
Research Institute, Hungarian Academy of Sciences

 <http://www.sztaki.hu> http://www.sztaki.hu 

 <http://www.emi.sztaki.hu> http://www.emi.sztaki.hu


From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Dhanji R.
Sent: Wednesday, July 15, 2009 2:06 AM
To: Bob Lee
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Atomicity of clearing of WeakReferences



On Wed, Jul 15, 2009 at 9:46 AM, Bob Lee <crazybob at crazybob.org> wrote:

On Tue, Jul 14, 2009 at 4:28 PM, Joseph Seigh <jseigh_cp00 at xemaps.com>

If you have more than one WeakReference pointing to an object, and the
object no longer has any normal references, are the references cleared
atomically?   Or can you bring an object back into play by getting a
reference to it from a WeakReference that hasn't been cleared after seeing a
different WeakReference to it get cleared?

The spec says they are cleared atomically:

"Suppose that the garbage collector determines at a certain point in time
that an object is weakly reachable
achability> . At that time it will atomically clear all weak references to
that object and all weak references to any other weakly-reachable objects
from which that object is reachable through a chain of strong and soft
references. At the same time it will declare all of the formerly
weakly-reachable objects to be finalizable."

This would be easy to support in a stop-the-world collector, but it seems to
me that it could overly restrict concurrent collectors. Thoughts?


Concurrent collectors also pause all application threads during marking.
They just have shorter pauses as there are more marks done and the sweeping
is concurrent.


So it should not affect atomic clearing?





__________ ESET NOD32 Antivirus - Vírusdefiníciós adatbázis: 4238 (20090713)


Az üzenetet az ESET NOD32 Antivirus ellenõrizte.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090715/3cb0690b/attachment.html>

More information about the Concurrency-interest mailing list