java, possible to package the gcj aot stuff separately ?

[Colin Walters]

On Thu, Jul 31, 2008 at 8:40 AM, Andrew Overholt <overholt at redhat.com>wrote:

>
>
> Yeah, one of the reasons we didn't do this to begin with was because RPM
> has no notion of Suggests or Recommends like dpkg does.  Debian went
> this route, but I've seen reports of people not realizing they needed to
> install the associated -gcj package.
>

I think the long term vision here should be that we actually need *both* AOT
and JIT compilation.

We need a JIT because many apps will continue to load code at runtime from
sources that are not Fedora.  Think unpackaged Eclipse plugins for just a
start.  But with OpenJDK, when I sit there at a Jython toplevel
experimenting with code, it's pretty cool that it's actually getting JITted
down to native code as it runs.  There are also applications that actually
generate bytecode at runtime for various purposes, and that continues to be
a good idea.

A JIT also has a lot more interesting information than a normal AOT model.
Hotspot does a lot of cool things there.

However, one approach is to take a set of runtime profiles from
applications, and feed that back into the compiler:
http://gcc.gnu.org/news/profiledriven.html

As far as I know in Fedora right now we are not taking advantage of runtime
profiles when we compile things in Koji.  I heard though that Firefox can
get up to a 10% speedup by being compiled with the right data; see:
http://developer.mozilla.org/en/docs/Building_with_Profile-Guided_Optimization

It does make sense to have AOT compilation, because having Hotspot
re-profile and recompile the Eclipse core on everyone's computer is a bit of
a waste.
One approach here would be to modify Hotspot so that it can pick up
"precompiled" code fragments shipped in a lookaside cache, based on its own
runtime profiling data.  I'm not sure if anyone has looked into that.

But it's not as simple as saying that AOT is always fast and JIT is always
slow - it really can be the opposite, and AOT compilation for everything can
be a waste of space if the library is not in a performance critical path.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080731/9c841944/attachment.htm>