 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006System.gc not enqueuing cleared WeakReferences
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  Signature======================================================================== Ian Pilcher i.pilcher@comcast.net ======================================================================== > I have (finally!) reached the point of writing unit tests for my > WeakIdentityHashMap, and testing for proper removal of otherwise [quoted text clipped - 5 lines] > > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > 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. Signature======================================================================== Ian Pilcher i.pilcher@comcast.net ======================================================================== >> References are not guaranteed to be enqueued immediately after they are >> cleared. In Sun's implementation all references get passed through a [quoted text clipped - 5 lines] > 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. > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > 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. Signature======================================================================== Ian Pilcher i.pilcher@comcast.net ======================================================================== >> 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 [quoted text clipped - 3 lines] > The observable effects are quite possibly because that acts as a delay > loop rather than it forcing more GC. Could be. >I have (finally!) reached the point of writing unit tests for my > WeakIdentityHashMap, and testing for proper removal of otherwise [quoted text clipped - 8 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.