Re: GC in VM as target, was Is Assembler Language essential

"George Neuner" <gneuner2@comcast.net> wrote in message
news:09-03-015@comp.compilers...
> On Sun, 1 Mar 2009 12:52:07 +1000, "cr88192" <cr88192@hotmail.com>
> wrote:
>
>>thus far, I had worked by having the GC and main threads try to operate at
>>the same time. (a problem though is that my GC is not entirely
>>reliable...).
>
> see http://portal.acm.org/citation.cfm?id=286878 and
> http://iwi.eldoc.ub.rug.nl/root/2007/SciCompProgGao/?pFullItemRecord=ON


ok.


>>freezing and unfreezing threads is an interesting idea (and could save
>>having to use a write barrier...).
>>I guess though it could cause a pause in the various threads whenever the
>>GC
>>runs though...
>
> You can't live completely without barriers unless [1] you stop the
> world or [2] there is no shared memory.


I was almost considering this (basically, pausing all threads but the GC
during a GC pass...).




> The major advantage of threading comes when the threads have private
> heaps and most allocations are local. Any thread can initiate a minor
> collection of its own heap without affecting any other threads. For
> the shared spaces you want to use a collection which requires very
> little synchronization with the mutator threads (such as those
> described in the papers above).
>
> In private heaps, you typically want to use a compacting collector so
> you can bump allocate. But with potentially moving private data you
> don't want to allow shared objects to point to private ones (else
> you'd be constantly updating pointers). This is true regardless of
> whether the shared objects might also move due to collections.
>
> When a pointer update in the shared space will result in a shared
> object pointing to a private object, you need to first copy the
> private object and, recursively, anything it points to into shared
> space. That, of course, also means either using forwarding pointers,
> indirection headers or updating all the private pointers to them
> (unless the data are immutable in which case it doesn't matter because
> the private and shared objects are indistinguishable). For these
> things you need barriers.
>
> In fact, concurrent GC is a powerful case for immutable data because
> it allows the various spaces to be collected mostly independently.


sadly, I use a conservative GC as the main GC, so this is not workable in my
case...

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