harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject [gc][gc-haromy-5] Parrot's discussion on GC Improvements
Date Mon, 14 Apr 2008 05:21:56 GMT
Thanks for the interesting reading!

I have a hint which you may find useful: it is possible to write to a
list, keeping another one in CC. Did you managed to locate a Parrot
glossary?  I found reading Parrot texts difficult because I have no
idea what are Parrot buffers (= java arrays of primitive types?). Is
there any place where Parrot PODs are extracted into something
readable and nice looking?


On Sun, Apr 13, 2008 at 4:19 PM, Senaka Fernando <senakafdo@gmail.com> wrote:
> ---------- Forwarded message ----------
>  From: chromatic <chromatic@wgz.org>
>  Date: Sat, Apr 12, 2008 at 1:23 PM
>  Subject: Re: The Big Three Rakudo (and Parrot OO) Bottlenecks
>  To: parrot-porters@perl.org
>  Cc: Bob Rogers <rogers-perl6@rgrjr.dyndns.org>
>  On Friday 11 April 2008 19:05:41 Bob Rogers wrote:
>  >    From: chromatic <chromatic@wgz.org>
> >    The free object list is the reason that compacting/copying collectors
>  >    are popular, specifically that all you have to do to find the next
>  >    free object is bump the pointer by sizeof (header) and see if that's
>  >    still within the bounds of the pool.
>  >
>  > You don't even need the bounds check, strictly.  Several popular free
>  > Lisps just blindly initialize the last word of the new object, and if
>  > that segfaults, the allocation is restarted after creating a new pool.
>  > But I don't know if it's really worth it for anything smaller than a
>  > cons (two pointers).
>  I can see that working, but I'm a little leery of catching segfaults in a
>  cross-platform way (and the cost of that context switch... hmm, have to
>  benchmark that), but I'm more worried that there won't be a segfault because
>  the next page happens to be in already-allocated memory somewhere and we're
>  overwriting something else.  We have multiple pools of different sizes.
>  > Wouldn't it be better to have the GC trigger after the next X bytes or
>  > objects are allocated, rather than using the end of the pool?  The pool
>  > boundary seems pretty arbitrary to me.
>  Possibly.  I'm not sure how that interacts with the three-color incremental
>  scheme in the PDD, though.  We could go for the low-latency system or a very
>  conservative system or a high throughput system, but I need to think more
>  about the implications of the documented system.
>  > Weren't we just recently having a problem with special treatment for
>  > constant PMCs?  Full support for magic flying ponies is gonna cost you,
>  > and it'll probably be in terms of reliability.
>  I know, but once in a while refcounting has its advantages....
>  -- c

With best regards,

View raw message