[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Garbage Collection Riddle

Date: Thu, 19 Jul 90 10:19:16 PDT
   From: tribble (Eric Dean Tribble)

   I assume this is the garbage collector version of the problem I
   pointed to for purging schemes:  If you call zorch on the original
   Bar, the first zap messages clears the strong pointer to the Bar.  The
   second zap could cause a garbage collection, and the Bar currently
   executing zorch() would be collected even though it is currently in
   the midst of executing because it has no strong pointers to it.

   Presumably you started all this with the message zip.  In fact this
   does seem like a rather bizarre and inlikely construct.  It will only
   occur when we have circular structures keeping everything together.  A
   particular example that occurs to me is the replaceOLoaf: operation to
   replace the child pointer to a loaf in the ent.  This will
   conveniently go away when I switch to using become.  Presumably the
   same thing happens in the other direction.

Bingo!  Hand that man a prize.  Yes, it was indeed derived from what
you noticed about garbage collection behavior in the presence of

Even if the case seems rather bizarre, I see little way to locally
reason about code to satisfy ourselves that we are not exercising this
bizarre case.  (At least no way sufficient for implementation in
XLint)  Ideas?