JDK-6359309 : Large setting for -Xmx param prevents plugin from starting in Internet Explorer
  • Type: Bug
  • Status: Closed
  • Resolution: Duplicate
  • Component: deploy
  • Sub-Component: plugin
  • Priority: P3
  • Affected Version: 1.4.2_09,5.0
  • OS: windows_2003,windows_xp
  • CPU: x86
  • Submit Date: 2005-12-06
  • Updated Date: 2010-10-12
  • Resolved Date: 2007-11-27
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)

Microsoft Windows [Version 5.2.3790]

2.0GHz Pentium M processor
1GB physical memory
Internet Explorer 6.0.3790.1830

When Java Plugin is configured with -Xmx parameter set to some number larger than half of the system's physical memory, java plugin will not start in Internet Explorer.  It pops up a message box that says "The Java Runtime Environment cannot be loaded".  On my machine, -Xmx750m does the trick. The problem seems to be independent of the version of Windows operating system. It's also reproducible on Windows 2000 and XP.  It happens with both the <APPLET> tag and with the <OBJECT> tag.

Open Java 1.5 control panel and switch to Java tab.  Open "Java Applet Runtime Settings" by clicking on "View" button.  In the last field (Java Runtime Parameters) enter "-Xmx512m", where "512" should be replaced by 3/4 of the system physical memory size.  Also enable "<APPLET> tag support" for Internet Explorer.  Apply settings.  Open internet explorer and navigate to any web page that contains an applet.

Applet runs and its user interface is visible.
The place where the Applet would be on the HTML page is blank with a little icon in top left corner, which represents missing control. An error message dialog is displayed by Java Plugin.

Error message box has the title "Java(TM) Plug-in Fatal Error", and the message is "The Java Runtime Environment cannot be loaded".

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
HTML page that calls up the applet.


Test Applet
<APPLET width=400 height=250>
	<PARAM NAME="codebase" VALUE=".">
	<PARAM NAME="code" VALUE="testapplet.TestApplet.class">
	<PARAM NAME="name" VALUE="Test Applet">


Even though the actual TestApplet.class doesn' t have to be available to see the problem, below is java code for this Applet.


package testapplet;

import java.applet.Applet;
import javax.swing.JLabel;

public class TestApplet extends Applet {
    public TestApplet() {
        add(new JLabel("Applet's Running"));

---------- END SOURCE ----------

Maximum possible value for -Xmx must be determined by trial and error for each individual machine.

EVALUATION There have been a large number of negative comments regarding the above evaluation and the decision to close this bug as "will not fix". 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. This work was checked in under 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 in IE described above does not interfere with the specification of a large -Xmx value (for example, in the Java Runtime Parameters in the Java Control Panel). Second, the new Java Plug-In will support specification of JVM command-line arguments on a per-applet basis via a new parameter in the applet's HTML. This will eliminate the need to do any global setting of this or other parameters in the Java Control Panel. The first public release of the new Java Plug-In will be in build 08 of the forthcoming "6uN" release, for which early access builds can be found at https://jdk6.dev.java.net/6uNea.html. As of this writing the new Java Plug-In is not yet the default, but users will be able to turn it on by toggling a Java Control Panel switch. More documentation on the new plug-in will be provided when it becomes available or soon afterward. To indicate that we have heard your feedback and have responded, the disposition of this bug is being changed from "will not fix". Instead, for tracking purposes, it is being closed as a duplicate of 6622332. We hope that the new plug-in will address this significant issue. 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 when it becomes available and file any issues against it under product java, category java_plugin, subcategory plugin2.

EVALUATION Windows loads dll's in various awkward places in the 32-bit virtual address space, leading to virtual address space fragmentation. The jvm requires contiguous virtual address space for the heap, so if many dll's have been loaded, it's quite likely that for a given on-the-large-size value of -Xmx, the jvm may not be able to obtain a large enough contiguous memory region for the heap.

EVALUATION The applet fails to load because VM initialization fails with such big value for -Xmx. You can try running any java program (SwingSet2 demo for example) and experience exact same behavior. So, this is not limited to plugin. The error you'll see when running java program in command prompt is: C:\jdk1.5.0_04\demo\jfc\SwingSet2>java -Xmx2000m -cp SwingSet2.jar SwingSet2 Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. The vm was unable to allocate requested heap size and failed to initialize. This is a know behavior. This issue might be addressed in the future release by vm team. The workaround is rather simple - specify smaller heap size. I am closing this bug as "Will not fix".