On Thu, Jul 31, 2008 at 8:40 AM, Andrew Overholt <overholt@xxxxxxxxxx> wrote:
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.
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.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
