Re: possible garbage collector problem...

[Michael McClary <michael>]

> From: tribble@xxxxxxxxxxx (Eric Dean Tribble)
> 
>    Garbage collecting between pieces of a single expression isn't a problem
>    as long as we are single threaded.  We'll clearly have to be cleverer about
>    it when we go to multiple threads.  I don't have an obvious solution in
>    mind right now though.
> 
> Really?  Even if the call to the inner procedure does an allocation
> and garbage collection?  Are we declaring arguments to functions as
> strong pointers?

Dean is correct.  (Actually, the problem arises when the outer procedure
provokes garbage collection while the results of the inner procedure's
allocation [or unhooking] are still in only a wimpy pointer.)  Whenever
you call any routine that may provoke garbage collection, all your
non-garbage objects must be visibly non-garbage.

Multi-threading adds no problem if each thread has its own memory, which
is garbage-collected separately.  If it shares the garbage-collectable
memory with other threads, things get hairier.

With non-preemptive multithreading, those routine calls that may provoke
task-switching must be added to the list of those that may provoke garbage
collection.

With preemptive multithreading, a task-switch (and thus garbage collection)
may happen between any two instructions.  Thus, "diddling with
garbage-collectable structures" must be a mutually-exclusive state,
guarded with a semaphore or the equivalent.  The mutual-exclusion cannot
be done automatically by the allocator because it must cover the entire
interval where invisible non-garbage objects exist.

	michael