[kaffe] Optimization?

[Dalibor Topic]

hi Jukka,

--- Jukka Santala <jsantala at tml.hut.fi> wrote:
> On Mon, 27 May 2002, Dalibor Topic wrote:
> > I, too, would like to see more performance
> > improvements to kaffe's libraries. However, I'm
> not
> > sure if manual method inlining is the way to go.
> Here
> > are my reasons: 
> 
> Yeah, the duplication is something I'm concerned
> with as well,
> particularily as it also means that multiple copies
> of the code need to
> exist in memory, and so some cache advantages could
> be lost. I'm not sure
> duplicating a few critical codepaths in rather
> stable parts of the code is
> all that significant for maintenance, though. In
> fact, some could argue
> that trying to maintain a tangled spaghetti-code of
> nested calls to shared
> methods whose changes could have unforeseen
> consequences to other
> code-paths is harder.

I'll assume that we are talking about private methods
like bucket or find.

When you start manually inlining code you
give up control over it. You no longer know who will
use it, if it gets inlined again and so on. With
shared
methods you at least have the possibility to impose
access restrictions, hopefully reducing the amount
of spaghetti being served around ;)

> And while I concur with the notion of automated
> optimization tools, these
> are blind to application design issues and
> accumulated developer wisdom;
> hence it's usually better to hand-optimize few
> trouble spots, than risk
> things like the aforementioned cache-effects for
> whole code.

Wouldn't it be nicer if the VM did that kind of
optimization automatically? Imagine the following: a
class loader that uses some form of heuristic
to decide to inline bytecode on demand
while loading a class. Since at loading time all
referenced classes need to be resolved, we can
safely inline bytecode in loaded classes.

This would benefit all code loaded by the VM. So
computation intensive application code would be
optimized just like library code.

For even better impact, you could delay inlining of
code until the jit tries to compile it.

> > I'd prefer to see a generic Klasses.jar that
> simply
> > works, and different Klasses.jar's for download on
> > kaffe.org for specific needs: a size optimized one
> and
> > a speed optimized one. Both kinds of optimization
> 
> I'm not sure it would be so significant in the end,
> most people would not
> bother picking one or the other, and often enough
> small size comes with
> speed. Something I've thought of before is providing
> a "JDK 1.1 only"
> classlib for those size-optimization purposes. This
> would require more
> work than simple automated optimization-utilities,
> ofcourse, due to
> differences in the API. But as it is, Kaffe can't
> run full Java2 anyway,
> so most of the Java2 specific things are dead weight
> when it's being used
> to primarily run JDK1.1 code.