[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: possible garbage collector problem...
- To: <eric>, <us>
- Subject: Re: possible garbage collector problem...
- From: Michael McClary <michael>
- Date: Sun, 1 Oct 89 17:39:22 PDT
> 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
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.