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

[Timothy Stack]

On Saturday, September 20, 2003, at 10:47  AM, Helmer Kr=E4mer wrote:

> On Fri, 19 Sep 2003 11:40:07 -0600 (MDT)
> Timothy Stack <stack@cs.utah.edu> wrote:
>
> Hi Tim,
>
>>> Okie, I've duplicated the problem, the gc is getting stuck and that=20=

>>> eats
>>> up all the CPU.  In particular it gets stuck in startGC() looping on=20=

>>> the
>>> finalizer list.  I tried backing out helmer's last changes to the GC=20=

>>> and
>>> it seems to run fine again, but I'm not really sure where the bug is=20=

>>> just
>>> yet.
>>
>> okie, the offending diff seems to be in gc-incremental.c:
>>
>> @@ -639,7 +663,6 @@
>>  startGC(Collector *gcif)
>>  {
>>  	gc_unit* unit;
>> -	gc_unit* nunit;
>>
>>  	gcStats.freedmem =3D 0;
>>  	gcStats.freedobj =3D 0;
>> @@ -663,9 +686,8 @@
>>  	startTiming(&gc_time, "gctime-scan");
>>
>>  	/* Walk all objects on the finalizer list */
>> -	for (unit =3D gclists[finalise].cnext;
>> -	     unit !=3D &gclists[finalise]; unit =3D nunit) {
>> -		nunit =3D unit->cnext;
>> +	while (gclists[finalise].cnext !=3D &gclists[finalise]) {
>> +		unit =3D gclists[finalise].cnext;
>>  		gcMarkObject(gcif, UTOMEM(unit));
>>  	}
>>
>>
>> Restoring the old version makes things work again, is this important=20=

>> for
>> the leak problem you found?
>
> I'll try to get tritonus up and running and will respond
> once I can reproduce the problems (tritonus refuses to
> play any sound :( ).

Fortunately, they have a fair amount of debugging built in.  One=20
problem i ran into was that the libraries aren't linked into the=20
executable, so it won't work if you try to do static linking.  I've got=20=

the fix in my tree, just need to check it in.

> Regards,
> Helmer

thanks,

tim