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
proven assertions about things that might not matter.
Actually, I had some laptop problems which should hopefully be fixed
soon. As time is beginning to run short (remember that the GC should
be functional by Sept. 1st), I'll rewrite GMC for dummies very soon
(tomorrow ?) and
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
which should hopefully be fixed
soon. As time is beginning to run short (remember that the GC should
be functional by Sept. 1st), I'll rewrite GMC for dummies very soon
(tomorrow ?) and hope to begin coding just after that.
Regards,
Alexandre
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 du
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&
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
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). It should expl
23 matches
Mail list logo
