On Mon, Jul 25, 2005 at 10:33:37PM -0400, Bob Rogers wrote:
[snip]
>
> This is sounding more and more like the CMUCL gencgc algorithm, which
> uses what I understand is a classic approach. Instead of an IGP list,
> it write-protects all oldspace pages (hence my earlier question),
> unprotecting t
Hi,
I began putting the ideas of the documents in form.
For now, only the data structures are there but I think they look quite
nice. There are still some things lacking (mainly how the UINTVAL flags;
field of Gc_gmc_hdr will be used : I think that one or two bits for
marking plus some bits for re
From: Alexandre Buisse <[EMAIL PROTECTED]>
Date: Tue, 26 Jul 2005 03:06:14 +0200
I am sorry not to have told everyone before, but I discussed with leo
on IRC and the scheme he originally envisionned is actually very close
to NLDC and more simple : simply do the NLD pass at the same
From: Nicholas Clark <[EMAIL PROTECTED]>
Date: Mon, 25 Jul 2005 10:15:33 +0100
On Sun, Jul 24, 2005 at 10:32:32PM -0400, Bob Rogers wrote:
>For the record, is it acceptable in Parrot to use page
> write-protection to record whether oldspace objects have been modified
> since
On 7/25/05, Bob Rogers <[EMAIL PROTECTED]> wrote:
> I'm still digesting it (and trying to bone up on GC algorithms at the
> same time), but it does sound like it should work. I assume that
> "forall (p -> q)" above really means "forall (q0 -> q where q0 == p)",
> i.e. process all IGP entries from
On Sun, Jul 24, 2005 at 10:32:32PM -0400, Bob Rogers wrote:
>For the record, is it acceptable in Parrot to use page
> write-protection to record whether oldspace objects have been modified
> since the last full GC? This is what CMUCL does on most ports, but it
> occurs to me that this might b
From: Nattfodd <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 03:22:04 +0200
Leopold Toetsch wrote:
>> ... Perhaps you should save your (metaphorical) breath, and I'll
>> wait for a more detailed design.
>
>
> I'm waiting too :-)
Hi,
I believe I found a good workaround
Leopold Toetsch wrote:
>> ... Perhaps you should save your (metaphorical) breath, and I'll
>> wait for a more detailed design.
>
>
> I'm waiting too :-)
Hi,
I believe I found a good workaround for the cycle problems. It is a
little bit slower and worst case (which never occurs, happily) is
|IGP_s
Bob Rogers wrote:
So that means you do not use the IGP pointer to A when collecting any
generation <= j, correct? Otherwise, I imagine you'd always decide that
A is alive, and hence B and C.
IGPs entries that span the range of to be collected generations are not
considered (and very likely r
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 18 Jul 2005 17:08:53 +0200
Circular or not isn't really the problem. With generational GC you'll
always have the chance of tenured garbage . . .
Now due to some other pointer store the object C becomes dead. But as
long as w
From: Nattfodd <[EMAIL PROTECTED]>
Date: Tue, 19 Jul 2005 04:03:49 +0200
Leopold Toetsch wrote:
>
>gen n | gen j
>[ A ] -> [ B ] -|-> [ C ]
> ^ |
> +--+
>
> A circular data structure doe
Leopold Toetsch wrote:
>
>gen n | gen j
>[ A ] -> [ B ] -|-> [ C ]
> ^ |
> +--+
>
> A circular data structure doesn't really change the picture, except,
> when again scanning up to generation j, and we find object C b
Bob Rogers wrote:
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 17 Jul 2005 12:08:34 +0200
> What happens when a store creates a cycle? And how would this be
> detected?
To keep the invariant we can't move the container nor the contained
object, *if* both are aggregat
Nattfodd wrote:
Leopold Toetsch wrote:
I believe that if we want variable-sized body, we need at least one next
(or pmc_size) pointer in the header.
Not necessarily. We can have:
- some type bits in the gmc_header for fixed-sized and commonly used
objects, so that GMC knows the size
- alt
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 17 Jul 2005 12:08:34 +0200
> What happens when a store creates a cycle? And how would this be
> detected?
To keep the invariant we can't move the container nor the contained
object, *if* both are aggregates. Therefore the po
Leopold Toetsch wrote:
> Nattfodd wrote:
>
>> Leopold Toetsch wrote:
>
>
>>> 1) pmc_bodies have to be variable sized
>>
>>
>> Oh, I believed that we would use variable-sized pmc only if the gc
>> proved to work really well.
>
>
> Well, with fixed sized bodies, we don't need the extra indirection.
Bob Rogers wrote:
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sat, 16 Jul 2005 11:38:41 +0200
. . .
We keep the invariant by several means:
. . .
c) a write barrier checks pointer stores into aggregates (by just
comparing 2 memory addresses - basically)
we can d
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sat, 16 Jul 2005 11:38:41 +0200
. . .
We keep the invariant by several means:
. . .
c) a write barrier checks pointer stores into aggregates (by just
comparing 2 memory addresses - basically)
we can do either:
- mak
Nattfodd wrote:
Leopold Toetsch wrote:
1) pmc_bodies have to be variable sized
Oh, I believed that we would use variable-sized pmc only if the gc
proved to work really well.
Well, with fixed sized bodies, we don't need the extra indirection.
But I really like to have a more flexible objec
Leopold Toetsch wrote:
>
> On Jul 16, 2005, at 2:24, Nattfodd wrote:
>
>>
>> Hi,
>> I've produced a new document on GMC (Generational Mark & Compact), the
>> GC I'm trying to implement as a Summer of Code project. It's called gmc
>> for dummies and I hope it's plainly understandable (if not, tell
On Jul 16, 2005, at 2:24, Nattfodd wrote:
Hi,
I've produced a new document on GMC (Generational Mark & Compact), the
GC I'm trying to implement as a Summer of Code project. It's called gmc
for dummies and I hope it's plainly understandable (if not, tell me so
and I'll try to make it better). I
Nattfodd wrote:
>It's here :
>http://perso.ens-lyon.fr/alexandre.buisse/divers/gmc_for_dummies.pod
>A more complete document is http://perso.ens-lyon.fr/divers/gmc_design.pod
>
>
Sorry, the second URL is actually
http://perso.ens-lyon.fr/alexandre.buisse/divers/gmc_design.pod
22 matches
Mail list logo
