Jump to content
Excelsior Forums

liontiger

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Posts posted by liontiger


  1. Hello Martin,

    There is no documentation (besides built-in help) for most of our command-line tools. Most notable exceptions are jc and xpack, which are JET compiler and JET packager respectively.
    The xlink tool is our linker and should not be used explicitly, thus it is not documented.

    As for xxd -- I have no idea, what this tool could be. 

    Best Regards, Ivan


  2. Hello Jane,

    Currently Excelsior JET doesn't support cross-platform builds.
    So in order to compile application for target Linux machine, you will need to use Excelsior JET for Linux, on a Linux building machine (either hardware or virtual machine can work).

    Note however, that Excelsior JET doesn't support Unix targets except for OS X.
    So if you are trying to compile for Unix (e.g. FreeBSD-based system), you can try compiling for Linux and running the application in Linux Binary Compatibility mode (see https://www.freebsd.org/doc/handbook/linuxemu.html).

    We have not tested this approach, so it may or may not work for you or target Unix system.

    Best Regards


  3. Quote

    To solve this issue, we try some optimized options (as below) about JIT cache but it doesn't work. It never create cache.

    JIT caching was deprecated in version 8.0 of Excelsior JET and has been removed since.

    As for excessive JIT compilation: 
    Could you please try specifying all dependencies' jars as `!CLASSPATHENTRY` equations?
    You can remove all `!module` equations as well as `-CLASSABSENCE=HANDLE` and `-IGNOREMEMBERABSENCE+` to see which dependencies are missing from compilation set.

    Also, have you tried using our Maven or Gradle plugins and/or Jet Control Panel tool?

    Best Regards,
    Ivan Trepakov
    Excelsior Support


  4. 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


  5. 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.


  6. 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

×