Re: Register Allocators and Garbage Collectors

Ori Bernstein <rand.chars@gmail.com>
Mon, 15 Sep 2008 18:26:27 -0700 (PDT)

          From comp.compilers

Related articles
Register Allocators and Garbage Collectors rand.chars@gmail.com (Ori Bernstein) (2008-09-09)
Re: Register Allocators and Garbage Collectors gneuner2@comcast.net (George Neuner) (2008-09-13)
Re: Register Allocators and Garbage Collectors marcov@stack.nl (Marco van de Voort) (2008-09-14)
Re: Register Allocators and Garbage Collectors niktechc@niktech.com (Sandeep Dutta) (2008-09-15)
Re: Register Allocators and Garbage Collectors rand.chars@gmail.com (Ori Bernstein) (2008-09-15)
Re: Register Allocators and Garbage Collectors rand.chars@gmail.com (Ori Bernstein) (2008-09-15)
Re: Register Allocators and Garbage Collectors gneuner2@comcast.net (George Neuner) (2008-09-16)
Re: Register Allocators and Garbage Collectors rand.chars@gmail.com (Ori Bernstein) (2008-09-17)
| List of all articles for this month |

From: Ori Bernstein <rand.chars@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 15 Sep 2008 18:26:27 -0700 (PDT)
Organization: Compilers Central
References: 08-09-052 08-09-061
Keywords: GC, parallel
Posted-Date: 16 Sep 2008 07:50:52 EDT

On Sep 13, 8:49 pm, George Neuner <gneun...@comcast.net> wrote:
> On Tue, 9 Sep 2008 20:28:36 -0700 (PDT), Ori Bernstein


> In a typical multi-threaded implementation, each thread maintains a
> private heap which it can collect independently at any time. Objects
> normally are created in the private heap. If the thread passes (hands
> off) the object to another thread, it is copied to the new thread's
> heap and becomes garbage to the original thread.


Hm. How would this be detected? I suppose that the compiler would have
to detect possible escape points and add runtime checks for that. But
then how does a collector like Boehm handle it, as it has no support
from the compiler?


<snip>


> Collecting the shared heap requires collecting all the private heaps
> as well because thread private objects may reference shared ones.
> When a global collection is necessary, a typical method is send a
> software interrupt each thread. The interrupt performs a private
> collection and then either resumes or idles the thread. As part of
> the private collection, the thread records references to shared
> objects to be used as roots for the collection of the shared heap.


Hm. Ok, I'm still not sure how you'd determine the roots if you've got
the register allocator putting them into only registers and you've got
a concurrent GC. (A blocking GC, they'd get pushed onto the stack
before the GC function gets called, of course. I can see that.) I
suppose that the compiler could put live ranges into the debug
information, but that seems like it would be quite slow/inefficient to
parse. And again, it raises the question of how a GC like the Bohem GC
does it without compiler support.


> Whether threads are allowed to continue while the shared collection is
> in progress depends on how the collector works. If it does not move
> objects, it is safe to let the threads run. If the collector moves
> objects, the threads generally must be idled while the collection is
> running. If the threads are allowed to run, allocations in the shared
> heap require synchronization with the collector so they are not
> missed.


It seems that would suck for performance, but I guess not too many
short-lived objects will end up in the shared heap, so it probably
won't get collected very often.


Thanks,
        Ori



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.