Register Allocators and Garbage Collectors

Ori Bernstein <rand.chars@gmail.com>
Tue, 9 Sep 2008 20:28:36 -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)
[1 later articles]
| List of all articles for this month |

From: Ori Bernstein <rand.chars@gmail.com>
Newsgroups: comp.compilers
Date: Tue, 9 Sep 2008 20:28:36 -0700 (PDT)
Organization: Compilers Central
Keywords: storage, GC, parallel
Posted-Date: 13 Sep 2008 11:51:05 EDT

I was wondering how garbage collectors running in a thread in compiled
languages typically would handle interactions with the register
allocator keeping variables in use only in registers.


For example, suppose we have code that looks like this:


int x[];
x = new int[10];
x[3] = 42;




And suppose it compiles to look like this:




; allocate 10 4 byte ints
1 pushl $40
2 call gc_alloc
; store 42 to the 3rd element of the array
3 movl $42,12(%eax)




If we get a context switch between lines 2 and 3, then the only record
of a root pointing to the newly allocated value is in register %eax,
and is hidden from the debugger thread.


How do garbage collectors deal with this problem typically? Does the
compiler have to insert spill points which force the values onto the
stack and invoke the GC? Am I just on crack thinking that there might
be a problem?



Post a followup to this message

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