Bundles tested:
- 6u5 b02 promo
- jre-6u10-plugin2-windows-i586-p-05_nov_2007
- 6u10 b07 JRE bundle

Platform: WinXP pro, English
Test run:  customer  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
Posted Date : 2007-11-15 02:35:53.0

N/A

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.
Posted Date : 2007-12-16 21:14:44.0