[LLVMdev] Garbage collection

Ralf Schneider lists at gestaltgeber.com
Thu Feb 26 09:42:24 PST 2009


2009/2/26 Török Edwin <edwintorok at gmail.com>

> 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."


Well, I have alread thought a little bit about this problem.
If I remember right only the thread calling fork will remain active in the
child process. Thats exactly what we want.
In pseudocode it could look like this.

Garbage collection thread:
    shared_mem = create_shared_memory()
    loop:
        wait_for_garbage_collection_signal()    # wait until a garbage
collection is requeted
        pause_all_other_threads()    # stop the world
        root_pointers = get_root_pointers_from_all_threads()
        resume_all_other_threads()
        child_pid = fork()
        if(!child_pid):
            # child process - all threads except of the current one has been
stopped by fork()
            collect_garbage(root_pointers, shared_memory)    # collect
unreferenced memory blocks, put the result in shared_memory
            exit()
        else:
            wait_for_process_exit(child_pid)
            free_memory_blocks(shared_mem)    # free all memory blocks the
GC has found

=> There is probably no problem with mutexes and other synchronization
primitieves, because we simply do not care in the garbage collection thread

But may be I'm missing something.

Regards,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090226/b067b769/attachment.html>


More information about the llvm-dev mailing list