Community
Participate
Working Groups
The --launcher.XXMaxPermSize argument applies a vm argument -XX:MaxPermSize conditionally on the vm being from Sun. On windows, the company name from the jvm's exe/dll is checked. We should now set the vm argument for "Oracle" as well as "Sun Microsystems". *nix platforms are not affected as there sun vms are detected by execing "java -version" and looking for "Java HotSpot(TM)" or "OpenJDK"
See patch and +1 from Tom on bug 319514.
Fixed in the 3.6.x branch
I have tagged this as "R36x_v20100715" for Helios SR1. The following projects have changed: org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher.wpf.win32.x86
Andrew, We are seeing evidence that JRockit does not always happily continue after a warning on -XX:MaxPermSize. The issue seems to be specific to some versions of Windows and possibly versions of JRockit. The one that didn't start for us is Win 7 64-bit. Raj, could you list configurations tested, including JRockit version on each? Perhaps it would make sense to port the *nix launcher logic to Windows? That approach seems more robust.
Forgot to add... We will help with testing of modified launcher.
JRockit Update: After a bit of investigation we found out the JRockit issue updated earlier was caused by using 32 bit vm instance on 64 bit OS. I am able to launch the IDE with 64 bit JRockit instance. NOTE: I still see the warning “[WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit” but that doesn’t stop from using the product.
> After a bit of investigation we found out the JRockit issue updated earlier was > caused by using 32 bit vm instance on 64 bit OS. I am able to launch the IDE > with 64 bit JRockit instance. Ram, Could you confirm that the case that fails was trying to use 64-bit Eclipse on 32-bit JRockit? The 32-bit Eclipse with 32-bit JRockit on 64-bit Windows case is expected to work...
It would be unfortunate if we had to port the *nix code over to windows as that is a larger code change than we generally like to make in a maintenance release. Execing "java -version" is a bigger hit to startup times. Checking the output of "java -version" would distinguish between hotspot and jrockit, but it still suffers from the problem of a string change breaking us. Is "Java HotSpot(TM)" that much more permanent than "Sun Microsystems" was? (I guess maybe it is...)
Yes, the earlier failure was caused trying to use 32 bit JRockit for 64 bit Eclipse. The 32 bit Eclipse with 32-bit JRockit on 64 bit Windows works fine.
> Is "Java HotSpot(TM)" that much more permanent than "Sun Microsystems" was? > (I guess maybe it is...) Probably a bit more permanent than company name. In the acquisitions that I've been through, the company name was not kept in products, but the names of the technologies stayed... BEA WebLogic -> Oracle WebLogic Sun Java HotSpot -> Oracle Java HotSpot For what it's worth.
*** Bug 320792 has been marked as a duplicate of this bug. ***
