about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)

Tuomas Leikola tuomas.leikola@digia.com
Mon Jan 28 02:15:00 GMT 2002


----- Original Message -----
From: "Bryce McKinlay" <bryce@waitaki.otago.ac.nz>
To: "Tuomas Leikola" <tuomas.leikola@digia.com>
Cc: <java@gcc.gnu.org>
Sent: Friday, January 25, 2002 11:06 PM
Subject: Re: about non-compatible optimization (was: Re: patch to bring java
vtables closer to g++ abi conformance)


> Tuomas Leikola wrote:
>
> >combine that with section-gc (or whatever was the current name) and maybe
it
> >will be finally possible to write small command-line-tools (like
gnutools)
> >in java.
> >
> Huh? Are you suggesting you want to statically link your small
> command-line-tools?

umm.. if they become small enough or i'm using some c64 or something that
doesn't support shared libraries? ;)

>
> Closed world optimizations would certainly be nice in some cases.
> However they also:
>
> - Prevent Java's dynamically extenisbility
> - Prohibit dynamic linking (at least if you want to keep binary
> compatibility)
> - Would require a lot of new compiler infrastructure in order to do them
> well
>

agreed. but then again, closed world means just that.

is libgcj so stable that you can just depend on it and not worry about the
next week? i've seen the ms DLL hell, would consider static linking a ..
compatible solution in the long run :(

> >
> >yes, there are alot more savings in higher level constructs than in
> >assembler level.. optimizing cast check and method lookup seems quite
futile
> >(no offense!) if there are multiple redundant checks.
> >
>
> I agree that eliminating redundant checks is important. However, in many
> cases it is hard (hopefully the ast SSA stuff will make it easier). But
> if you can make a cast check 3x faster, then it is still 3x faster
> regardless of any redundant checks.
>

yes, it's tricky to do in code, simpler to do by hand. i suppose gcj already
does multiple passes on different optimization techniques until no-one of
then can suggest a change?

> I am curious why you mentioned "dynamic invocations" or "method lookup"
> as being slow. It isn't. In fact a virtual method call (in a loop) in
> GCJ is *faster* than a static method call (in Java or C). Try it if you
> don't believe me! Or are you talking about runtime method lookup via
> reflection?
>

my point tried to be resolving interface calls statically, but it seems it's
not as slow as i thought (according to shudo's benchmarks)

 - tuomas




More information about the Java mailing list