JDK-5086661 : JDK 1.5's temporary native libraries may not be deleted on VM exit
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 2004-08-13
  • Updated: 2018-03-23
  • Resolved: 2018-03-23
Related Reports
Relates :  
JDK-4240589 - (ref) runFinalizersOnExit(true) causes VM crash for user native libraries
Relates :  
JDK-8164512 - Replace ClassLoader use of finalizer with phantom reference to unload native library
Relates :  
JDK-4171239 - File.deleteOnExit() does not work on open files (win32)
Description
Name: js151677			Date: 08/13/2004


JDK 1.5's temporary native libraries may not be deleted on VM exit

In JDK 1.5 the concept of a temporary native library is implemented in
javax/management/loading/Mlet.java.
It used java.io.File.deleteOnExit() on the temporary native library to
indicate the file should be deleted when Java VM exits.

Unfortunately there is a prohibition against deleting an open shared
library on HPUX.  The unlink() system call will fail with errno==ETXTBSY
on HPUX.  As a result, on HPUX and possibly other operating systems
the temporary native library files used by Mlet often are not deleted.
(Solaris operating system does not appear to be impacted by this issue.)

The JDK 1.5's VM shutdown sequence does not unload any remaining shared
libraries.  Also the deleteOnExit() hook is run too early, when the Java
daemon threads are still running and may be registering additional
deleteOnExit entries.  A race condition is possible.

  To implement this feature properly the VM should unload any remaining
open shared libraries in its shutdown process.  Only after the shared
libraries are closed should the deleteOnExit() hook be run.
(Incident Review ID: 296806) 
======================================================================
Comments
When a ClassLoader is unloaded, the native libraries will be unloaded via java.lang.ref.Cleaner mechanism (see JDK-8164512). MLet is a URLClassLoader and the cleaning of native libraries is handled in the same way. I would recommend to consider using NIO and non-temporary files which can be deleted by an explicit shutdown hook installed by MLet mechanism.
23-03-2018
WORK AROUND J2SE does support the forced unloading of native library during the VM shutdown. An application wishing to use this functionality needs to call: Runtime.runFinalizersOnExit(true); This will force the ClassLoader finalize method to run which will unload all native libraries that have been loaded into the processes address space. This should work around the bug that is being reported here. ###@###.### 10/25/04 20:30 GMT
25-10-2004
EVALUATION There does not appear to be any way to achieve the semantics required by the JMX API here without changing the JVM, at least on HPUX. The Java API doesn't provide a way to unload a library explicitly, so even if the JMX implementation tried to use Runtime.addShutdownHook instead of File.deleteOnExit, there would be nothing useful it could put in that hook to make the file deletion work. The JVM change suggested in the Description appears to be the only way to make this work. This could potentially be an HPUX-specific change, though. ###@###.### 2004-08-17 J2SE does support the forced unloading of native library when the VM is exited. An application wishing to use this functionality needs to call Runtime.runFinalizersOnExit(true); This will force the ClassLoader finalize method to run which will unload all native libraries that have been loaded into the processes address space. This should work around the bug that is being reported here. ###@###.### 10/25/04 20:30 GMT
25-10-0004