Re: Current status of your swt-gtk package
On Tue, Oct 18, 2005 at 04:55:07PM -0400, Joe Smith wrote:
>
> 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.
We used tomcat5 when packaging Eclipse 3.1(.1) as its the only version
we can bring into Debian main. Upstream still uses tomcat4 due to some
reasons. We cant from the legal point of view.
> 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.)
Excelsior JET is not free we cant use it. If you want somethink like
this to be used for eclipse please start reading the GCJ mailing lists
and start hacking on it. There is much stuff to do before we can even
think about your proposal. As always patches are welcome. ;-)
Cheers,
Michaeö
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Reply to: