[LLVMdev] Garbage collection

David Vandevoorde daveed at edg.com
Thu Feb 26 10:27:02 PST 2009


On Feb 26, 2009, at 11:40 AM, Török Edwin wrote:
[...]
>>> A little bit off topic: Has anybody tried building a concurrent GC  
>>> - running
>>> in a different _process_, instead of a thread?
>>>
>>
>> Yes, I had a proof of concept implementation of a GC with
>> - shared memory as the GC arena,
>> - (C++) throw-catch-based marking
>> - simple lookup rules for (in-arena) associated
>>  instance metadata.
>>
>> I never had the need to finish the implementation, but
>> the fork approach worked reasonably well, and the mark
>> and sweep parts ran in the forked process, with the
>> shared memory communicating back the collection results.
>>
>> The most amusing thing was to see how the stack unwinding
>> in the forked process did the marking and the original process
>> was not harmed.
>>
>> I hope to extend the concept to multiple threads by (m)protecting
>> increasing parts of the arena and hoping that all threads get
>> caught with time. Finally the last running threads must be
>> stopped and forced to fork. This last question and how to recover
>> the threads from the protection violations in the original process
>> are the big open questions to be solved.
>
> What do you do if the program is multi-threaded? fork()-ing a
> multithreaded program can lead to problems ...
> The functions you can call after forking is very limited according to
> POSIX: "If a multi-threaded process calls /fork/(), the new process
> shall contain a replica of the calling thread and its entire address
> space, possibly including the states of mutexes and other resources.
> Consequently, to avoid errors, the child process may only execute
> async-signal-safe operations until such time as one of the /exec
> <http://www.opengroup.org/onlinepubs/9699919799/functions/exec.html>/
> functions is called."

My understanding is that the child process would basically only take  
care of the "mark" phase (and return results via shared memory for a  
"lazy sweep" by the allcotor).  Do you anticipate async-signal-unsafe  
operations would be required for that?

	Daveed





More information about the llvm-dev mailing list