JDK-6433218 : Java applet fails with Large Java Runtime Parameter setting
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0,5.0u7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2006-06-02
  • Updated: 2011-06-02
  • Resolved: 2008-01-17
Related Reports
Duplicate :  
Relates :  
Description
Running a Java applet/application with runtime parameter set above half of actual RAM available on the system fails to initialize applets. We are regularly receiving incidents from JRE consumers reporting this behavior affecting their applets/applications performance. 
This behavior is always reproducible ranging from multiple JRE version(s) - 1.5.0_06, 1.5.0_07 to Mustang-Beta and across multiple browser(s).

There are lot of valid comments from the customer in the Java forums about this behavior of Plug-in. Please see:
http://forum.java.sun.com/thread.jspa?threadID=697370

Steps to Reproduce:
1) Check system physical memory from:
Start -> Command -> systeminfo (XP only)
2) Ensure that you have one of the mentioned JRE version(s) installed: 1.5.0_06/_07 or 1.6.0-Beta2
3) Enable "<APPLET> tag support" for browsers from Java Control Panel (Start -> Control Panel -> Java -> Advanced - applet Tag Support)
3) Run the test vm applet from:
http://www.java.com/en/download/help/testvm.xml
Default behavior will run the test applet with dancing duke and installed/working JRE version information.

In the NEXT step - we will change the memory settings for JRE.

3) Go to Start -> Control Panel -> Java -> Java - Under "Java Runtime Environment Settings" 
4) Click on View - Double click in the box under "Java Runtime Parameters" and enter a value above half of system's physical memory. For example, if RAM is 1024 MB, enter a value "-Xmx768M" or above "-Xmx1024"(without quotes).
5) Click OK - Apply - OK
Note: Ensure that you have JRE cache cleared before attempting the next step
6) Start a new browser session (IE/Mozilla/Firefox)
7) Enter test vm url:
http://www.java.com/en/download/help/testvm.xml
An error message titled
"Java(TM) Plug-in Fatal Error
The Java Runtime Environment cannot be loaded."
or
"Java(TM) Plug-in Fatal Error
Several Java Virtual Machines running in the same process caused an error"
Note: Screenshots attached

Expected Behavior:
Reducing -Xmx setting down to 512M or below will run the applet normally. However, Applet should be able to run/perform without any issue irrespective of memory usage if available within the system RAM limit.

As a temporary relief, can we have a more user friendly error message.

Comments
EVALUATION There have historically been many reports of problems running applets when a large -Xmx setting has been specified via the Java Control Panel. Some bugs where this either definitely is the root cause, or may be the root cause, include 6359309, 6433218, 6516270, 6528750, and 6559586. Up until recently, it was not technically feasible to fix this problem in the Java Plug-In due to its in-process architecture. In recent months a new implementation of the Java Plug-In has been developed which changes the execution model of applets. Instead of running the applets in a JVM embedded in the web browser's process, they are now run in a separate JVM process which communicates back to the web browser. The initial checkin of this work done under bug ID 6622332. This new plug-in solves this problem in two ways. First, since the JVM is no longer running in the same process as the web browser, the address space fragmentation problem (which occurs most often in the Internet Explorer browser) does not interfere with the specification of a large -Xmx value via the Java Runtime Parameters in the Java Control Panel. Second, the new Java Plug-In supports specification of JVM command-line arguments, including -Xmx, on a per-applet basis via a new java_arguments parameter in the applet's HTML. This eliminates the need to do any global setting of this or other parameters in the Java Control Panel. The new Java Plug-In is currently available for testing in the early access builds of the "6uN" release, which can be downloaded from https://jdk6.dev.java.net/6uNea.html . See https://jdk6.dev.java.net/testPlugIn.html for instructions on testing the new Java Plug-In specifically. In 6uN build 10, the new Java Plug-In is enabled by default upon installation on the Windows platform; see the testing instructions for installation on the Solaris and Linux platforms. Customer feedback so far indicates that the new Java Plug-In conclusively solves this longstanding problem. For tracking purposes, this bug is being closed as a duplicate of 6622332, which is the "umbrella" bug covering the initial integration of the new Java Plug-In. Note that currently the new plug-in does not change the default heap size for applets, but we believe that this will be far less of an issue now that an individual applet can request a particular heap size. We are open to revisiting this particular issue, in particular in the context of the new plug-in. Please try the new Java Plug-In and file any issues against it under product java, category java_plugin, subcategory plugin2.
17-01-2008

EVALUATION This is actually a feature request to provide better error message for existing problem described in bug 6359309. Changing to RFE.
13-06-2006

WORK AROUND Set JRE parameter less then 3/4 of actual physical memory present in the system. For example, 512 MB if RAM is 1024 MB.
02-06-2006