FULL PRODUCT VERSION :
java version "1.8.0_141"
Java(TM) SE Runtime Environment (build 1.8.0_141-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux laptop 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
I'm deploying an application over JNLP that needs to use the old Serial GC because of its heap compaction and memory-releasing behaviour across OSes.
I have a JNLP deployment descriptor that includes the following resource descriptor block:
<resources>
<j2se version="1.8+" java-vm-args="-Xms256m -XX:UseSerialGC"/>
<jar href="myApplication.jar" main="true"/>
<property name="jnlp.packEnabled" value="true"/>
</resources>
According to the JNLP file descriptor syntax reference at http://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html#resources , the java-vm-args attribute of the j2se element has a fixed set of arguments that it will pass through.
Both -Xms* and -XX:UseSerialGC are on the list of supported arguments, but try as I might, the Serial GC argument is not passed to the JVM that actually runs the application.
If I use a profiler, I can see that the -Xms argument is getting passed through to the executing JVM.
I'm certain that my JNLP serving rig is well-formed and that the JNLP descriptors are not being cached by an intermediary, as changing the value of the -Xms parameter takes immediate effect on the next invocation. I have tried reordering the parameters, removing the -Xms parameter, and using the -XX:+UseSerialGC variant that's mentioned elsewhere in the JVM documentation.
I've also noticed that the profiler shows a bunch of additional commandline parameters that are being passed by the JNLP launcher. Among them is:
-Djnlpx.vmargs=LVhtczI1Nm0A
Which, when you un-Base64 the value, yields "-Xms256m".
It certainly seems to me that the JNLP launcher is stripping a runtime option that the documentation says is legal.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a working JNLP deployment for an application.
2. Add a java-vm-args="-XX:UseSerialGC" attribute to the j2se element under the resources element.
3. Invoke javaws for your descriptor.
4. Connect a profiler to the JVM spawned by javaws.
5. Note the absense of the -XX:UseSerialGC JVM argument on the process.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
That the the Serial GC would be used by the JVM spawned by javaws.
ACTUAL -
The default GC is used.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages or crash logs are generated.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="http://hostname.com/" href="application.jnlp" spec="1.0+">
<information>
<title>Application Name</title>
<vendor>Comapny Name</vendor>
<homepage href="https://hostname.com"/>
<icon href="icon.png"/>
<icon href="icon.png" kind="shortcut"/>
<icon href="splash.png" kind="splash"/>
<description>Application Description</description>
<description kind="short">Application</description>
<shortcut online="false" install="false">
<desktop/>
<menu submenu="Group Name"/>
</shortcut>
<offline-allowed/>
</information>
<update check="timeout" policy="prompt-update"/>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.8+" java-vm-args="-XX:+UseSerialGC"/>
<jar href="application.jar" main="true"/>
<property name="jnlp.packEnabled" value="true"/>
</resources>
<application-desc main-class="com.hostname.package.App">
</application-desc>
</jnlp>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
A workaround has not yet been found. We're considering a nested launcher-inside-a-launcher to sidestep this restriction if a fix isn't forthcoming.
java version "1.8.0_141"
Java(TM) SE Runtime Environment (build 1.8.0_141-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux laptop 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
I'm deploying an application over JNLP that needs to use the old Serial GC because of its heap compaction and memory-releasing behaviour across OSes.
I have a JNLP deployment descriptor that includes the following resource descriptor block:
<resources>
<j2se version="1.8+" java-vm-args="-Xms256m -XX:UseSerialGC"/>
<jar href="myApplication.jar" main="true"/>
<property name="jnlp.packEnabled" value="true"/>
</resources>
According to the JNLP file descriptor syntax reference at http://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html#resources , the java-vm-args attribute of the j2se element has a fixed set of arguments that it will pass through.
Both -Xms* and -XX:UseSerialGC are on the list of supported arguments, but try as I might, the Serial GC argument is not passed to the JVM that actually runs the application.
If I use a profiler, I can see that the -Xms argument is getting passed through to the executing JVM.
I'm certain that my JNLP serving rig is well-formed and that the JNLP descriptors are not being cached by an intermediary, as changing the value of the -Xms parameter takes immediate effect on the next invocation. I have tried reordering the parameters, removing the -Xms parameter, and using the -XX:+UseSerialGC variant that's mentioned elsewhere in the JVM documentation.
I've also noticed that the profiler shows a bunch of additional commandline parameters that are being passed by the JNLP launcher. Among them is:
-Djnlpx.vmargs=LVhtczI1Nm0A
Which, when you un-Base64 the value, yields "-Xms256m".
It certainly seems to me that the JNLP launcher is stripping a runtime option that the documentation says is legal.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a working JNLP deployment for an application.
2. Add a java-vm-args="-XX:UseSerialGC" attribute to the j2se element under the resources element.
3. Invoke javaws for your descriptor.
4. Connect a profiler to the JVM spawned by javaws.
5. Note the absense of the -XX:UseSerialGC JVM argument on the process.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
That the the Serial GC would be used by the JVM spawned by javaws.
ACTUAL -
The default GC is used.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages or crash logs are generated.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="http://hostname.com/" href="application.jnlp" spec="1.0+">
<information>
<title>Application Name</title>
<vendor>Comapny Name</vendor>
<homepage href="https://hostname.com"/>
<icon href="icon.png"/>
<icon href="icon.png" kind="shortcut"/>
<icon href="splash.png" kind="splash"/>
<description>Application Description</description>
<description kind="short">Application</description>
<shortcut online="false" install="false">
<desktop/>
<menu submenu="Group Name"/>
</shortcut>
<offline-allowed/>
</information>
<update check="timeout" policy="prompt-update"/>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.8+" java-vm-args="-XX:+UseSerialGC"/>
<jar href="application.jar" main="true"/>
<property name="jnlp.packEnabled" value="true"/>
</resources>
<application-desc main-class="com.hostname.package.App">
</application-desc>
</jnlp>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
A workaround has not yet been found. We're considering a nested launcher-inside-a-launcher to sidestep this restriction if a fix isn't forthcoming.