Jump to content
Excelsior Forums
Sign in to follow this  
thexder

JRE-indepencency of Jet 3.7

Recommended Posts

I always understood Jet in that way, that i may compile everything into a deployable executable without the need of any JRE.

Thats what I would call JRE independency.

With Jet 3.7 there is a top statement saying that "JRE-independent deployment for J2SE 5.0 is not possible".

Do i get this right that I need a J2SE 5.0 JRE to run my J2SE 5.0 Java applications compiled with Jet?

And that all previous J2SE 5.0 applications do not have the need for a JRE?

Share this post


Link to post
Share on other sites

Hi,

I was wondering whether you guys at Excelsior are planning to go on writing your own native methods in place of those included in the Sun JRE (which as I understand was what granted JRE independence for Java versions prior to 5.0), or whether you have decided to make use from now on of Sun's native methods (which would require much less effort on your part, I think).

Another question: how can Just In Time compilation ever be faster than Ahead Of Time compilation?

Thanks.

Share this post


Link to post
Share on other sites

I was wondering whether you guys at Excelsior are planning to go on writing your own native methods in place of those included in the Sun JRE (which as I understand was what granted JRE independence for Java versions prior to 5.0), or whether you have decided to make use from now on of Sun's native methods (which would require much less effort on your part, I think).

We will use our native methods partially. There's no sense to write e.g. AWT native methods from scratch.

We plan to provide JRE-independence in the next versions using Sun Community Source License (Commercial Use).

Another question: how can Just In Time compilation ever be faster than Ahead Of Time compilation?

Do you mean performance of running application, not the compilation itself? Please, refine.

Share this post


Link to post
Share on other sites

Yes, I mean the performance of the application. In the "Myths and Facts" section of your website (Myth 3), there seems to be stated that in some cases running an application with a JIT compiler will give better performance than running the same application, compiled ahead of time.

How is this possible, since in the first case the application has to be compiled+run, while in the second case it only has to be run?

(Can the advantage of knowing the configuration of the machine on which the application is running possibly make up for the extra time spent compiling? Seems unlikely to me...)

Share this post


Link to post
Share on other sites

One possible reason is that some optimizations that could be implemented in the JET compiler, are not yet implemented.

For example, there's much room for improvements in performance of floating point computations. It will be necessarily done in future versions of the JET VM.

-----------

In general, a dynamic compiler has more infromation 'bout the running program so in some cases it can optimize hot code better.  It can be seen on some artificials microbenchmarks. As for real applications, it's very hard to figure out what's the pure impact of the gathered profile information on the resulting performance.

Two years ago, we conducted experiments with exploiting profile info gathered at run-time for subsequent static compilation with JET. It proved to be useful for some applications but did not affect performance radically. However, we should revise those results with the current version of the JET compiler, of course.

The main conclusion we drawn from the study is that most important aspect that helps dynamic compiler to work effectively is selective compilation of hot methods. This way, they save time for dynamic compilation. Note that the static compiler considers all methods "hot" and optimizes them at the highest level.

Nevertheless, in future versions, we plan to implement two-step compilation: on the first run, profile information is collected and then it's used for optimizations.

BTW, it's interesting  that contemporary C/C++ compilers has recently taken this approach. Such a compilation mode is now present in Intel Reference Compiler, MSVC and the Sun UB compilers for C/C++ and Fortran 90.

Take care,

--zz top

B)

Share this post


Link to post
Share on other sites
Sign in to follow this  

×