JDK-6630062 : run Yoko* reliability test with new plug-in doubles the handles used compared with old plug-in
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-11-15
  • Updated: 2010-09-08
  • Resolved: 2008-02-21
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 6
6u10 b10Fixed
Related Reports
Relates :  
JDK-6613949 - run Yokogawa reliability test with new plug-in bundle caused big handle leaks
Relates :  
JDK-6760921 - Browser hang while reloading LiveConnect conformance tests on Unix platforms
Description
Bundles tested:
- 6u5 b02 promo
- jre-6u10-plugin2-windows-i586-p-05_nov_2007
- 6u10 b07 JRE bundle

Platform: WinXP pro, English
Test run: yokogawa test YokogawaTC4_001
workspace: deployment_mustang_UR_int_exec_ws

with new plug-in, a 24 hours run
handle count grow from 540 to 123,465

with old plug-in, a 24 hours run
handle count grow from 643 .. 61,826

Please see more comparison data in Comments field
Notice the range is much small with 6u5 b02 promotion build
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6630062.0
18-12-2007
EVALUATION After iteratively disabling almost all of the functionality in the new plug-in, it turned out that the root cause of the handle leak with the Yokogawa tests was attaching threads to the JVM via the JNI AttachCurrentThread and never detaching them via DetachCurrentThread. The Yokogawa TC4_001 test repeatedly loads an applet in new browser windows, closing the window associated with the previous invocation. This causes a fresh thread to be created and attached to the JVM to execute each new applet instance, and these threads were never being detached. While testing the fix with the Firefox browser, where the threading model is different (one thread per browser instance, not browser window), it was discovered that fixing the problem by detaching the thread in the destructor of the MozPluginInstance actually introduced a resource leak. This was the structure of the original fix for IE: detach the thread in AxControl::FinalRelease(). It appeared that repeatedly attaching and detaching a thread from the JVM introduced a resource leak, which would indicate a JVM bug. However, an attempt was made to reproduce this behavior with a standalone test case outside the browser with no success. The solution chosen is therefore to detach the current thread from the JVM inside the DllMain DLL_THREAD_DETACH notification. There is an assumption that detaching a thread from the JVM which was never attached has no adverse side-effects, which appears to be the case. On Firefox, we currently do not detach the current thread from the JVM on Windows. In addition to this fix, a helper class was introduced to help with the pushing and popping of JNI local frames to avoid inadvertently holding on to Java objects via JNI local references for longer than expected. Tested with overnight runs of the Yokogawa TC4_001 test case with both IE and Firefox on Windows. Slight resource leaks remain in both browsers, but it is believed that the Java-related leaks are fixed. Additional manual testing of other applets done on Windows and Solaris platforms.
16-12-2007