Jump to content
Excelsior Forums

liontiger

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Posts posted by liontiger


  1. 15 minutes ago, SRS said:

    I understand the Jet runtime included things like GC ratio to configure how garbage collection happens.  As it so happens, our application is quite tuned for this and we use

    jvm launch settings such as the ones below.    How do I make sure that these get used in the Jet runtime?

     

    
    -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads
    =4 -XX:CMSWaitDuration=90000 -XX:CMSInitiatingOccupancyFraction=10 -XX:+UseCMSInitiatingOccupancyOnly

    These options are specific to Oracle HotSpot and its GC. Excelsior JET has its own Garbage Collector with its own set of options that cannot be mapped to or from HotSpot ones.
    So you can remove all of the -XX options and see if your application works fine on our GC.

    If after that your application will require any tuning you will have to do it using properties described in Excelsior JET User's Guide: https://www.excelsiorjet.com/docs/jet/jetw010#0321


  2. If that's the case, please try using our JET Launcher tool by replacing "java" in your command line with "<JET Home>/profile1.8.0_121/jre/bin/java" where <JET Home> is the full path to your Excelsior JET installation directory.
    The resulting command line will look like this:

    <JET Home>/profile1.8.0_121/jre/bin/java -noverify -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8091,s
    uspend=n -Xms=8G -Xmx=8G -Xmn2G -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/tmp -XX:CompileThre
    shold=1000 -XX:+UseCompressedOops -XX:ErrorFile=/var/log/hs_err_pid%p.log -XX:SurvivorRatio=3 -XX:+UseLargePages -XX:+UseTLAB -X
    X:TargetSurvivorRatio=90 -XX:+AlwaysPreTouch -XX:+AggressiveOpts -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads
    =4 -XX:CMSWaitDuration=90000 -XX:CMSInitiatingOccupancyFraction=10 -XX:+UseCMSInitiatingOccupancyOnly -Xloggc:$LOGDIR/gc.log -ve
    rbose:gc -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=12 -XX:GCLogFileSize=100M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -
    XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=1024G -Dcom.sun.managemen
    t.jmxremote.port=18091 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

    This will create a new JET project with specified arguments in JET Control Panel.


  3. Just to reiterate what has been discussed with @AndyDenby over email and to provide a public statement on this issue:

    It is highly discouraged to manually alter `java.class.path` property. If you will attempt to do it, you must provide ALL dependencies explicitly in that class path.

    So for this particular case the suggested workaround is:

    1. Remove altering of `java.class.path` from `jvmArgs` configuration. Gradle plugin will handle adding all dependencies into class path on its own.

    2. Exclude packaged configs (which you want to change after deployment) from created .jar file using following configuration:

    
    jar {
        exclude('config')
    }

    Assuming that all packaged config files are located in 'config' directory inside of .jar.

    The reason for such workaround is that Gradle plugin currently searches import class path entries before external class path entries, so if you don't exclude configs from .jar, JVM will find them in resources of compiled .jar file instead of your packaged external configs.

    There is a ticket in Excelsior JET Gradle plugin's bug tracker to add proper support for modification of `java.class.path` - https://github.com/excelsior-oss/excelsior-jet-gradle-plugin/issues/36

×