[kaffe] Test fail for m68k/linux

[Dalibor Topic]

Kiyo Inaba wrote:
> I said,
> 
>>The latest weekly test failed for m68k/linux.
>>The fail files say everything is timeout and earlier snap does not have this problem.
> 
> 
> This is not true, at least for jit3. Just become much SLOWER :-<
> 
> For 050421 snap, 'time $JAVA HelloWorldApp' tells,
>     real    5m8.022s
>     user    1m52.930s
>     sys     0m16.640s
> but for 050428 snap, it tells
>     real    11m33.120s
>     user    5m11.830s
>     sys     0m20.880s
> 
> Since this mac is now compiling snap for intrp, and the 'real' may be slightly
> slower than an idle machine.
> 

Hi Kiyo,

thanks for the bug report!

Is there any chance of comparing the two profile outputs for the 
different snapshots to see where the time went? Looking at the list of 
changes in that week, it seems that the major changes were the 
integration of (and switch to) the nio charset handling from GNU 
Classpath, and Double/VMDouble (inclding fdlibm) merge. I'd guess that 
the former might be a cause for the delay you observed, but it would be 
interesting to see if measures can confirm it.

My assumption would be that writing more of the core class libraries in 
java penalizes the slower CPUs much more than it does so on fast CPUs. 
Going from that assumption, I think there are a few things one could do 
to improve performance on smaller machines, beside making the jit better. :)

1) update the gcj bindings to 4.0 so that we can use a prebuilt 
rt.jar.so file, and don't have to jit everything. I believe Transvirtual 
had some good success there with mips-based devices and their gcj fork.

2) Improve the interpreter, by getting the changes from ertl (jim huang 
posted a patch for that, afaik), and latte merged in.

3) Merge in a mixed mode engine patch from latte. Mixed mode probably 
only works well if the interpreter is not too slow, as the first 
mixed-mode attempts with kaffe found no imrovement over just using the jit.

cheers,
dalibor topic