Bug ID: JDK-6399321 Event Handle Leak while using JNI

Versions (Unresolved/Resolved/Fixed)

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	JDK 6
5.0u10 b01Fixed	6Fixed

Short description:              Event Handle Leak while using JNI

Operating System:              Microsoft Windows
OS version:                    5.2.3790
Product Name:                  JRE
Product version:               java version "1.5.0_06"
                               Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)                  Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

Hardware platform:             
System Manufacturer      FUJITSU SIEMENS 
System Model     D1899   
System Type      X86-based PC   

Processor x86 Family 15 Model 4 Stepping 3 GenuineIntel ~3600 Mhz      
Processor x86 Family 15 Model 4 Stepping 3 GenuineIntel ~3600 Mhz      
Processor x86 Family 15 Model 4 Stepping 3 GenuineIntel ~3600 Mhz      
Processor x86 Family 15 Model 4 Stepping 3 GenuineIntel ~3600 Mhz
BIOS Version/Date        FUJITSU SIEMENS // Phoenix Technologies Ltd. 4.06  Rev. 1.05.1899, 6/27/2005     
Hardware Abstraction Layer      Version = "5.2.3790.1830 (srv03_sp1_rtm.050324-1447)" 
Total Physical Memory    2,046.93 MB    
Available Physical Memory       1.09 GB 
Total Virtual Memory     3.39 GB 
Available Virtual Memory 2.11 GB 
Page File Space  1.54 GB 
Page File D:\pagefile.sys 

Full problem description:

The program contains a single thread that attaches and detaches from JNI in a loop.
The loop-count and the sleep-time in the loop can be customized via command line arguments.

Test case:                      
The test progam is JniTest.zip
Compile and Link the Test program
Open the Task Manager in the machine and add the column "Handle" to the list of columns displayed. 

Start the test program
Observe the Handle count for the process JNITest.exe
It can be observed that the Handle count increases by two for every execution of the for loop. Each execution consists of one call AttachCurrentThread and DetahCurrentThread to JVM.Open "Process Explorer" from www.sysinternals.com and observe the type of handles used by the process JNITest.exe. It can be seen that the leak happens for the type "Event".

EVALUATION Later parker initialisation in JavaThread::run is no good, as threads running java called from a JNI attach do not go through JavaThread::run. All seems fine until somebody Thread.interrupts such code, when it crashes due to a null parker. My current suggestion is removing the parkerFreeList. So far it has not actually been used (only had things added).

10-04-2006

EVALUATION This problem appears in 5.0u6 after 6271298 is implemented. mustang leaks 1 handle rather than 2 for every attach/detach cycle. On Windows we are leaking Handles, on Solaris we leak some C heap memory. A JavaThread has a "Parker", which on JavaThread destruction is now added to a free list rather than deleted. However, JavaThread::initialize skips the check for whether it can use a Parker from this free list, because ThreadLocalStorage isn't initialized at that point. So we do "new Parker()" for every jni_AttachCurrentThread() call and never delete them. I'm testing the moving of Parker initialization (with parkerFreeList checking), e.g. to JavaThread::run.

04-04-2006

Duplicate :	JDK-6410103 - Handle Count increases when IE windows is opened and closed repeatedlt in 5.0u7-b02
Relates :	JDK-6461897 - nsk/regression/b4324380 fails with java.lang.OutOfMemoryError
Relates :	JDK-6271298 - java.util.concurrent unpark() may reference stale native thread structures