Jump to content
Excelsior Forums

tanelorn

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Everything posted by tanelorn

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Hi, I am trying to deploy a rather large Java application (300MB of jars) using Excelsior JET. That application works properly during the initial "trial run" in JET Launcher. The best scheme I could come with so far is the following: - my "business classes" are compiled as an executable (about 100MB), - third-party classes are referenced in java.class.path and compiled on demand. The initial steps of my application works flawlessly, but then it crashes with the following: java.lang.InternalError: JIT ERROR: (JIT) Internal crash while bytecode compiling: out of heap space I tried to increase the available heap by using "-heaplimit=1677721600" and "-Djet.gc.heaplimit:1677721600" in my project file, but that does not solve my problem. I am also using the "-Djet.jit.fast" option. Could you suggest me a workaround? Best regards.
  10. (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.
  11. 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.
  12. (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.
  13. 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.
  14. (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.
  15. (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.
  16. (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.
  17. (JIT) Internal crash while bytecode compiling

    Hi, Thanks for your answer! I had forgotten to ask for a notification on this topic, so I did not see it. I will test this asap. On a related note, what is the expected behaviour when the JIT compiler goes out of memory (ie, use more than 256MB in your example)? Can it, as the JET runtime, use swap space in this situation? How can I enable this? My application may load third-party plugins at run time, and I am concerned by the risk of out of memory errors if some of them are too large. I'd much rather prefer the application to swap in this situation than to halt with a "JIT Out of Memory" message. Best regards.
  18. Hi, While recompiling a project with the new Excelsior JET 6 compiler, I was met with the following error message: * [ *** F505 ] * Error importing xxx.prj (in project yyy.prj): projects that use Global Optimizer can not import other project The message makes sense, but I seem to remember that I was able to perform this kind of compilation under JET 5. This (supposedly) new behaviour means that the Global Optimizer cannot be used on Multi-Component Applications (as described by the manual). Is there a workaround for this (ie, referencing JET-compiled components from a globally-optimized app)? Using the -LOOKUP directive instead of !use, perhaps? Best regards.
  19. JET6 : Global Optimizer and Importation

    OK, that definitely makes sense. I suspected something like that. Actually, I liked the idea of having a smaller "rt" directory and a more aggressively optimized application. But I have no strong reasons to stick to it, and I prefer to benefit from the multi-component possibility. Thanks for those informations! Regards.
  20. F941 Out of Memory Error

    Hi, I am using Excelsior 5.0 on a Windows platform. While compiling a large class (>500K) embedded in a big jar (>13M), jc crashed at first with an F950 error ("out of memory: adjust COMPILERHEAP equation"). Since I'm more interested in completing the compilation than getting optimized code for now, I fixed this using the COMPILEWITHFIXEDHEAP, as suggested by the documentation. The F950 error disappeared, but I am now running into F941 errors ("out of memory: increase the value of COMPILERHEAP equation"). This error does not seem affected by the COMPILEWITHFIXEDHEAP flag, so I gradually increased the COMPILERHEAP. I am now using "-compilerheap=2000000000", which seems to be near the acceptable limit value, and jc is still crashing with F941 errors. Do you have any advice? It would be definitely acceptable for me to spend more time compiling due to swapping, or to specifically disable native code compilation for this large class. But I still need most of this jar to be natively compiled, as my code depends on it. Best Regards.
  21. F941 Out of Memory Error

    Hi, Following an advice from your support team, I compiled this jar with the just-released Excelsior JET 6. This F941 error is not reproduced anymore: the JET 6 version seems much more robust with respect to memory consuption. So this issue is solved for me. Thanks for your time! Best regards.
  22. Explicit Mixed Compilation Model

    Hi, The Excelsior JET 5.0 documentation states that "Even though certain classes of your application can be compiled statically, you may enable the mixed model for them explicitly." It is also said that "You may also use this reflective shield facility to pick out the classes and packages that you do not want to precompile by simply making them unavailable to the JET static compiler." Could you describe how this is performed? I can manually remove classpath entries before jc compilation, but then my compiled app throws ClassNotFound exceptions. Best regards.
  23. (JIT) Internal crash while bytecode compiling

    Hi, Is there a verbose mode or some similar tool I could use to see which class the JIT compiler was processing while it crashed? Sadly, this information is not provided by the error message. In this way, I could try to compile it AOT, or to replace it. Since my first post, I tried miscellaneous GC settings such as -Djet.gc.defragment, -heaplimit=0, -Djet.gc.fatal.out.of.memory or -Djet.gc.verbose.out.of.memory. None fixed my problem or helped me gain more insight on its cause. Best regards.
  24. Explicit Mixed Compilation Model

    Hi, removing the jars at compile time and setting up java.class.path to ensure their proper use at run time did the trick for me, indeed. xpack simplifies this, as I can ask it to copy the jars in the deployment directory. After reading the KB 000030 ("PRB: Compiled application cannot find resources"), I also added to java.class.path the jars I compiled into my exe. I thought at first that they should be removed from the classpath, but that led to ressources not found, even if they are embedded in the app. I think you should add an example demonstrating this (a compiled and a non-compiled jar, each containing resources) to your samples. But perhaps I overlooked it. Thanks!
  25. F941 Out of Memory Error

    Hi, I have just sent you the smallest jar still reproducting the F941 error I could come up with. Actually, this problem is alleviated by the fact that none of my classes directly inherit from or implement the content of this jar. So, as I understand it, not compiling it does not impede their native compilation. Anyway, the resulting jar is surprisingly small, so that's probably worth a look. Best regards.
×