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
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
