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

[Dalibor Topic]

Hi Tim,

thanks for taking the time to look into this. I've tried backing out the 
change as you propose, and it works for me (TM). But the jit-temp-data 
is no longer freed, so we are back at square one ;(

Timothy Stack wrote:

>>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?

yep, jit-temp-data is back at 8M instead of a few 100K as before.

cheers,
dalibor topic