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:11 GMT
---------- Forwarded message ----------
From: chromatic <chromatic@wgz.org>
Date: Sat, Apr 12, 2008 at 6:09 AM
Subject: Re: The Big Three Rakudo (and Parrot OO) Bottlenecks
To: parrot-porters@perl.org

On Friday 11 April 2008 17:27:34 chromatic wrote:

> 1) The Garbage Collector is algorithmically inefficient.  There are
> potential optimization strategies here which don't require us walking
> allocated header in the system multiple times (yes, it's that bad in at
> least two places), but the real solution I suspect is to replace the
> current GC with at least the one specified in the new GC PDD.

I realize there's a third (potential) problem with the GC.  I don't recall
offhand (and I don't have time at the moment) to see if it keeps any
statistics about whether the current GC run actually reclaimed anything
substantial.  That is, if we exhausted a free list and ran the GC but only
freed a couple of headers, we know we'll just have to run another full mark
and sweep shortly anyway.  My evidenceless guess is that it's worth just
allocating another empty pool unless we've reclaimed 1/3 to 1/2 of a pool's
worth of headers.

This is probably an optimization we should consider for any GC scheme.

Oh, and while I'm asking for magic flying ponies who eat garbage and produce
candy, wouldn't it be nice to have a way to allocate a PMC or other PObj you
know you need for a couple of instructions and then never again and then
immediately free it?

-- c

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