Michael said:
The second option was done long ago, originally for Fedora.
It would be the best if Eclipse.org just moved up to tomcat5. The more
debian's eclipse deviates from upsteam the more of a pain it is on both the
debian maintainer and on upstream.
Off topic but just to throw this out, this would seem to be the best (in
terms of speed) theoretetical JVM:
This a a merged static and dynamic compilation system that gains speed in
echange for a (slight?) increase in processor usage, resource usage, and
diskspace usage.
A static compiler that can optionally embed code for profiling which can
then be used for later static recompiling, which would re-optimize based on
the code paths most used (think like what gcc can do with '-fprofile-arcs').
The static compiler would also optionally be able to embed enough
information to allow the dynamic ahead-of-time compiler (no, that is not a
typo, read on) to re-optimize.
The resulting binaries would be linked to a dynamic compiler. The dynamic
compiler would be able to JIT compile java code as is needed. The resulting
native code would be cached, and stored to disk. While the program is idle
the dynamic compier can perform ahead-of-time compilation of bytecode, as
well as reoptimize the existing machine code it generated based on profiling
information, as well as staticly compiled code that had the nessesary
information embeded. (In the case of the native code geneated by JIT that
information is can be gleamed from the original bytecode, which is not the
case with staticly compiled code, so any needed information would need to be
embeded.)
Obviously the dynamic compiler could also be used to run java code directly,
and an interface for doing so should be provided.
(This mostly describes 'Excelsior JET', although I'm not sure that that
system supports dynamic reoptimization of the executables generated by the
static compiler.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
