Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8185553

-XX:+UseSerialGC stripped from java-vm-args

XMLWordPrintable

    • b23
    • x86_64
    • linux_ubuntu

      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.

            herrick Andy Herrick (Inactive)
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: