Re: test if there is a gain

[Tom Tromey <tromey@redhat.com>]

>>>>> "Arnaud" == Arnaud Vandyck <avdyk@debian.org> writes:

Arnaud> As Michael pointed out, we first need to have benchmarks to know if
Arnaud> there are real advantages to compile things to native. Also, we could
Arnaud> make choice: do we need to build the libs and the apps? only the apps?
Arnaud> Which one? Is it more important to build ant then tomcat? gjdoc then
Arnaud> eclipse? I don't know.

There is already a bunch of benchmarking info out there.  This one
seems pretty fair:

    http://www.shudo.net/jit/perf/

Measuring performance is tricky though.  For instance, on the one
hand, the binary compatibility ABI involves a performance hit.  On the
other hand, gcj can use shared libraries, which is a win in certain
situations (but not often looked for in benchmarks).

Arnaud> Now that it is done, we have to think about several problems:
Arnaud> the first is the gain (as Michael pointed), the second is that
Arnaud> when running a native java application, you can relay on a
Arnaud> unique VM (that's also the choice problem Michael pointed
Arnaud> out).

Arnaud> If we choose to build java packages to native, they will relay
Arnaud> *only* on gcj. Let's hope it'll never have RC bugs!

Our goal with the new BC ABI was to make it possible to run java
applications with zero application-level changes.  And, we've
succeeded at that.  One consequence of this is that a "gcj compiled"
application can still be run on any other JVM.

So, for instance, in FC4 we're shipping a gcj-compiled Eclipse.  The
eclipse wrapper just invokes "java", which by default points to gij.
However, you could install a proprietary JVM, change the alternatives,
and the same Eclipse would continue to work just fine.

Tom