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>]

Bryce McKinlay wrote:


>
> I agree "--no-binary-compatibility" should always been an option (and
> perhaps the default for static compilation), much like
> --no-bounds-check. I would like to make binary compatibility the default
> eventually though, assuming the performance impact is shown to be not
> too large and only when it is finished and well tested.
>

this leads to another issue, is it planned that gcj would support "closed
world"
optimizations?

if we know not a single class is to be loaded runtime, there are a number of
optimizations
available, like assuming all classes not extended "final" and inlining (all)
invocations on them.

another issue is a keyword i have been missing in java, "genuine", telling
the
compiler that an instance of a class is not any of its subclasses. sure,
this is error prone if done at source level, but compiler can "notice" many
cases like this, like

Vector a = new Vector();
while (a.size() < 10)
{
    a.add("");
}

the dynamic invocations could be avoided. i don't know if gcj or any
compiler does
this already.

and the issue becomes even worse when using an interface, like List. It
should
be relatively easy to know (at least locally) that the instance of List
referenced
is always a genuine Vector, and inline the method invocations.

i suppose this could lead to really robust optimizations, given static
linking and
monolithic compilation.. however the tree-based optimization would need lots
and lots of work..

i'm dreaming of a case where the compiler would, in the small example i
gave,
that after inlining Vector calls, that in a's Object[], every object would
be either
String("") constant or null, optimize String.length() the same way and so
on. I
don't think any "advanced" JIT can take this kind of optimization all the
way.

sorry i haven't done much research on the issue, these are just thoughts.