System.gc not enqueuing cleared WeakReferences

[Ian Pilcher]

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]

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.

 

[Thomas Hawtin]

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

 

[Mike Schilling]

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.

 

[Thomas Hawtin]

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

 

[Adam Maass]

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

 

[Ian Pilcher]

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.

 

[Mike Schilling]

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

Could be.