Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling)

[Dalibor Topic]

Hi David,

David Lichteblau wrote:
> Quoting Dalibor Topic (address@hidden):
>
> > h) re-use the StringBuffer on the stack
> >
> >  Rationale: In order to write as efficient code using StringBuffer as 
> > the good Java compilers, we need to reuse the StringBuffer instance on 
> > the stack. So instead of writing multiple append statements, try to use 
> > a single statement to perform all the work on the StringBuffer instance, 
> > including creation, calling append, and calling toString() on it.
>
>
> That would only help with interpreters, right?  Nothing a good JIT does
> not handle for you.

I doubt that it only helps with interpreters. I'd assume that it also 
helps with kaffe's JIT, for example. But every little bit helps ;)

Basically, you want to have a JIT that rewrites

  sb.append("something");
  sb.append("else");

into

  sb.append("something").append("else");

In order to do that, the JIT would have to infer that 
StringBuffer.append(*) *always* returns a reference to the same string 
buffer instance it was invoked upon in that code path.

as in :

[sb on stack]
[call append]
[hey, that's sb on stack again, cool!]

Which means you either hardcode the optimisation into the JIT (which is 
possible since StringBuffer is a final class), or do some bytecode 
analysis on side-effects of StringBuffer.append() (i.e. does it return 
'this' on all code paths). I don't know how hard the second approach is.

In any case, the question is: can we assume that VMs using GNU Classpath 
have good JITs? I think the answer is 'No', despite the great 
performance of some VMs using GNU Classpath. Some VMs using GNU 
Classpath have no JITs, some have JITs that aren't state-of-the-art.

On a side note, I would have loved to assume that VMs using GNU 
Classpath have fast reflection implementations, which would have allowed 
me to use the generic, reflection based method outlined in the first 
proposal. But being a project that's used by multiple VMs, I think GNU 
Classpath has to care about the lowest common denominator. Which means I 
can't assume that some bytecode optimizer will take care of performance 
of my code ;)

cheers,
dalibor topic