Jump to content
Excelsior Forums


Excelsior Staff
  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About IgorJorch

  • Rank

Profile Information

  • Gender
  1. IgorJorch


    Dear Harshit, Investigation of this problem requires interaction via support email, and, as you already duplicated your question there, we answered you there as well. This thread will be frozen until the issue is solved and then the results of the investigation might be posted here. King regards, Igor Jorch, Excelsior Support.
  2. IgorJorch

    Safety of PDB files persistence

    Hi Martin, Let me answer to your questions referring to their numbers only. 1.2. Yes. In fact, glibc is just a standard system library so any linux application depends on it. 1.3. Yes, but note that there is section Compliance Tests. Given the large variety of linux distributions we cannot guarantee totality of support. Also note that if you're building a native (ex. C/C++) library it is not JET-compiled and thus might require higher version of glibc/kernel depending on its compiler settings and build environment. 1.4. JET-compiled applications/libs are compiled by `jc` and linked by `xlink` -- internal compiler and linker placed in $JET_HOME/bin. 2.1. Yes. 2.2.2. Yes, that should work. But note that in JET 15 (scheduled to May) we plan to rework smart recompilation and some things regarding *pdb might change. 2.3. All of those files are used at some step of build process. Removing some of them might result in partial or full recompilation. For example in obj.zip all object files (machine code from compiler) are written and from them the linker composes resulting exe/so. Kind regards, Igor Jorch, Excelsior Support.
  3. IgorJorch

    What happened with the compilerheap option?

    Hi Martin, The thing is, `compilerheap` option always made sense only in Excelsior JET targeting x86 CPUs. Starting with JET 14 it is hardwired to maximum and removed from compiler' interface. On the other hand, compiler in Excelsior JET for AMD64 and ARM32 CPUs is itself a JET-compiled Java application, so its heaplimit can be set using JETVMPROP environment variable as following: JETVMPROP=-Xmx2g $JET_HOME/bin/jc ... Kind regards, Igor Jorch, Excelsior Support.
  4. IgorJorch

    Class unloading

    Hello, You both are right, for now Excelsior JET doesn't have Class GC. We're working to make it possible, but it isn't the main priority for nearest releases. Kind regards, Igor Jorch, Excelsior Support.
  5. IgorJorch

    Run-time linking of shared libraries

    Hi Martin. Note that this citation is from section Run time linking and above that the Load time linking and their differences are described. If you are making a multi-component application following the steps from section 11.3 Multi-component applications of User's Guide, then there are `!uses` directives in your project files. That directive enforces load-lime linking for specified components, so there is no need in provoking run-time linking for them. Pretty the same is effect of `!module` directive, yet it is more restritive in a way that while `!uses` allows inter-component (but not cyclic) dependecies, for `!module` there must be no static dependencies between libs. To sum this up, there are three different ways to tell JET-compiled executable about additional classes in a separate library: `!uses lib1.prj` directive, which provides load-time linking and allows AOT-compiler to see info about classes compiled into lib1 so that it can resolve static dependencies onto them. `!module lib2.so` directive, which also provides load-time linking but doesn't know anything about how this library were compiled, so cannot provide AOT-compiler with info needed to resolve static dependencies onto classes. `-dll:class-...:lib3.so` runtime property, which provides run-time linking and thus cannot influent AOT compilation in any way. Hope this helps, but don't hesitate to ask additional questions if anything not clear enough. Kind regards, Igor Jorch, Excelsior Support.
  6. IgorJorch

    Cleanup of files in JET directory

    Hi Martin, You better not remove those folders manually, but use JETSetup utility for it. What you need is the following commands: jetsetup -remove-profile <profile-index> jetsetup -cleanup-backup Note that on Windows you need to add `-batch` option before any others. Please refer to User's Guide section "2.5 JET Setup options summary" for futher info. Kind regards, Igor Jorch, Excelsior Support.
  7. IgorJorch

    Documentation of RSP file format

    Hi Martin, No, there is no such documentation. This file is just linker configuration, and the only documentation available about it is help which is printed for `xlink.exe`. Regards, Igor Jorch, Excelsior Support
  8. IgorJorch

    Documentation of xlink, xxd and xpack

    Hi Martin, Yes, the effect of this command is that your exe stats to explicitly import all symbols, that are exported by the specified .so. However, the reason you need this in your build is unknown - you can try to remove it and see what would happen, most probably everything will continue to work fine. Kind regards, Igor.
  9. IgorJorch

    Spring Lookup method injection

    Hello, Yes, dynamically generated code will be JIT-compiled by Excelsior JET runtime. You can try it out using our Evaluation edition: https://www.excelsiorjet.com/evaluate Also, there is an article in our Knowledge Base about compilation of Spring Boot application to which you may refer while evaluating: https://www.excelsiorjet.com/kb/38/howto-natively-compile-a-spring-boot-application If you have more question, please don't hesitate to ask them in our support: java@excelsior-usa.com Regards, Igor Jorch, Excelsior Suppor