Jump to content
Excelsior Forums


Excelsior Staff
  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About AlexandrFIlatov

  • Rank

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. AlexandrFIlatov

    Jet 15.0 has a problem with ODA/Teigha

    Hello, Mentioned crash happens in native method com.opendesign.td.TD_DbJNI.OdDbText_getBoundingPoints. The most probably the JET Runtime crashes due to incorrect JNI usage. Please try to run your application on the OpenJDK JRE with "-Xcheck:jni" option specified in the java command line. It can help to detect some errors in native methods. Also check your code for the pairs AttachThread/DetachThread: every AttachThread must be concluded with DetachThread before the thread dies. Attaching without detaching is a common JNI misuse that is not checked by the OpenJDK JVM. Moreover, using JNI functions in a thread is prohibited before either CreateJavaVM or AttachThread has been invoked. Regards, Alexandr Filatov, Excelsior Support
  2. 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.
  3. AlexandrFIlatov

    Sealing Violation

    We are glad that your problem is solved! Do not hesitate to contact us if you have any other questions regarding Excelsior JET. Excelsior Support Team
  4. AlexandrFIlatov

    Sealing Violation

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

    Sealing Violation

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

    Sealing Violation

    Hello, 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).
  7. AlexandrFIlatov

    Exception Occurred During Initialization

    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. We have encountered some problems with Turkish, Polish and Chinese locales. Excelsior Support Team
  8. AlexandrFIlatov

    Exception Occurred During Initialization

    Hello, Yes, it is Excelsior JET error message. It is known issue that such error could happen on Windows with some specific locales. Upcoming release will incorporate necessary fixes. Is it possible for you to test your application compiled and packaged with early access build of Excelsior JET 11.3 beta 3? It could be downloaded at https://www.excelsiorjet.com/beta. Excelsior Support Team
  9. AlexandrFIlatov

    Jet 11 - Failed to determine compiler version

    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".
  10. AlexandrFIlatov

    JVM arguments during execution

    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
  11. AlexandrFIlatov

    JVM arguments during execution

    Hello, You can find all the information you are interested in at Excelsior JET User's Guide, section "Application Considerations", subsection "Java system properties" at https://www.excelsior-usa.com/doc/jet/jetw011.html#0308. Regards, Excelsior Support Team