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

["Tuomas Leikola" <tuomas dot leikola at digia dot com>]

From: "Tom Tromey" <tromey@redhat.com>
To: "Tuomas Leikola" <tuomas.leikola@digia.com>
Cc: <java@gcc.gnu.org>
Sent: Thursday, January 24, 2002 7:20 PM
Subject: Re: about non-compatible optimization (was: Re: patch to bring java
vtables closer to g++ abi conformance)


> >>>>> "Tuomas" == Tuomas Leikola <tuomas.leikola@digia.com> writes:
>
> Tuomas> this leads to another issue, is it planned that gcj would
> Tuomas> support "closed world" optimizations?
>
> As far as I know nobody is working on it.  I think it would be a
> useful addition.

in java, definitely. closed world -> no dynamic class loading -> possibly no
dynamic init

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.

> Tuomas> but compiler can "notice" many cases like this, like
>
> Tuomas> Vector a = new Vector();
> Tuomas> while (a.size() < 10)
> Tuomas> {
> Tuomas>     a.add("");
> Tuomas> }
> Tuomas> the dynamic invocations could be avoided.
>
> Type-based optimizations like this are one thing I hope to get out of
> the `ast' (tree-based optimization) work being done.  Another
> optimization in this category is removing redundant cast checks.  I've
> looked at the ast code a little, but I haven't done any hacking on it
> yet :-(

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.

of course the vtable pointer is usually cached in loops etc, but i would not
trust the compiler to remember such things for entire arrays etc.

i just wish the tree optimizer was java so i could help with it :(

 - tuomas