Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About tanelorn

  • Rank
  • Birthday 01/01/01
  1. Re: Excelsior JET To Protect Eclipse RCP Applications

    Thanks, using this and the memory-related flags enabled proper compiler operation. Sadly, it halted near the end of the compilation process with an assertion error with regard to an EMF class. I posted a more detailed report to java@excelsior-usa.com. With regard to feedbacks: the compiler seems to be rather robust with respect to memory consumption and large project handling (it could compile 73719 classes out of 96735 before halting). Disk usage seems reasonable too (600Mb of temporary data for an admittedly large >500Mb eclipse directory). I noticed only one processor core was used, tough. Do you have any plan for multi-core compilation in JET 6.5? Best regards, Olivier Parisy.
  2. Re: Excelsior JET To Protect Eclipse RCP Applications

    I just tried this. My setup is the following : I installed the beta1 and kept the default profile (1.6.0_07). I copied the [tt]eclipse[/tt] directory of our application (with its plug-ins in [tt]eclipse\plugins[/tt]) in [tt]D:\JETBeta1_Test\eclipse[/tt]. My current directory while compiling is [tt]D:\JETBeta1_Test\comp[/tt] I compile using: [tt]jc =ercp D:\JETBeta1_Test\eclipse -pack=none[/tt] The compiler runs for only a few seconds, then exits without an error message. A (nearly empty) [tt]eclipse_jetpdb[/tt] is created, but nothing else seems to happen. Since our distribution is large, I also tried to compile with the [tt]-compilerheap=1300m -compilewithfixedheap+[/tt] flags, but the behavior is the same: D:\JETBeta1_Test\comp>jc =ercp D:\JETBeta1_Test\eclipse -pack=none -compilerheap=1300m -compilewithfixedheap+ Excelsior JET v6.5 beta 1 Evaluation Version (c) Excelsior 1997,2008 Active Java SE Version 1.6.0_07 (profile 7) ************************ JET v6.5 beta 1 EVALUATION ************************** * This program cannot be used in a business, commercial, government, * * or institutional environment except for evaluation purposes. * ************************************************************************ Make Eclipse RCP appplication "D:\JETBeta1_Test\eclipse" Do you have any advice? Best regards, Olivier Parisy.
  3. Re: Excelsior JET To Protect Eclipse RCP Applications

    Hi! Thanks for your time. This is what I understood. I just wanted to point out that I needed diferent [tt]-pack[/tt] options depending on the plug-in. Nice, this is what I expected. May I ask you if the beta 2 will include this GUI? Could you provide me with more details? It would be nice to be able to try this now, without having to wait for the GUI. Not for now, as the Eclipse IDE will not work without the [tt]-pack[/tt] option, and applying this option to my plug-ins would not be realistic. I may give it a try to ensure things at least run smoothly, but I would definitely prefer to try your "tricky" compilation steps Best regards, Olivier Parisy.
  4. Hi, I read your "Secure Eclipse RCP Applications with Excelsior JET" page, and especially the FAQ section, with great interest. We would like to provide IP protection to one of our applications using AOT compilation. It is written as a set of Eclipse plug-ins enriching the Ganymede distribution (it's not a standalone RCP application). If I understand your FAQ properly, this would involve a project setup along the line of: Compile our app plugins using JET 6.5, without retaining the bytecode. Compile the rest of Ganymede using the [tt]-pack[/tt] option (to ensure proper IDE operation). Perhaps exclude from step 2 rarely used plugins, which can be compiled at runtime using JIT if needed. Am I correct in thinking that: The current JET 6.1 beta 1 version has an "all or nothing" approach which prevents the described setup for now. The GUI which will be provided in following beta versions will enable this kind of fine-tuned compilation (as is already possible with JET 6.0 for "classic" J2SE apps). Similarly to previous JET versions, the GUI will generate freely editable textual project files. Best regards, Olivier Parisy.
  5. Plug-in compilation

    Thanks for your understanding Great, thanks for the hint! A JET 6.0 pro version. No, not for now. But knowing it can/will be done opens possibilities. Regarding my initial query: you remembered me of the checks required to compile an application in multiple components. But would the getResources("/resources/descriptor.xml") mechanism I described work if each of my plug-in is compiled as a DLL (as I understand it, I suppose it would)? On a more general note: could it be used as a "real" plug-in system, ie, offer extensibility "on-site" by just dropping new DLLs in an existing installation? What would then be the steps required so that the existing application could "see" the new plug-ins? Referencing the new DLLs in the CLASSPATH? Or some trick with JETVMPROP and the -dll option, perhaps? Regards, Olivier Parisy.
  6. Plug-in compilation

    OK, I understand those are the standard checks to be performed when using the JET compiler on multi-components applications. Our plug-ins are independant of each other, so cyclic dependencies are not to be expected. They may be dependant on some "core" classes compiled in the main EXE, though. Would that be the case, I suppose I could compile those "core" classes in a "core.dll" compilation set, on which my plug-ins and main EXE would be dependant, isn't it? Anyway, I understand this constrain and I am ready to track dependencies as needed to define my compilation sets properly. I am asked to provide intellectual property protection to our app; Excelior JET was explicitely chosen to enable such a native compilation of our "business" classes (I am very interested by your "stay tuned" post regarding JSR 277, btw ). Monolithic compilation of our code in an EXE nicely fulfills this purpose, but limits extensibility, hence my question. Regards, Olivier Parisy.
  7. Plug-in compilation

    Hi, Our application uses a plug-in mechanism implemented in the following way: Each plug-in is a standalone jar, which must be in the [tt]CLASSPATH[/tt]. They all contain a descriptor, at a given, fixed path (let's say [tt]/resources/descriptor.xml[/tt]). Each descriptor stores the name of the "main" class of the plug-in. at start-up, descriptors are discovered using: Thread.currentThread().getContextClassLoader().getResources("/resources/descriptor.xml") We finally iterate on the descriptors collection to load each plug-in "main class". For now, this has worked finely with JET by compiling all plug-in jars with the application jar, in a monolithic way. But I would now like to make this more modular by compiling each plug-in jar in its own DLL. Will the JET runtime then be able to "discover" all of our plug-ins using the previous algorithm? I suppose this part of the doc is appropriate: "You need to tell the JET runtime in which DLL to look for each class or package. You may do that by adding the following options to the JETVMPROP equation or the JETVMPROP environment variable: -dll:class-name:dll-name or -dll:class-prefix*:dll-name" But will this work in our case (multiple [tt]/resources/descriptor.xml[/tt] files, each one in a plug-in)? Regards, Olivier Parisy.
  8. (JIT) Internal crash while bytecode compiling

    Thanks a lot, you helped me very much With respect to memory consumption, it's definitely understandable (and rather comforting) that you prefer to play it safe. I'll do my part by limiting my application memory allocations, too.
  9. Multiple Compilation Sets and Usage Statistics

    Nicely detailed. Thanks. OK. That's some kind of equivalent to -Djet.jit.disable.resolution, but for AOT compilation, then? Best regards.
  10. (JIT) Internal crash while bytecode compiling

    OK, so there is no official way to see them But what I was interested in is not the set of all properties, but the value of official properties... Some kind of "verbose" switch to check which heap size an application was configured with, etc. Some investigations revealed a major memory leak in the native code part of our application, so I would not incriminate your engine. Should I see other memory-related crashes after this fix, I'll send your a more detailed report to your support address. But fine-tuning JIT behaviour with the flags you provided me already helped a lot. That may be useful for stability purpose. But I am mostly trying to reduce my application memory consumption for now to ensure those problems will not happen again. I would have say "hoping the JIT compiler will cope with them", but I am much more confident in it now, thanks to your explanations. Fair enough Yes, you can expect that. We are interested to improve and evolve any piece of our software including JIT and we have this task on our "todo" list. That's nice to read. Moreover, considering I didn't compare the SUN and JET JIT compilers under the same memory load, I can't make statements about their relative robustness... On an unrelated note: your forum lacks a "Solved" button initial posters could use to flag a thread when they are satisfied by your answers. I have opened quite a number of them those last weeks, and I would be glad to "close" most of them as an appreciation of your efficient support. Best regards.
  11. Multiple Compilation Sets and Usage Statistics

    OK. So, since global optimization cannot safely be used with multiple compilation sets, the trial run is not so useful in this case. From a .prj point of view, what does "explicitly added" mean? Is it its inclusion using a !classpathentry directive? Now, that is very interesting. It means I can finely tune the set of classes actually compiled to native code, which mean I will be able to limit the size of my DLLs to actually needed code. So you answered my next question before I asked it, basically Best regards.
  12. Hi, While compiling an application as a set of DLLs (using multiple compilation sets), does the !module myproject.usg directive, when included in each .prj file, have an impact on compilation? Or is this only used by the "main" (EXE) compilation set? On a related note: I tried to compile a sub-project where all jars have the -protect=nomatter flag. It also includes an .usg file referencing some classes of those jars. The compilation then fails with a "no classes to compile" (or similar) message. Is this to be expected? Best regards.
  13. (JIT) Internal crash while bytecode compiling

    I understand that now. So we can't just switch to JET, compile a minimum set of classes and expect its JIT compiler to perform most of the work (as the SUN JIT would), isn't it? That was my initial analysis, on the basis that I only wanted to protect a minimal set of core business classes, and that compiling all my jars AOT leads to a huge 300MB DLL/EXE. While the flag you suggested fixes my problem now, as I understand it I have no certainty that an especially taxing plugin written by one of my customers (so, not under my control and after shipment) will not generate a JIT crash. That is definitely not the same as slow-running code: my support will hate me for this Considering that the next iteration of our software will be totally plugin-based, that's a rather daunting prospect. Would you say the main focus of Excelsior JET is and will stay AOT compilation? Or can we expect a robustness of your JIT compiler in par with the SUN JIT in the future? No offence intended here: I just need to clearly understand those issues. Best regards.
  14. (JIT) Internal crash while bytecode compiling

    That's very interesting. What is the default value for jet.jit.heap.size? Is there any way to display all runtime parameters at launch time, by the way? Indeed, even when using small values for jet.gc.heaplimit, or a value of 0, as soon as I explicitely set jet.jit.heap.size, my application crashes with "JIT ERROR: (RT) not enough memory for JIT compiler". As an example, I still get this error when using -Djet.jit.heap.size=256m -Djet.gc.heaplimit:256m (and many other combinations of values) on a 4GB computer. Is this to be expected? Yes, that did the trick for me! Using a combination of -Djet.jit.disable.resolution and -Djet.jit.cache, I can get a first slow, not crashing run, and subsequent runs have proper performances. Thanks for your help! Best regards.
  15. (JIT) Internal crash while bytecode compiling

    I just tested this. Even with -Djet.jit.heap.size=1024m, JIT compilation still breaks and I get "JIT ERROR: (RT) not enough memory for JIT compiler". I will continue to add jars to my static compilation set until the charge on the JIT compiler is minimal, but I am growing concerned with the risk of failure at runtime when dynamically-loaded plugins will get added. That may be performed by customers after shipment, where such a crash is not acceptable. So I am definitely interested by your answer to my previous message with respect to swap enabling. Interestingly, I also tried the -Djet.jit.cache option and, after a few runs, all classes get compiled and my application behave properly. The jittemp directory is then surprinsingly small (12MB), so I have difficulties understanding why this cannot be dynamically compiled in one pass. Best regards.