Jump to content
Excelsior Forums

AlexandrFIlatov

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Posts posted by AlexandrFIlatov



  1. We have extensively studied the provided example and there are some points we need to explain:

        1. This example may be optimized in naive way by just wrapping data into ByteBuffer in the following way:        

    buf = ByteBuffer.wrap(data) 

        After this,  ByteBuffer.put() may be replaced with buf.getInt(), buf.getFloat() which speed ups the execution by 3-5 times (both on Oracle HS and JET).


        2. Bench results depend on inlining settings. Our performance analysis team made an example (based on the provided above) on which x86-compiled application has comparable to Hotspot performance, when inlining level is set to default. However, when inlining level is set to "Very Aggressive" in JET Control Panel, resulting executable outperforms Hotspot by the factor of 1.5 on the same bench.

    Inline planning has very big influence on performance, which ahead-of-time compiler may fail to predict because it lacks execution profile information. Default value is chosen to be applicable for the majority of applications, but It is reasonable to try different inlining levels for particular application and compare the resulting performance.

        3. Excelsior JET compiler for x86 applications has more optimizations implemented than x64 compiler. That is why, if application uses less than 2GB of RAM, it is worth trying to compile this appication with x86 edition of Excelsior JET and compare the performance of both executables.


    The upcoming release of Excelsior JET is devoted for various performance improvements in both (x86 and x64) compilers. Note, that the example provided by cheble is in our short-list for performance analysis.


  2. It seems that ojdbc7 uses Java Security API which checks if loaded classes belong to specific jar.

    In order to support this checks Excelsior JET have to pack this .jar into executable. You can do this by editing your .prj file, replace

     

    !classpathentry lib/ojdbc7-1.0.jar
      -optimize=autodetect
      -protect=nomatter
    !end
    

     

    with

    !classpathentry lib/ojdbc7-1.0.jar
      -pack=all
      -protect=nomatter
      -optimize=all
    !end
    

    rebuild your application and check whether it helped.


  3. Since TestRun is finished successfully, it is highly possible that you have a configuration problem.
    How do you run JET-compiled application? Have you tried to clear CLASSPATH variable explicitly (e.g. running from console):            

    export CLASSPATH=
    ./YourApp


  4. Hello,

    On 06.01.2017 at 5:29 AM, zabquart said:

    Let me also preface this with, it works 100% perfect from Netbeans IDE and running before compiling.

    Is it true that your application successfully passes "Test Run" step and only compiled version fails?

    To perform a Test Run, execute the following Maven command:

             mvn jet:testrun

    Note, that Test Run is a special runnng mode with all environment variables being empty to avoid any side effects.

    It is possible, that SecurityException is caused by invalid CLASSPATH variable which you forgot to clear before run of JET-compiled application (which already incorporates ojdbc.jar in compiled form and should not load it again).


  5. On 04.10.2016 at 3:13 PM, GaryLynch said:

    Thanks for the response. Do you know when 11.3 will be released?

    Release of Excelsior JET 11.3 is planned for Oct'16. Stay tuned with our roadmap or subscribe on our news feed to get updates about Excelsior JET: https://www.excelsiorjet.com/roadmap.

    23 hours ago, GaryLynch said:

    also, do you know which locales are affected?  I am having the problem with customers in Turkey and the Czech Republic.

    We have encountered some problems with Turkish, Polish and Chinese locales.

    Excelsior Support Team


  6. Usually this kind of error appears when there are some 32-bit libraries are absent. Some key components of the 64‑bit version of Excelsior JET for Linux remain 32‑bit and most 64‑bit Linux systems do not have the 32‑bit libraries installed by default.

    Please, use the command-line below and check if error persists:

                        sudo apt-get install libc6:i386 libx11-6:i386 libxext6:i386 libxrender1:i386 libxi6:i386 libxtst6:i386

    This behaviour is explained on our site https://www.excelsiorjet.com/evaluate#install at section "Installation Instructions", subsection "Linux".


  7. Being a compliant Java SE platform implementation, Excelsior JET in particular supports the Management API, the JMX (Java Management Extensions) technology, and SNMP. However, there is a number of HotSpot-specific management and monitoring features in the reference implementation. They are not supported. Unforunately, class RuntimeMXBean is one of them at the moment. 

    You can find more information about supported JMX API by Excelsior JET here: https://www.excelsiorjet.com/kb/36/howto-monitor-and-manage-your-optimized-applications-using-jmx-or-snmp.

     

    Anyway, Excelsior JET successfully recognizes options "-Xss" and "-Xmx" passed through JETVMPROP, but RuntimeMXBean.getInputArguments() returns empty String[], so your approach does not give you desired results when compiled by Excelsior JET. Note, that on Windows and OS X stack size for main thread is hardwired by compiler into executable using option -stacklimit from project file as required by executable binary format.

    Regards,

    Excelsior Support Team

×