The problems with StringBuilders...

Andrew Haley aph@redhat.com
Fri Oct 7 16:52:00 GMT 2005


Bryce McKinlay writes:
 > On 7-Oct-05, at 5:54 AM, Andrew Haley wrote:
 > 
 > >> 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.
 > 
 > Well, you can do that, but it bloats the application pretty  
 > significantly. Binaries are effectively double the size, since you  
 > can't know at compile time which methods will or won't require the  
 > fallback.

In many ways it's a classic space/time trade-off, just like -O3.
However, while binary size will increase, resident memory won't be
very much affected because usually only one version of a method will
be paged in.

 > >> 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.
 > 
 > Immediately after compilation, when the development environment  
 > matches the runtime environment, in many apps the chance is not high.  
 > But any changes/evolution to a library you are building that code  
 > against would invalidate those optimizations. That means that  
 > application performance will degrade over time - updating libgcj, for  
 > example, would mean that all your applications run slower until you  
 > recompiled them.

Sure, but this is of course true for JITs too -- it's just that you
recompile far more frequently!  For minor release updates of libgcj,
the degradation would probably not be noticeable.  For complete
rewrites of some libraries it would be more of an issue.

 > I don't think that is acceptable.

OK.
 
 > >> 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.
 > 
 > A JIT can often eliminate initialization checks trivially because the  
 > class in question is already initialized at compilation time. This is  
 > never true for an AOT, so this optimization is much more difficult.

It's more difficult, yes, given that with a JIT it's trivial.  But in
many cases we can do it.

Andrew.



More information about the Java mailing list