This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: .class code optimization
- From: Adam Megacz <gcj at lists dot megacz dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Adam Megacz <gcj at lists dot megacz 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 17:36:38 -0700
- Subject: Re: .class code optimization
- Organization: Myself
- References: <Pine.LNX.4.44.0210111459420.8371-100000@ops2.one-point.com>
Jeff Sturm <jsturm@one-point.com> writes:
> ISTR that Sun's javac once performed optimizations, including inlining
> across translation units. There were problems with it,
IMHO this is a huge crock. Intra-class inlining is still really useful
for non-HotSpot JVMs (as I've mentioned before, especially the MSJVM).
> like unverifiable bytecode: class A inlines method B.b(), but B.b()
> accesses fields private to B, etc.
AFAIK it was smart enough not to inline if the method accessed private
fields. Unfortunately, they ran into problems with versioning --
often people would get incredibly hard to debug errors if they changed
class B but did not regenerate A.class.
Hrm, come to think of this, inter-class inlining could be a big
advantage for gcj. I can't see how a JIT could ever support it.
- a
--
"Through your rags I see your vanity" -- Socrates