Andy Dougherty wrote:
On Fri, 2 Sep 2005, Nattfodd wrote:
I added in the last revision some very basic memory alignment control
(basically, headers and bodies are rounded up to the nearest multiple of
GMC_ALIGN, which has a value of 8 now but can be changed at will. As headers
were
Andy Dougherty wrote:
Overall, I wonder if it's an alignment issue, since SPARC tends to be
much more sensitve to that than x86. I haven't looked deeply at the
code at all, but do you do anything special to ensure that the blocks
of memory you are moving around maintain their aligment?
Andy Dougherty wrote:
On Thu, 1 Sep 2005, Nattfodd wrote:
today is the deadline for the google summer of code projects, and it's time
anyway for a "release" of GMC.
GMC is a generational garbage collector for parrot that allows copying of
objects and thus copying GC schemes
Will Coleda wrote:
On Aug 31, 2005, at 7:03 PM, Nattfodd wrote:
If people are willing to test real programs with it, it would really
be nice !
Thought I'd give languages/tcl a whirl, but after a fresh checkout of
the GMC branch:
% perl Configure.pl; make
perl build_tools/jit
Hi,
today is the deadline for the google summer of code projects, and it's
time anyway for a "release" of GMC.
GMC is a generational garbage collector for parrot that allows copying
of objects and thus copying GC schemes.
There are two main parts :
- The first is a new object definition (se
Tim Bunce wrote:
Anyone given any thought to Parrot <-> Java integration?
Possible?
Practical?
How much would would be involved?
Tim.
If I'm not mistaken, it's even one of the summer of code projects (see
http://www.perlfoundation.org/gc/grants/2005-googlesoc.html and
http://www.perlfound
ourse included #if PARROT_GC_GMC everywhere so it should be pretty
safe unless you set #PARROT_GC_SYSTEM to 3 in include/parrot/settings.h
If that's the case, my perl.org account is named 'heimdall' (I don't
know how to change it for 'Nattfodd', sorry).
Regards,
Alexandre
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
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
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,
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
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 explain how things will
hopefully work
13 matches
Mail list logo
