kaffe hungs (code attached)

[Dimitris Vyzovitis]

Godmar Back wrote:

>  Dimitri,
>
> Kaffe 1.0b3 doesn't really hang on this test, it just takes a very long time.
> The reason was that the long array for the BitSet was grown bit by bit, so
> the test ended up being a gc stress test as lots and lots of long arrays had
> to be created and discarded.

Right.
I think I just wasn't patient enough for it ;-}.
I don't know how, but it took more than 7 mins in my PII/350/256M machine
Anyway, I suspect that the BitSet implementation needs some (err... make that a
lot) optimization/tweaking.


> At this point, I believe that kaffe/jit is performance-wise on par with
> jdk1.1.7/intr on Linux for *real* applications; in some cases it's even
> better than jdk1.1.7/tya.
>
> For instance, for the "sieve" toy benchmark that comes with tya, Kaffe
> gives me a 555 score while TYA1.2v4 shows 436.  Since sieve tests only
> the quality of the generated code, Kaffe's poor showing for Dimitri's
> benchmark leads me to believe that other reasons may be dominating here,
> such as differences in the speed of the run-time libraries (i.e., BitSet)
> or differences in how stack overflow checks are implemented etc.
>

In principal (at lest for normal applications), kaffe is at least as good as
sun's jdk (and I bet it will be better in the future, although blackdown does
really *good* job in porting).
A minor problem, is that it doesn't support some deprecated 1.1 features, which
breaks applications that rely on older code (e.g. from personal experience,
awt.TextArea.appendText is not supported).
The point is that we need to stress test it in every possible aspect, so that it
becomes the *best* vm available (OK, there is a long way to go) . The message is
make java really free, not sun's precious property ;-}


>
> b) want to compile your run-time libs with the fastest compiler available.
>    (Hopefully, this will soon be gcj)

but for the moment it is jikes (at least in my opinion).

Dimitris