I've put in checks in our code to check is things are getting finalized... It does
happen (eventually)
To force cleanups, I rely on the following:
1. add a void kill() in all heavy classes. make it delete files, close
sockets... etc.
2. In void finalize() I make all references point to null
One thing to note and this helps tremendously is to do a v.removeAllElements() for
vectors not in use. I think that should be added to the finalize section for
Vector but that's up to SUN to do that.
3. Don't forget to do a super.finalize() in all subclasses at the last line in
void finalize()
The way I look at it, clean up the reference tree all you can so that the GC does
not have to do it for you. If the GC's work is less, it makes your code run
faster since the GC is not sitting in its tree cleaning mechanism.
One other thing to note is the GC only runs when the system is idle.. It can be
scheduled, but when it runs, it can get preempted pretty easily.. So if you
specifically set things to null as much as you can, the GC's job will be easier
and you'll reach all those hard to reach places faster.
Manfred Hauswirth wrote:
> Though this is not directly Java-Linux related, I think it is important to
> mention this on this mailing list, since it is important to distinguish Java
> problems from Java-on-Linux problems (if there are problems with Java on
> Linux, people tend to blame it on Linux ...):
>
> The finalize() issue seems to cause lots of problems. It is not completely
> clear whether it works or not (IMHO not even for SUN themselves). According to
> my tests (SUN JDK 1.2 reference implementation - just to be completely on the
> safe side) it does not work satisfactory (at all ?).
>
> I've tested finalize() with a server app - and no finalize() method gets
> called after I delete all by references to my test objects. A bug parade check
> gives contradicting results:
>
> Bug Id 4148454 (State Closed, not a bug)
>
> "The System.runFinalization method can only invoke the finalize methods of
> objects that that garbage collector has detected as being "finalizer
> reachable." Unfortunately, the conservative GC in the "classic" VM sometimes
> can't classify an object that way because there's a stray pointer to it
> somewhere in a native stack. This is most likely what is happening in the
> submitter's case; it works in JDK 1.1.5 out of sheer luck. The only way to
> guarantee that you've dropped all references to an object is to ensure that
> all threads that have ever referenced the object have terminated."
>
> IMHO this is NOT satisfactory, especially if you write servers that heavily
> consume resources (like I do), because this actually means that resource
> consumption can possibly grow infinitely and the programmer cannot do anything
> against it.
>
> Even more confusing is the follwoing statement (Bug Id 4102959, State Closed,
> will not be fixed) :
>
> "According to the bugs database, this is only the third time that anyone's
> noticed that we've never implemented class finalization. --
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> xxxxx@xxxxx 1/9/1998
>
> Please see 4108421 "Remove class finalization from JLS". Because of that
> proposal, this bug will not be fixed. xxxxx@xxxxx 1998-04-07"
>
> A search for 4108421 gives: "Results: No bug found"
>
> Hmmmmm ?!
>
> Any opinions ?
>
> Manfred
>
> --
> [EMAIL PROTECTED]
> http://www.infosys.tuwien.ac.at/Staff/pooh/
> ---------------------------------------------------------------------------
> "Growing old is mandatory. Growing up is optional."
