Re: GCJ Native Proposal
On Tue, Mar 15, 2005 at 09:24:30AM -0500, Barry Hawkins wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jerry Haltom wrote:
> [...]
> | The main
> | motivation for this is speed. There is no JIT overhead involved and it
> | runs native, not interpreted. It is worth noting that the Kaffe folks
> | want to integrate support for this binary interface into Kaffe.
> It must be underscored that this is a _potential_ speed gain. We
> actually are not certain what speed gains, if any, we will have.
>
> If we are honest with ourselves, a second and quite powerful motive is
> our desire to get Eclipse into main, and that really only serves a
> handful of the Debian community at large. All of the Debian policy and
> developer docs encourage us to not just think about our packages, but
> about the whole project. Is this really something that reflects good
> stewardship on our part? I think we have to think that one over.
> [...]
> | This begs the question then: How do we make these native .so files
> | available in our packages to our users. A number of ideas were
> | considered:
> |
> | a) Include the .so along with the .jar in the same deb.
> | b) Create a separate package for the .so.
> |
> | The first one (a) can be discounted because it would convert every Java
> | package into a binary: arch package. This isn't feasible for obvious
> | reasons: we like archive space!
> [...]
> Approach b) is the only one that seems feasible, and I would only
> recommend doing it on a few packages experimentally to see if the
> hoped-for speed gains merit the considerable increase in resource
> impact. A third option I would also posit is:
>
> c) Take a deep, hard look at what is broken with JIT in the free
> runtimes right now and how we could significantly contribute to that
> part of free java that really needs help.
>
> Iterpreted languages hardly need me to back them up, but I think they
> have a proven track record. Taking one of the leading interpreted
> languages and choosing to make its use of native compiled binaries as a
> de facto for our distro just doesn't sit well with me.
You are right, its not always a gain. Tom Tromey told me that he is
aware of one case where the native library is slower then interpreting
the jar.
Doing (c) and fixing JIT runtimes can be good, but it ist a hard work
too. The Kaffe people put much efforts into this. JIT works find on i386
but not at all on powerpc for them. Same mixture for all the other
Debian archs. When Kaffe supports the BC-ABI too this will be huge gain
after all as it is surely be faster then non-JITed bytecode. The idea is
make the code reuseable to other VMs can adopt it too.
We have now 3 possibilitiest:
1) compile all to native
2) compile a selected group of jars to native
3) dont compile to native at all and decide later
In current stage we should go for either (2) or (3) and we should proove
that its a gain. Otherwise we just waste archive space for no gain which
is stupid.
Michael
--
Java Trap: http://www.gnu.org/philosophy/java-trap.html
Reply to: