[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re:

From: Dalibor Topic
Subject: Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling)
Date: Sun, 30 Nov 2003 18:13:30 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

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




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 ;)

dalibor topic

reply via email to

[Prev in Thread] Current Thread [Next in Thread]