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.