JDK-4034630 : finalization enabled on instance memory allocation, not object construction
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.1,1.2.0,6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,solaris_2.5,solaris_9
  • CPU: generic,other,sparc
  • Submitted: 1997-02-26
  • Updated: 2005-01-14
  • Resolved: 2005-01-14
Related Reports
Duplicate :  
Description
In a simple Java class (attached) the "finalize routine is only called if

1.  The object reference is set to null before program exit AND

2.  The mainline code sleeps for a few seconds before exiting



also .. if these conditions are met, but if the constructor fails, later on, the finalize routine is STILL called!!  (See example in attachment)

ron.kleinman@Eng 1997-02-25

Comments
EVALUATION This is apparently a misunderstanding of how finalization works. In the example code it is necessary to null the reference to the finalizable object or the object cannot be garbage collected, and hence cannot be finalized automatically. The sleep has the effect of stopping the runtime from exiting for some seconds, during which time async GC will happen to run, freeing the object. Then, because nothing else is happening, the async finalizer runs, calling the finalize method of the object in question. You can see that this is happening by using the -verbosegc flag when running the example. All this is exactly as it's supposed to be. GC can only reclaim GC'able objects, and happens asynchronously unless you tell it otherwise. Finaliza- tion happens asynchronously unless you tell it otherwise. There is no timelines guarantee by default. If you want to force it to happen, you can call System.gc followed by System.runFinalization to synchronously collect garbage and run finalization. If you do that in the example, the finalizer is run without the sleep. If you don't want to run this stuff synchronously, but still want to make sure finalizers for all objects get run before the runtime exits, you can use System.runFinalizersOnExit. Using that in place of the sleep or the synchronous stuff in the example will also cause the finalizer to be run. In short: this bug report is based on a misunderstanding of finalization. timothy.lindholm@Eng 1997-02-25 With later discussion with the reporter of the bug, we agreed to convert the original bug report into an RFE. Part of the confusion was caused by the fact that an object is set up for finalization immediately upon the allocation of its memory. If its constructor fails, the user might think that the object effectively never got created, and might be subsequently surprised when the object was GC'ed and finalized. I think that the counterargument is that if you associate external resources with an object, and finalization is the last bastion of reclaiming those resources, then if there is any chance of the constructor failing you'd want to be sure that the object got finalized. Otherwise you'd leak external resources. The JLS suggests that an object does not become finalizable until it has been "created", but its use of that term appears informal to me. This is precisely the second time this issue has come up since finalization was introduced, as far as I know. timothy.lindholm@Eng 1997-03-07 It looks like the spec should be worded a bit more precisely to make the fact that an object whose constructor failed can be finalized. gilad.bracha@eng 1998-04-16 The specification has be clarified and the current behavior is violating the spec. Reassigning this to runtime and setting the priority accordingly. ###@###.### 2004-11-23 06:32:04 GMT
23-11-2004