JEP 132: More-prompt finalization
|Discussion||hostspot dash dev at openjdk dot java dot net|
|Reviewed by||Paul Hohensee|
|Endorsed by||Brian Goetz, Paul Hohensee|
Improve the promptness of finalization by use of multiple finalizer threads and/or aggressive management of the finalizer queue, and define a Java API for an application to request that reference processing be done.
Better management of native resources is not a goal of this project. Users may find more-prompt finalization aids native resource management but that will depend on the individual application.
Details are TBD but generally a stress test for finalization should result in more-prompt finalization than without this project. There are JRockit finalization stress tests that Hotspot generally does not pass which it should pass when this project is integrated.
Customers have asked for more-prompt finalization. This work will not satisfy all customers but should satisfy more.
More intense management of the finalization may be needed (objects moved from
the finalization queue in larger numbers). Investigate the JRockit processing
for finalization. This includes possible modification of the JDK library
Additional finalization threads may be added when finalization is requested.
Define a new Java API that will advise the garbage collector and runtime that finalization should be done. Implement actions on the part of the garbage collector and runtime to hasten finalization. For example, finalizable objects are discovered during a garbage collection so a garbage collection may be needed.
Educate users on alternatives to finalization.
Tests which create many finalizable objects and which print the number of objects finalized will be needed. Such tests exist in Hotspot nightly testing and similar tests for JRockit exist. Some modifications may be needed to stress test this feature. Even with this feature, finalization will be non-deterministic, so that should be taken into account when judging the pass/fail of a test.
Risks and Assumptions
If finalization is removed from the Java language then this project will not be necessary.
- Performance/scalability: Should be no change or improved
- Documentation: Some documentation for licensees may be needed