harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <senaka...@gmail.com>
Subject Re: Parrot's discussion on GC Improvements
Date Sun, 13 Apr 2008 12:19:51 GMT
---------- 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message