Hi.. I need some inputs on the below.
I am trying to write a program which will help me find the number of objects eligible for garbage collection at any given point of time.
How do i do this?
Any suggestions?
Sheetal Krishna 0 Newbie Poster
stultuske 1,116 Posting Maven Featured Poster
why would you do that? I guess you could do that by keeping every object reference that you create also in a List somewhere, and counting those that are 'null'.
jwenting 1,889 duckman Team Colleague
of course the very act of checking an object to see if it's in the garbage collection queue may well remove it from the queue, and is likely to itself generate objects that make it on to the queue the moment your check ends.
Therefore the check is useless. You have a Schroedinger's cat situation here, you can't check the queue without changing the queue.
JamesCherrill 4,733 Most Valuable Poster Team Colleague Featured Poster
Can you avoid that problem by using only weak references?
~s.o.s~ 2,560 Failure as a human Team Colleague Featured Poster
I am trying to write a program which will help me find the number of objects eligible for garbage collection at any given point of time
AFAICT, there is no mechanism exposed by the JVM to "count" the number of objects eligible for garbage collection since this would in turn require a "mark" cycle.
Can you avoid that problem by using only weak references?
Unfortunately none of the reference types (phantom/weak/soft) will help here.
JamesCherrill 4,733 Most Valuable Poster Team Colleague Featured Poster
How does visualvm get it's info (eg number of instances awaiting finalisation)? Maybe there's no way from within the language, but what kind of instrumentation interface does visualvm hook into?
~s.o.s~ 2,560 Failure as a human Team Colleague Featured Poster
How does visualvm get it's info (eg number of instances awaiting finalisation)? Maybe there's no way from within the language, but what kind of instrumentation interface does visualvm hook into?
That's a good observation.
First to clarify: the number of objects pending finalization isn't really the same as the number of objects eligible for garbage collection. The former means that the objects are already identified as part of garbage (or simply put have been GC'ed) and have been put in the finalizer queue by the GC. The latter asks the question "when the next GC cycle runs (minor or major), which objects would be picked up for GC".
Secondly, it's easy to get the number of objects pending finalization; we already have a MBean for it. There is a catch though; that count is only for objects which have a non-trivial finalize method i.e. is only applicable for classes which override the finalize method. Since the OP (I believe) has no control over the objects, this count would not reflect objects of custom classes which don't override finalize. So I would say that count is not a very good measure in this particular case.
jwenting 1,889 duckman Team Colleague
and of course, one should never rely on finalize() being called at all, so in production code its very existence if often a clear sign of design flaws or at least a serious red flag as to the correctness of the code.
As the execution of finalize() is not guaranteed on any instance, any code in there is by definition unreliable...
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.