limit check insertion

Matthew Fluet fluet@CS.Cornell.EDU
Thu, 25 Oct 2001 09:37:19 -0400 (EDT)


Thinking about this a little more, I don't think it's a bad idea to move
teh GC loop into the runtime system.  On the other hand, it's not going to
save any code.  Looking at the "in assembly we would have" below, this is
identical to what is currently there, except that the jmp skipGC is
currently jmp stackCheck. 

> > I don't see why it would cost any thing to make the loop that checks if the
> > GC has to run again would cost any thing.  It is all after we have decided
> > that we are going to do a GC, so we can save all the actual machine registers
> > in a fixed location, call the GC, make sure we got what we want and then
> > reload the registers.  All of this code can be in one place, right?
> 
> In a single-threaded world, yes.
> In a multi-threaded world, we could make this work by keeping a
> "bytesNeeded" field in GC_thread which would be set when the thread is
> suspended.  When restarting a thread, the loop needs to use the
> bytesNeeded.  (The loop is really for this case; returning to threadA that
> was suspended when asking for 100 bytes might be restarted in threadB's
> non-allocating loop, after threadB has used up all the free space.)
> 
> So, in assembly we would have:
> 
> stackCheck:
>         if out of stack
>                 goto doGC
> heapCheck:
>         if out of heap
>                 goto doGC
> skipGC:
> normal code
> ...
> doGC:
>         gc(bytes needed)
>         jmp skipGC
> 
> 
> and in C we would have
> 
> gc(bytes) {
>   currentThread->bytesNeeded = bytes;
>   do {
>     normal GC for bytes bytes
>   } while (currentThread->bytesNeeded < (limit - frontier))
> }
> 
> (The normal GC might change threads by changing currentThread, so the
> second ->bytesNeeded is for the thread we might return to.)