The first-ever release of Excelsior JET for Linux/ARM is rapidly approaching the end of what we informally call a “release period”, or RP for short. Roughly speaking, it is the period between the feature freeze and general availability dates of a new product version. During an RP, all Excelsior JET developers turn into part-time testers. Of course, most of the JCK and many other tests run in unattended mode, plus we have automated many interactive tests, but still there are some real-world applications and scenarios that have to be tested manually.
From one such test scenario a company tradition stems: on the very last day of a release period, when all other tests have passed, the Excelsior JET team plays natively compiled Jake2, a Java port of the open source Quake2 game engine, in multiplayer mode, of course. This time, however, we have a new platform – Linux/ARM, so we were not sure whether Jake2 will work there at all. Turned out it does work – here is a screenshot of Jake2 running on a Raspberry Pi 3 under 32‑bit Ubuntu MATE 16.04:
Of course, the FPS rate on the Pi fluctuates between 8 and 10 — quite low compared to the 70-80 range observed on a decent Intel PC, so whoever gets to play on that system will be seriously handicapped…
Categories: Embedded, Excelsior JET
Tags: ARM, compatibility, desktop, performance
Our very own Nikita Lipsky, one of the “fathers” of the Excelsior JET project, was at the JavaZone conference in Oslo last week to give a talk about Java AOT compilation. Here are the video and slides of his talk:
Categories: Java, News
Tags: deployment, Java, JVM, performance, protection, startup time
Over the years, Sun and Oracle engineers have developed so many different garbage collection techniques for the HotSpot VMs — from Uniprocessor Train GC algorithm to Parallel Scavenge to (incremental) Concurrent Mark Sweep to Garbage First — that Oracle had to deprecate certain combinations in Java 8 and will remove them in Java 9. And all these techniques have dozens of tuning options.
Meanwhile, our Excelsior JET JVM have always had a single hybrid garbage collector, roughly defined as incremental concurrent-mark parallel-sweep compact. We've also deliberately kept the number of tuning options to a minimum. Customers can attest that our approach is good enough for many real-world scenarios, and appreciate the simplicity of configuring our GC.
The above does not mean we have not been working on anything better. The number of available garbage collectors will double in Excelsior JET 10.5, to be released in early February.
Meet the CoreBalance™ Garbage Collector
We have designed the all-new CoreBalance™ GC from the ground up to utilize multi-core CPUs. The result is shorter “stop-the-world” pauses and overall reduction of garbage collection overhead:
We have posted a public beta of Excelsior JET 10.5 to our web site today, so you can try out the new GC.
Categories: Excelsior JET
Tags: beta, early access, garbage collection, JVM, performance
Even though the primary focus of Excelsior has always been on programming languages and their implementation – compilers, managed runtimes (JVM), tooling, etc., our Professional Services Department also offers Java consulting and undertakes long-term application development projects. One such project involved a large distributed system for enterprise email filtering and archiving. The system was implemented in Java and works on top of JBoss, with a large number of automatically scheduled tasks.
At some point the system experienced severe performance deterioration during massive import of email messages. However, our ability to diagnose the problem was substantially undermined by the fact that literally thousands of concurrent threads were running when the problem manifested itself. Isolation of the respective code portions into separate applications was not possible either. A really advanced performance analysis tool was needed.
Read the rest of this entry »
Categories: Tools We Use
Tags: Java, performance, tool, webapps
Some time ago, JetBrains introduced a free edition of its brightest Intellij IDEA IDE. Excelsior used this opportunity to native compile and package this edition of IDEA with Excelsior JET and made the compiled version freely available.
We have been working with the native compiled IDEA for a few months and found one major distinction: long lasting GC pauses no longer appear when using the IDE.
Try it yourselves: Intellij IDEA
9.0.310.5.2 Community Edition is available for download at Excelsior JET Application Gallery!
Develop with pleasure!
Note for IDEA plug-in developers.
To compile and run your own plug-ins to IDEA, copy two directories
from the original installation to native compiled one. We did not include these IDEA jars in the native package because they are not needed to run the pre-compiled IDE. However, the original classes are required for plug-in development, which can be enabled by simply copying the above directories.
Categories: Excelsior JET, Java
Tags: Java, performance
The recently issued Excelsior JET 7.2 was, in essence, a maintenance release, because the Excelsior Java team is now mostly focused on the development of the 64-bit version of Excelsior JET. Nevertheless we have managed to include one major feature in this release – Startup Accelerator.
Combined with Startup Optimizer available in previous versions of Excelsior JET, it delivers a noticeable improvement in Java applications startup time. We have prepared a short comparative study backing this statement:
Java vs Native vs Optimized Java
The following startup time comparison includes different RSS feed readers: two native Windows applications (FeedDemon and FeedReader) and one implemented in Java (RSSOwl). The latter was run on the standard JRE 1.6.0_20 and then compiled with Excelsior JET 7.2 Professional Edition/profile 1.6.0_20.
These applications were run on a mid-range laptop (dual-core ULV Intel Celeron SU2300, 2GB RAM), and their warm and cold startup times measured as the time to fully display the main window.
As you can see, the RSSOwl application optimized with Excelsior JET starts:
- 2x to 3x faster than on the JRE
- about as fast as the similar native applications
Java Startup Time solution page: optimization guidelines, FAQ
Excelsior JET: product info
Categories: Excelsior JET, Java
Tags: Java, performance, startup time
We have donated free Excelsior JET licenses to the SimuLab project, aimed at creating an open source flight simulator. They were apparently impressed by the performance of the native build:
- CPU peaks (highest cycle consumption): JRE 62%, JET 53%
- Memory: JRE 227MB, JET 133MB (highlighting mine – DL)
- Startup: not measured but JET outperformed the JRE BY FAR as expected.
If you are passionate about flight simulators and Java, check out SimuLab and consider contributing some of your spare time or money (does anyone in today’s world still have any of these?)
If you are already working on an interesting non-commercial Java app and feel that the use of Excelsior JET might benefit its end users, feel free to apply for a free license.
Categories: Excelsior JET
Tags: memory, performance, sponsored-project
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: performance, protection, Tomcat