The problems with StringBuilders...

Bryce McKinlay
Wed Oct 5 17:50:00 GMT 2005

David Daney wrote:

>> Right, and the JET paper suggests that they know a lot about how all
>> the system classes behave.  That might be the key to most of the
>> performance improvement -- you're not alowed to replace system
>> classes, and many of them are final, so...
> ... Any call to any method in java.* could be inlined or converted 
> into a call to an equivalent but more effecient implementation.  
> Further more, code analysis can be done to see if it is safe to use 
> vastly simpler implementations.  

You can only do this if you make some closed-world assumptions. 
Certainly for things like Math.*, the methods are simple enough and 
well-defined enough that they can be trivially inlined - and we already 
do this. But for the general case, its not possible to inline java.* 
methods without breaking binary compatibility rules, and thus 
disallowing the code from running on a newer version of the runtime.

JET can probably do better here because it builds the JRE into the 
application binary rather than separating the application from the 
runtime as we do. If you assume a static, unchangeable runtime, then you 
can do much more with optimization - but you also get much larger 
binaries, and lose a great deal of flexibility.

Even if you know the implementation won't change, java.nio.*Buffer is 
still tricky case (again, assuming a non-closed world) because it is 
abstract. Unless you know exactly how the Buffer was allocated, you 
can't guarantee that the Buffer passed to a given method will actually 
be the runtime's implementation. We'd have to implement Buffer.get() 
something like the following:

if (bufobj instanceof GCJByteBufferImpl)
  { .. inlined get() implementation... }
  call bufobj.get()

In a simple implementation, the bloat would probably eliminate much of 
the benefit from avoiding the call. However, where buffer calls occur in 
a loop, and bufobj is invariant, this could be improved by compiling two 
separate copies of the loop and doing the instanceof just once to select 
which one to execute.


More information about the Java mailing list