On 01/21/2009 07:20 AM, Derek Zhou wrote:
On Monday 19 January 2009 12:34:02 am you wrote:
I actually applied this patch instead, but you must be thanked anyway
for the debugging.
Another thing is I don't think the _gst_incremental_gc_step function in
oop.c is doing what it means to do:
void
_gst_incremental_gc_step ()
{
OOP oop, firstOOP;
int i;
for (i = 0, oop = _gst_mem.highest_swept_oop,
firstOOP = _gst_mem.last_swept_oop;
i<= INCREMENTAL_SWEEP_STEP&& --oop> firstOOP;
oop->flags&= ~F_REACHABLE)
{
if (--oop> firstOOP)
{
finished_incremental_gc ();
break;
}
if (!IS_OOP_VALID_GC (oop))
...
If you look closely there is no practical way it can get to the
IS_OOP_VALID_GC check, let alone the actual sweeping. However my attempt
of fixing it intuitively caused gst to crash so I don't know...
I think I fixed it now. :-) Just because after six months I had a good
reason. :-)
The bug was just that _gst_mem.last_swept_oop was totally wrong and
basically worked by chance. Yes, I mean it...
The reason I went back to it, is that I wanted to remove the usleep (1)
almost-busy wait (poll every millisecond) for signals done in
VMpr_Processor_yield. The changes would be as follows:
1) when GST is idle, it tries doing an incremental garbage collection
step, fifty times per second
2) in addition, if there are any, it runs the idle blocks
(ProcessorScheduler>>#idleAdd:) round-robin, also fifty times per second.
3) if there is no idle block and the GC is done, however, it can just
sigsuspend until the next signal.
I had this ready a while ago except that because of the above bug, it
would never finish the incremental GC, and never go sigsuspend. :-(
I'll push after some more testing on Swazoo.
Paolo
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
