[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ämer wrote:

> On Fri, 19 Sep 2003 11:40:07 -0600 (MDT)
> Timothy Stack <stack at cs.utah.edu> wrote:
>
> Hi Tim,
>
>>> Okie, I've duplicated the problem, the gc is getting stuck and that 
>>> eats
>>> up all the CPU.  In particular it gets stuck in startGC() looping on 
>>> the
>>> finalizer list.  I tried backing out helmer's last changes to the GC 
>>> and
>>> it seems to run fine again, but I'm not really sure where the bug is 
>>> 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 = 0;
>>  	gcStats.freedobj = 0;
>> @@ -663,9 +686,8 @@
>>  	startTiming(&gc_time, "gctime-scan");
>>
>>  	/* Walk all objects on the finalizer list */
>> -	for (unit = gclists[finalise].cnext;
>> -	     unit != &gclists[finalise]; unit = nunit) {
>> -		nunit = unit->cnext;
>> +	while (gclists[finalise].cnext != &gclists[finalise]) {
>> +		unit = gclists[finalise].cnext;
>>  		gcMarkObject(gcif, UTOMEM(unit));
>>  	}
>>
>>
>> Restoring the old version makes things work again, is this important 
>> 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 
problem i ran into was that the libraries aren't linked into the 
executable, so it won't work if you try to do static linking.  I've got 
the fix in my tree, just need to check it in.

> Regards,
> Helmer

thanks,

tim