Re: VM as target, was Is Assembler Language essential

George Neuner <gneuner2@comcast.net>
Mon, 02 Mar 2009 23:48:37 -0500

          From comp.compilers

Related articles
[9 earlier articles]
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-02-24)
Re: VM as target, was Is Assembler Language essential cr88192@hotmail.com (cr88192) (2009-02-25)
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-02-25)
Re: VM as target, was Is Assembler Language essential cr88192@hotmail.com (cr88192) (2009-02-27)
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-02-28)
Re: VM as target, was Is Assembler Language essential cr88192@hotmail.com (cr88192) (2009-03-01)
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-03-02)
Re: VM as target, was Is Assembler Language essential gneuner2@comcast.net (George Neuner) (2009-03-03)
Re: GC in VM as target, was Is Assembler Language essential cr88192@hotmail.com (cr88192) (2009-03-06)
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Mon, 02 Mar 2009 23:48:37 -0500
Organization: A noiseless patient Spider
References: 09-02-021 09-02-037 09-02-076 09-02-082 09-02-089 09-02-095 09-02-103 09-02-109 09-02-114 09-02-122 09-02-124 09-02-133 09-02-143 09-02-151 09-03-007
Keywords: GC, parallel
Posted-Date: 03 Mar 2009 12:45:01 EST

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




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


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.


George



Post a followup to this message

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