JDK-8006836 : PlatformEvent is leaking event handles on Windows
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs24
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • Submitted: 2013-01-24
  • Updated: 2014-01-24
  • Resolved: 2014-01-24
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.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8028280 - ParkEvent leak when running modified runThese which only loads classes
Relates :  
JDK-8028280 - ParkEvent leak when running modified runThese which only loads classes
Description
Ran Kitchensink on Windows when developing the NMT test module, noticed that the number of open handles are increasing over time. Started a longer Kitchensink run, it's on day 9 right now, and the number of handles have increased from around 860 to 1060, private bytes seems stable though.

The Kitchensink process is running with '-Xmx4000m -Xms4000m -XX:NativeMemoryTracking=detail'
Comments
Limited to max threads over the process lifetime. There was potential for a leak, resolved in 8028280
24-01-2014
There is the same potential leak for PlatformEvent (as is with ParkEvent).
22-01-2014
The current design keeps the events in case another thread ever references them. We can investigate whether there is another approach.
05-02-2013
You would need to track the maximum number of threads that have ever existed at one time - which is a little tricky without introducing a thread creation/destruction bottleneck on the counters. But basically I would say this is not a real problem. You now have a tool that is highlighting something that has always been happening. Given the VM never returns memory to the OS and the handles were all actively in use at at least one time, then this is not really going to affect the VM process or other processes.
31-01-2013
It seems like we're leaking event handles associated with ParkEvent, this seems to be a known issue according to comments in the source: "Once a win32 event handle is associated with an Event, it remains associated with the Event. The event handle is never closed. This could be construed as handle leakage, but only up to the maximum # of threads that have been extant at any one time. This shouldn't be an issue, as windows platforms typically permit a process to have hundreds of thousands of open handles." First of all this may not be the only reason for this leak, the number of threads in Kitchensink should be fairly stable so this shouldn't increase that much over time. The problem with this expected leak is that this makes it very hard to figure out what handles are part of the expected leak and which ones are not. Second, the statement: "This shouldn't be an issue, as windows platforms typically permit a process to have hundreds of thousands of open handles." is not entirely true since each of these handles occupy kernel memory and this affects far more than just your local java process. On top of that the kernel memory for handles is non-pageable, meaning that the kernel cannot swap this memory out to disk but instead has to keep this in physical memory at all times.
31-01-2013
2013-01-30 12:27 1012 Handles Type Count Event 741 Section 1 File 126 Directory 2 Mutant 2 WindowStation 2 Semaphore 16 Key 7 Thread 97 Desktop 1 IoCompletion 17
30-01-2013
2013-01-27 09:49 975 Handles Type Count Event 705 Section 1 File 126 Directory 2 Mutant 2 WindowStation 2 Semaphore 16 Key 7 Thread 96 Desktop 1 IoCompletion 17 2013-01-29 17:16 997 Handles Type Count Event 722 Section 1 File 128 Directory 2 Mutant 2 WindowStation 2 Semaphore 16 Key 7 Thread 99 Desktop 1 IoCompletion 17
29-01-2013
Started a new run with 7u14-b10 (hs24-b29), since all the 7u12 builds are gone and I can't get the debug symbols for 7u12-b09 anymore... Turned on htrace (handle tracing) which should give me stack traces for each open handle.
24-01-2013