This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: .class code optimization
- From: Tom Tromey <tromey at redhat dot com>
- To: Adam Megacz <gcj at lists dot megacz dot com>
- Cc: Jeff Sturm <jsturm at one-point dot com>, Andrew Haley <aph at redhat dot com>, Lapo Luchini <lapo at lapo dot it>, <java at gcc dot gnu dot org>
- Date: 11 Oct 2002 18:38:50 -0600
- Subject: Re: .class code optimization
- References: <Pine.LNX.4.44.0210111459420.8371-100000@ops2.one-point.com><864rbsbii1.fsf@nowhere.com>
- Reply-to: tromey at redhat dot com
>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:
Adam> Hrm, come to think of this, inter-class inlining could be a big
Adam> advantage for gcj. I can't see how a JIT could ever support it.
What difficulties do you forsee?
It seems to me that if your JIT already has recompilation
capabilities, like HotSpot, then you could just inline the first time
a method is called (you probably wouldn't really do this, but it is
one way to reason about the problem). Whether the method is in the
current class or some other class wouldn't seem to matter much.
With gcj cross-class inlining will always have to break Java binary
compatibility. With a JIT this isn't so.
Tom