Re: The problems with StringBuilders...

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > > > This is a problem with the GCJ approach.  We have this nice binary 
 > > > compatibility feature, but you have to disallow a wide range of 
 > > > optimizations in order to use it.  The JIT compilers (like Sun's 
 > > > HotSpot) can do these things because they know everything at run/compile 
 > > > time (as runtime and compile time are the same thing).
 > >
 > >No, that really isn't true.
 > >
 > >In a JIT compiler, when you devirtualize and inline you have to assume
 > >that you know everything about the program, in particular that a
 > >method you just inlined isn't about to be overridden by a subclass.
 > >But you don't, because at any time a ClassLoader can come along and
 > >create a new subclass of one of the classes you just inlined, and your
 > >assumptions are no longer true.  So what do you do?  The ClassLoader
 > >has to signal the runtime that the world has changed, and you have to
 > >fall back to the non-inlined version of the code.  This is *exactly*
 > >the same with ahead of time compilation.  We can do optimistic
 > >optimization in gcj and fall back if we have to, just like a JIT.
 > 
 > Its not quite the same. One difference is that in an AOT compiler, we 
 > have nothing to fall back on but the interpreter.

No, that's not true.  We just fall back to a generic version of the
method.

 > In an AOT, however, we are flying blind - there is no reliable
 > knowledge of what classes will be encountered at runtime, so
 > there's a high chance than any given devirtualization optimization
 > will have to be thrown away at runtime.

There's a chance, yes.  But I suspect the probability is, in general,
not high.

 > We could avoid the interpreter-fallback by compiling methods twice
 > - once with and once without virtual inlining and devirtualization,

Of course.

 > but this is wasteful in space, and application performance would
 > degrade over time as dependent libraries get updated,
 > etc. Profile-directed optimization feedback might help, but its no
 > substitute for the knowledge a JIT has.

I don't know why you say that.  Profile-directed feedback is
_precisely_ a substitute for the knowledge a JIT has.  It may be less
reliable in that different runs of an application give different
results, but that's true for a JIT to: previous behaviour of an app
doesn't necessarily predict future behaviour.

 > Also, while devirtualization & inlining of virtual methods are 
 > optimizations that can be invalidated after compilation time even in a 
 > JIT, there are many other optimizations that can be trivially done at 
 > runtime but not at all ahead-of-time. This includes inlining of finals 
 > and static methods, various cases of "direct" dispatch, eliminating 
 > class initialization checks where you know a given class is already 
 > initialized at compilation time, etc.

I don't see why wy can't do these head of time.  Inlining of finals
and static methods is quite practical, as is eliminating class
initialization checks.  There's no great practical difficulty as long
as we have a way to fall back if we need to.

Andrew.