[kaffe] Optimization?

[Dalibor Topic]

hi Jukka,

--- Jukka Santala <jsantala@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.

>From what I've seen from fiddling with jopt and jarg
small size comes from deleting all debug information,
renaming private fields, methods and classes to single
letters, removing unneeded constants, and a few
bytecode optimizations. ;)

A JDK 1.1 "profile" of the class library would be
nice,
like the whole profile idea anyway. Since some library
code uses 1.2 features like reflection to do its work,
it
could be painful to create a "pure JDK 1.1" version of
the class libraries. But 1.1 with a few sparks of 1.2
should
be feasible.

> > Regarding benchmarking: I would still like to see
> it
> > coming to kaffe.org, you just need to push me
> harder
> > ;) I've taken a look at ashes, and it kind of
> works
> 
> Well, the generic idea was to have contributors run
> it on their platforms,
> so I really have mostly myself to blame for not
> having that ready. Altough
> mostly, we didn't settle on what kind of benchmarks
> to run on it. It still
> seems some standard open-source benchmark(s) would
> be preferable;
> application-specifics are always good, but there may
> be less agreement on
> what is pertinent, and in the end it won't work to
> require every
> contributor benchmark every possible application
> others are using Kaffe
> for. But I do suggest at least XML processing be
> included, as it has
> become standard part of Java, and is a rather heavy
> test. Maybe we can
> include some docbook benchmark or the like.

Sounds good enough. Do you have any specific
benchmark in mind? I'll take a look at XSLTMark.

cheers,

dalibor topic


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com