Excelsior JET 7.0 Beta Announcement In `tomcat-users’

Yesterday I announced the Excelsior JET 7.0 public beta program in the `tomcat-users’ mailing list at apache.org. The announcement has sparked a small discussion, but the follow-up would be a bit too long for email to my taste, so I am responding here and will then send a link to this post to the mailing list.

I will start with the concern that is easier to address. Leon Rosenberg wrote:

Wouldn’t that make the application slower? I assume this compiled code can’t be uncompiled and optimized by the hotspot, so it is not for performance.

Excelsior JET is an optimizing compiler originally developed as a tool for accelerating Java applications. True, Sun HotSpot Server 6 is very good, and so is Oracle JRockit, but there is no silver bullet – we have happy customers reporting substantial speedup of their apps as a result of AOT compilation, and we have prospects canceling evaluation because of the slowdown. I can point you to some third-party benchmarks, but your mileage will vary, one way or another.

Leon went on to write:

As for preventing decompilation, how many people/companies are actually delivering a war which they need to protect from decompiling? How many people would install such a product, one they can’t configure anymore, one that is even infectable by viruses?

We fully realize that Excelsior JET is unlikely replace the conventional JRE in the majority of Tomcat installations (unless Oracle starts charging for the JRE. πŸ™‚ ) So the question is if there are any Web application authors who might need our solution? We are sure there are some, and here is why:

  • We already have a few paying customers (technically it has been possible to compile Tomcat for years, but the process was difficult and error prone, plus the current version imposes some restrictions on your Web apps if you need protection, yet that does not stop people who really want it)
  • Customers and prospects keep asking if they could use our tool to protect their Web applications
  • “Tomcat” is the #5 search query of all times on our Web site, trailing only “SWT”, “Eclipse”, “DLL”, and “Swing”.

As you may see, our decision to add this feature is 100% customer-driven!

I have also spoken to the author of a popular Tomcat book, and he sees deployment as a big issue. Not deployment of web applications onto a Tomcat instance, but rather deployment of the entire solution, that is, Java Runtime plus Tomcat plus one or more Web applications. Ah, and don’t forget the database engine!

Imagine you are in sales engineering and a prospective customer wants to test drive your app just to get a feeling of its capabilities and such. If you could give them a single installer that would install and run on any manager’s PC with little to no configuration, and at the same time would be much more difficult to tamper with, would not you call this a competitive advantage?

The inability to configure Tomcat after native compilation is a misconception. If you download and install one of the sample packages, you would notice that the wars and jars are gone, but the Tomcat directory structure is retained and you still have the startup scripts and XML descriptors at your disposal. (Some people asked for an option to hide these as well, though.)

Moreover, Excelsior JET Runtime includes a JIT compiler, otherwise it would not have been certified Java Compatible and our company would not appear in the list of Java Licensees. So you may drop a WAR into webapps/ and it will work as usual. (Of course, out JIT is much less sophisticated than HotSpot, so that particular app would start slower and its response time would be worse than if you AOT-compiled it.)

As for viruses, last lime I checked java.exe was not immune to them either. πŸ˜‰

Ramzi Khlil wrote:

I think it’s not a good idea especially when application are subject to modification frequetly or if we plan to deploy a new application on the server. Tomcat has a very interesting feature which allows user to load application on fly without closing the server. But If I compile tomcat and webapps into single package, I will lost this feature.

I see that’s a very limited functionnality.

Again, there are use cases where you want to prevent (unauthorized) modification of your application. As Serge Fonville noted in his follow-up, there are ISVs whose shrink-wrapped products are essentially Web applications. Sure, those use cases may constitute a minority, but what we hear from our customers and prospects makes us believe it is not such a limited functionality.

Finally, I cannot resist quoting the AndrΓ© Warnier’s follow-up almost entirely:

…I have a number of corporate customers who have sub-contracted their
IT infrastructure to an external service company. In my experience these external people then, usually, tend to adopt the “umbrella” attitude, whereby they want every other external software supplier to supply their software in a manner that will cause themselves the least work and the least trouble. In other words, their ideal is that the software be delivered in the form of a single executable, pre-parameterised so that they don’t even have to choose options in an installer, and that they would not bear any responsibility if anything should not work as expected.

They are certainly not interested in even having to think about tricky customising options.

I am not saying that these are my preferred kind of customers. (I prefer smart ones, up to a point).

But this is a “use case” for the proposed package, it seems to me.

Categories: Excelsior JET, Java

Tags: , ,

4 Responses

  1. Leon Rosenberg Says:

    Sad, but I can’t resist to response πŸ™‚
    First of all I want to say that even I don’t know anyone personally, who might want to deploy a compiled webapp (my customers are mainly large enterprises with full control of their hosting solutions and therefore no need for compilation), I appreciate that other people may have a case for that, so I’m taking this point from the agenda.

    As for performance, I think that at least in theory the JavaVM must be able to perform better as any compiled program, the reasons for that are discussed in many articles, available on the net, so there is no need to repeat them here. Whether this theoretical advantage is achieved by current VMs is another question. Btw, your “third-party benchmarks” link is broken (points to this page).

    What I wanted to ask, is how the compiled version handles dynamical class loading via own class loaders, runtime weaving, proxying of the objects, rmi class loading and all this … ‘slightly extended’ stuff?

    Is it possible to create standard-java-compatible heap dumps for memory leak analysis? What about profiling?

    What about JLS constaints like enums? What’s with Java Memory Model, does the synchronization work as in normal JVM?

    If all this is handled properly, You will sure find a lot of users for your product, and I wish You to find many πŸ™‚

  2. Dmitry Leskov Says:

    Leon,

    Many thanks for spotting the broken link – corrected now.

    As for performance, there is one situation where static compilation has an advantage over dynamic: when the computational resources are scarce, e.g. in embedded systems. I am not going to suggest that you run Tomcat on your feature phone, but I know devices, such as heavy-duty printers, that have Java SE on board and provide Web services. I would rather use Jetty or some other container leaner than Tomcat in such devices, though. πŸ˜‰

    The above may also apply to virtual servers having only a chunk of physical RAM at their disposal.

    I leave it up to our CTO to follow up on your technical questions.

  3. Vitaly Mikheev Says:

    Leon,

    First off, thanks for your questions. I would divide them into five groups, just to give a few answers covering all at once.

    1. Compliance with the Java standard (call it Java)

    What about JLS constants like enums? What?s with Java Memory Model, does the synchronization work as in normal JVM?

    Well, Excelsior JET has been on the market since 2001. I mean we had time to implement all those Java language/platform features and implement them right. πŸ˜‰

    BTW, that Java cup logo (with the ?Java Compatible? subscript) displayed on the Excelsior JET page practically means that we

    have the huge JCK testsuite (for both Java 1.5 and Java 6)
    have the right to run it and check the results
    do that every single day (and night πŸ˜‰ )

    I assure you that among tens of thousands of the JCK tests, there are some written specially to guarantee that the features you mentioned are properly implemented.

    2. Dynamic compilation (may co-exist with static one)

    What I wanted to ask, is how the compiled version handles dynamical class loading via own class loaders, runtime weaving, proxying of the objects, rmi class loading and all this ? ?slightly extended? stuff?

    The JET Runtime is a complete JVM. It has a JIT compiler and supports custom classloading to handle stuff like bytecode instrumentation (aka weaving), dynamic proxying, etc. In addition, the JIT has a cahing mode to store/reuse the results of dynamic compilation, the cache can also be optimized off-line with the main AOT compiler, and so on.

    BUT all these tricks need bytecode to work. What about AOT and code protection?

    3. Custom classloaders (leave AOT a chance)

    What I wanted to ask, is how the compiled version handles dynamical class loading via own class loaders

    The fact is that AOT compilation can be used only for the classes whose classloading policy is known statically. So are the standard (so called bootstrap and application) classloaders but what about custom classloading schemes?

    One (bright) day, we made an observation: most developers tend to use frameworks (which implemented with the help of custom classloaders) rather than to hack the classloaders themselves. This is where AOT compilation can work even if non-standard classloaders are involved.

    Consider the following example.

    Typically, Eclipse RCP developers do not implement their own custom classloaders but they use the functionality provided by the OSGi Runtime for namespace isolation and module versioning.

    We implemented the Eclipse Runtime (Equinox OSGi) at the JVM level in Excelsior JET 6.5 and now offer the solution for Eclipse RCP (yes, there is demand for it πŸ˜‰

    4. JVM Tool Interface (?To have or not to have: that is the question?)

    Is it possible to create standard-java-compatible heap dumps for memory leak analysis? What about profiling?

    We do not support JVMTI as it?s an optional API in Java SE. The problem however is that support for JVMTI may seriously compromise IP protection.

    By a coincidence, last week, one prospect customer asked exactly the same question from another viewpoint: ?Can Excelsior JET prevent an attacker from creating Java heap dump for my application??

    As you may see, the other side of the coin is a weak point for security and IP protection.

    That?s why we implemented our own (non-standard) facilities for debugging and profiling. By default, they are not available to the users.

    5. JIT vs AOT (an essay on theoretical bounds)

    As for performance, I think that at least in theory the JavaVM must be able to perform better as any compiled program, the reasons for that are discussed in many articles, available on the net, so there is no need to repeat them here.

    Yeah, for the last decade I read most of these papers (or rather tons of paper πŸ˜‰ ).

    The thesis advocated by the authors looks like:

    Proposition. Provided the application runs infinitely and the amount of memory is not bound, dynamic optimization will smoke static one, sooner or later.

    The server environments were typically considered as a good approximation of that (ideal) model in the real world.

    My point is that none of the published papers presented a serious comparative study or other experimental results that could confirm the proposition.

    I?m not going to argue that AOT works better and I don?t believe that JITs are unbeatable either.

    One thing is undoubted though: runtime profiling substantially saves compilation time while delivering not so bad performance as a result of dynamic compilation. That?s true for a wide range of JITs, from HotSpot for Java to tree-tracing JITs for JavaScript, etc.

    But that?s about the cost/benefit balance not about AOT compilation.

    I talk a lot. Thanks for your attention.

    –Vitaly

  4. Nikita Lipsky Says:

    I can?t resist to response too πŸ™‚ (I am Excelsior technician but not CTO)

    We started Excelsior JET project when ?Java? and ?slow? were almost synonyms. And it was reality. Now it is just a myth but I still meet people who believe it. Honestly, we started the project to make it myth and we were not alone in this battle. Surprisingly for us during the battle another myth was born: dynamic compilers are always better than static ones in terms of performance. But let me try to show that it is just yet another myth.

    Let us consider classical analysis called “escape analysis”, that can be employed, for instance, for allocating objects on the stack in Java. It has been recently implemented in HotSpot but it’s been in Excelsior JET for ten years. Yes, speculative method devirtualization can help escape analysis greatly, and this is the point where dynamic compilers are advance, but the real problem is the analysis complexity and this is the point where static compilers are advance.

    Really, a straightforward implementation of escape analysis does not scale well, so the possible trade-offs are to handle limited cases (this is HotSpot way) or to address the problem by engineering a sophisticated system that covers common cases when it is theoretically possible to prove that object does not escape (this is Excelsior JET way).

    The last way required us to store the intermediate results to the hard disk just to not eat all available memory instantly and provide reasonable compilation time. Can you imagine that dynamic compilers would ever use the hard disk to optimize your program? I bet, they would not.