>
> >>To add another reason why nobody should draw conclusions quite yet:
> >>Kaffe's benchmarks were obtained with a version of its class libraries
> >>that was compiled with jikes, which is often considered to create
> >>the slowest bytecode among the different javac compilers.
> >
> >Is it? Can you point me towards some info about this issue with Jikes.
> >I'd like to read more about it.
>
My statement was based on examining the jikes bytecode while fixing
some of the problems it caused for kaffe. I saw lots of nops and
aload/aload pairs where a aload/dup would have been better, and lots
of gotos jumping to the next instruction etc. Basically the kind
of stuff that simple bytecode optimizers would fix.
Before anybody draws conclusions: this was with jikes 0.x (forgot which)
and time has passed since.
Secondly, the whole thing is dubious anyway since these differences
disappear for most jit compilers anyway, as Matt pointed out.
Only interpreters and such jits that perform peephole translation (such
as kaffe) might be affected by this to a certain extent.
Also, I'd like to add that I've observed in more than one
occasion that jikes was the only javac compiler who'd produce the correct
bytecode for certain constructs (for example interface dispatch, constructors
of inner classes) I've also seen warnings coming from jikes where it
would say something to the effect: "It is unclear whether we should
allow what you coded... awaiting clarification of JLS". I thought that
was rather cute.
- Godmar
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
