[kaffe] Freeing jit temp data on demand (Was: Re: JavaLayer 0.3.0 works)

Dalibor Topic robilad at kaffe.org
Wed Sep 17 13:01:02 PDT 2003

Hi Tim,

thanks for the quick patch! I tried it, but unfortunately, now kaffe 
crashes when I try to play a mp3.

bash-2.05a$ kaffe -cp jl030.jar javazoom.jl.player.jlp /var/tmp/GutenRMX.mp3
playing /var/tmp/GutenRMX.mp3...
kaffe-bin: ../../../../kaffe/kaffe/kaffevm/jit3/machine.c:221: 
translate: Assertion `reinvoke == false' failed.

here's the backtrace from gdb:

bash-2.05a$ KAFFE_DEBUG=gdb kaffe -cp jl030.jar javazoom.jl.player.jlp 
(gdb) run
Starting program: /tmp/topic/current/jre/bin/kaffe-bin -cp jl030.jar 
javazoom.jl.player.jlp /var/tmp/GutenRMX.mp3
playing /var/tmp/GutenRMX.mp3...

Program received signal SIGSEGV, Segmentation fault.
getLastEpilogueLabel () at ../../../../kaffe/kaffe/kaffevm/jit3/labels.c:87
87                      if ((l->type & Ltomask) == Lepilogue) {
(gdb) bt
#0  getLastEpilogueLabel () at 
#1  0x40074102 in epilogue_xxx (s=0x83fc74c) at 
#2  0x4009100f in generateInsnSequence (einfo=0xbfffe10c) at 
#3  0x40090a15 in finishInsnSequence (dummy=0x0, code=0xbfffe08c, 
einfo=0xbfffe10c) at ../../../../kaffe/kaffe/kaffevm/jit3/machine.c:473
#4  0x400907f7 in translate (xmeth=0x83ce990, einfo=0xbfffe10c) at 
#5  0x4004f719 in soft_fixup_trampoline (_data=0x83d41d9) at 
#6  0x4009186a in i386_do_fixup_trampoline () at 
#7  0x40053632 in callMethodA (meth=0x83ce990, func=0x83d41d4, obj=0x0, 
args=0x0, ret=0xbfffe16c, promoted=0) at 
#8  0x40044daf in Kaffe_CallStaticVoidMethodA (env=0x8122018, 
cls=0x83b921c, meth=0x83ce990, args=0x0) at 
#9  0x40025e53 in processClass (class=0x83b921c, tostate=13, 
einfo=0xbfffe59c) at ../../../kaffe/kaffe/kaffevm/classMethod.c:578
#10 0x4004eb2d in soft_new (c=0x83b921c) at 
#11 0x083d3a8b in ?? ()
#12 0x083ca0ea in ?? ()
#13 0x082e82ee in ?? ()
#14 0x082e446f in ?? ()
#15 0x40053ae2 in callMethodV (meth=0x8280010, func=0x818cfb4, obj=0x0, 
args=0xbfffeb44, ret=0xbfffe9a8) at ../../../kaffe/config/i386/common.h:38
#16 0x40044bd6 in Kaffe_CallStaticVoidMethodV (env=0x8122018, 
cls=0x827099c, meth=0x8280010, args=0xbfffeb40) at 
#17 0x40044c87 in Kaffe_CallStaticVoidMethod (env=0x8122018, 
cls=0x827099c, meth=0x8280010) at ../../../kaffe/kaffe/kaffevm/jni.c:2428
#18 0x0804908d in main2 (env=0x8122018, argv=0xbffff204, farg=4, argc=1) 
at ../../../kaffe/kaffe/kaffe/main.c:325
#19 0x08048e1b in main (argc=2, argv=0xbffff204) at 
(gdb) p l
$1 = (label *) 0x0

it looks like it uses an uninitialized label.

To reproduce the crash you'll need javalayer 0.3.0 from 
and some mp3 file, I used http://helden.warenform.de/swf/GutenRMX.mp3 .

dalibor topic

Timothy Stack wrote:
>>Timothy Stack wrote:
>>>>The memory usage seems to come from
>>>>jit-temp-data: Nr    179  Mem   8980K, which doesn't get freed as it 
>>>>should be, so it's impossible to run with less then -mx 16M. I think the 
>>>>gc should try to free jit temp data when it runs out of memory. Tim, 
>>>>Helmer, what do you think?
>>>The GC doesn't track this, its kept around in a pool which isn't freed if 
>>>it passes some threshold.
>>So it would require either a change to the gc to track it (which I 
>>though it did, since the (re/de)allocations already happen through the 
>>gc interface) or a change in the jitter (jit3) to free temp data when 
>>it's not needed any more (after jitting a method? after a certain period 
>>of time?), right?
> I've changed it to free most of the pool after the jit has completed, can 
> you cvs update and give it a go?
>>dalibor topic
> thanks,
> tim

More information about the kaffe mailing list