Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > System.gc not enqueuing cleared WeakReferences

Reply
Thread Tools

System.gc not enqueuing cleared WeakReferences

 
 
Ian Pilcher
Guest
Posts: n/a
 
      01-18-2006
I have (finally!) reached the point of writing unit tests for my
WeakIdentityHashMap, and testing for proper removal of otherwise
unreachable keys is proving to be quite a problem.

Currently, my tests assume that a call to System.gc() will ensure that
all cleared WeakReferences will be enqueued, but this does not appear to
be the case.

Does this sound credible? (This is Sun's 1.5.0_06 JVM on Linux, BTW.)

If System.gc() won't do the trick, does anyone know of anyway to ensure
that all WeakReferences are actually enqueued?

TIA

--
================================================== ======================
Ian Pilcher http://www.velocityreviews.com/forums/(E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
 
 
 
Ian Pilcher
Guest
Posts: n/a
 
      01-18-2006
Thomas Hawtin wrote:
> References are not guaranteed to be enqueued immediately after they are
> cleared. In Sun's implementation all references get passed through a
> maximum priority thread before becoming enqueued. A further complication
> with UNIX threading is that, unless the process is run as root, the
> thread priority is apparently ignored.


I was afraid of that. I know that we're not supposed to depend on the
behavior of the garbage collector, but this non-determinism makes
testing things a real PITA.

> I have a suspicion that References objects that are dropped themselves
> or only referenceable via WeakReferences do not get enqueued. That was
> on my list of things to check...


The doc is pretty explicit that you are correct.

--
================================================== ======================
Ian Pilcher (E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
 
 
 
Thomas Hawtin
Guest
Posts: n/a
 
      01-18-2006
Ian Pilcher wrote:
> I have (finally!) reached the point of writing unit tests for my
> WeakIdentityHashMap, and testing for proper removal of otherwise
> unreachable keys is proving to be quite a problem.
>
> Currently, my tests assume that a call to System.gc() will ensure that
> all cleared WeakReferences will be enqueued, but this does not appear to
> be the case.
>
> Does this sound credible? (This is Sun's 1.5.0_06 JVM on Linux, BTW.)


References are not guaranteed to be enqueued immediately after they are
cleared. In Sun's implementation all references get passed through a
maximum priority thread before becoming enqueued. A further complication
with UNIX threading is that, unless the process is run as root, the
thread priority is apparently ignored.

> If System.gc() won't do the trick, does anyone know of anyway to ensure
> that all WeakReferences are actually enqueued?


I have a suspicion that References objects that are dropped themselves
or only referenceable via WeakReferences do not get enqueued. That was
on my list of things to check...

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      01-18-2006

"Ian Pilcher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thomas Hawtin wrote:
>> References are not guaranteed to be enqueued immediately after they are
>> cleared. In Sun's implementation all references get passed through a
>> maximum priority thread before becoming enqueued. A further complication
>> with UNIX threading is that, unless the process is run as root, the
>> thread priority is apparently ignored.

>
> I was afraid of that. I know that we're not supposed to depend on the
> behavior of the garbage collector, but this non-determinism makes
> testing things a real PITA.


I have found it useful in testing such things to create lots of large
objects (say, 100,000-integer arrays) in a loop, which seems to force enough
collection to drive reference-enqueuing and even finalization. There are
still no guarantees, but you might give it a whirl.


 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      01-19-2006
Mike Schilling wrote:
>
> I have found it useful in testing such things to create lots of large
> objects (say, 100,000-integer arrays) in a loop, which seems to force enough
> collection to drive reference-enqueuing and even finalization. There are
> still no guarantees, but you might give it a whirl.


The observable effects are quite possibly because that acts as a delay
loop rather than it forcing more GC.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Adam Maass
Guest
Posts: n/a
 
      01-19-2006

"Ian Pilcher" <(E-Mail Removed)> wrote:
>I have (finally!) reached the point of writing unit tests for my
> WeakIdentityHashMap, and testing for proper removal of otherwise
> unreachable keys is proving to be quite a problem.
>
> Currently, my tests assume that a call to System.gc() will ensure that
> all cleared WeakReferences will be enqueued, but this does not appear to
> be the case.
>
> Does this sound credible? (This is Sun's 1.5.0_06 JVM on Linux, BTW.)
>
> If System.gc() won't do the trick, does anyone know of anyway to ensure
> that all WeakReferences are actually enqueued?
>


AFAIK, the specification does not require that gc *immediately* enqueue
cleared weak references -- only that they be enqueued sometime after they
are, in fact, cleared. That may be the source of your troubles.

-- Adam Maass


 
Reply With Quote
 
Ian Pilcher
Guest
Posts: n/a
 
      01-19-2006
Thomas Hawtin wrote:
>
> The observable effects are quite possibly because that acts as a delay
> loop rather than it forcing more GC.
>


One way or another, it seems to be doing the trick right now. Since its
testing code, I can live with it for now.

--
================================================== ======================
Ian Pilcher (E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      01-19-2006

"Thomas Hawtin" <(E-Mail Removed)> wrote in message
news:43cee11c$0$1496$(E-Mail Removed)...
> Mike Schilling wrote:
>>
>> I have found it useful in testing such things to create lots of large
>> objects (say, 100,000-integer arrays) in a loop, which seems to force
>> enough collection to drive reference-enqueuing and even finalization.
>> There are still no guarantees, but you might give it a whirl.

>
> The observable effects are quite possibly because that acts as a delay
> loop rather than it forcing more GC.


Could be.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
releasing callback thread immediately by enqueuing it and processingit on another thread. bsobaid C++ 1 04-06-2009 08:00 PM
Re: Write-to-disk cache via WeakReferences? Paul J. Lucas Java 2 08-03-2005 09:21 PM
Problem with enqueuing/dequeuing objects between threads Bryan Balfour Perl Misc 5 07-28-2005 12:08 PM
Write-to-disk cache via WeakReferences? Paul J. Lucas Java 6 07-25-2005 03:11 PM
weakreferences - my understanding Indbond Java 10 04-23-2004 03:10 PM



Advertisments