JDK-6927479 : Need support for explicitly cleaning up references for freeing up associated native resources
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs19
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2010-02-18
  • Updated: 2019-02-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6999109 - G1: ParallelClassLoading tests fail with java.io.FileNotFoundException (Too many open files)
Relates :  
JDK-6913047 - Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space
Description
Please refer to 6913047 "Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space" for more details.

Here is a quick summary of the problem encountered:
native resources/memory are allocated by native PKCS11 library and returned to java apps for use. These wrapper objects containing the native resources/memories are cleaned up by the weak reference queue mechanism. However, if GC isn't run, then these wrapper objects aren't en-queued for cleaning up and the associated native memories aren't freed. This may lead to an OOM situation whenever native PKCS11 library allocates memory faster than GC is called to free up the native resources.

Thus, to avoid this kind of OOM situation, we need some way to be able to free up these native resources automatically. It is suggested that this may be addressed by having a separate set of APIs to trigger the weak reference processing (without doing the GC).