United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6399321 Event Handle Leak while using JNI
6399321 : Event Handle Leak while using JNI

Details
Type:
Bug
Submit Date:
2006-03-16
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2006-08-09
Component:
hotspot
OS:
windows_2003,windows_xp
Sub-Component:
runtime
CPU:
x86
Priority:
P1
Resolution:
Fixed
Affected Versions:
5.0u6,5.0u7
Fixed Versions:
5.0u10

Related Reports
Backport:
Duplicate:
Relates:

Sub Tasks

Description
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".

                                    

Comments
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).
                                     
2006-04-10
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.
                                     
2006-04-04



Hardware and Software, Engineered to Work Together