GC refactor ahead

Andrew Whitworth wknight8111 at gmail.com
Tue Dec 1 22:33:46 UTC 2009


On Tue, Dec 1, 2009 at 4:07 PM, chromatic <chromatic at wgz.org> wrote:
> On Tuesday 01 December 2009 at 12:33, chromatic  wrote:
>
>> If ~80% of all PMCs created in the system are only there to account for
>> internal data structures for calling functions (and they are), and
>> if there's no complex control flow such as continuations and coroutines which
>> necessitate keeping sub-graphs of the call graph alive (and in this
>> benchmark, there aren't), then I'm very confident that PCC is expensive here.
>
> For further review, I annotated the GC with printf() calls to track PMC
> destruction during GC.  The attached log shows how many PMCs of which type get
> recycled during every GC run, as well as the percentage of PMCs (Context,
> CallSig, RetCallSig, FIA) I believe to be PCC-related.
>
> At least two out of three PMCs recycled in every run are PCC-related.

Thanks for this, c. It's very informative. So I won't doubt anymore
that PCC is expensive! I make a few observations from this:

1) We go through 15 GC runs before we ever find any trash. Suggests to
me that we are allocating a lot of things at startup. When we try to
allocate a new PMC at startup and there are none in the free list, we
first do a GC mark/sweep and then we allocate a new arena. This
suggests to me that we need to significantly increase the initialize
size of our pools to prevent this. Or else, we need to use heuristics
to prevent GC runs from occurring so early in the execution cycle.

2) High number of String PMCs is a little troublesome, and you're
probably right that most of those are autoboxed S registered for PCC
calls. I think CallSignature needs to be made much more intelligent
about this and avoid unnecessary autoboxing. STRINGs do have a flag
set in the PObj flags field, so we should be able to lazily box these
only when an S is passed and a P is needed. But, the numbers for this
are comparatively small.

3) Seems like there are huge gains to be had if we can merge
CallSignature/Context/CallSignatureReturns together. I think the
VTABLE interface of the resulting PMC will be sufficiently clumsy,
though maybe we can reuse the same object and just replace the VTABLE*
for it when it's being used in call or return mode.

4) It seems like we are making ~4000-8000 CallSignatures and Contexts
between most GC runs, which implies that we're making that many
function calls between GC runs. So, I don't think GC is running too
often, but when it is running it is very expensive. Of course, there
are a comparatively small number of RetContinuation PMCs collected, so
it seems the vast majority of expenses come from calling NCI
functions. This seems like a case that we should be able to optimize
further.

I also seem to remember you saying a while back that Capture.mark()
was eating up a huge amount of execution time, is this a true
recollection?

--Andrew Whitworth


More information about the parrot-dev mailing list