GC refactor ahead

[Andrew Whitworth]

On Fri, Dec 4, 2009 at 2:52 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Fri, Dec 04, 2009 at 11:26:12AM -0500, Andrew Whitworth wrote:
>>
>> Let me try and explain better what I am thinking:
>> [...]
>> So if we call Parrot_new_immortal_pmc() to create the parent, and we
>> call it again to create the child, we've manually shown the
>> relationship that the two are in the same generation and we don't need
>> integenerational pointers. However, if the parent is immortal and the
>> child is normal, the write barrier will detect that and add the
>> intergenerational pointer record.
>
> Speaking from the perspective of an HLL developer and user, almost
> nothing in the above paragraph makes any sense to me.  What would I do
> in a language like Perl 5, Python, Perl 6, or even PIR to say "hey,
> this object I'm creating is going to be part of an immortal data
> structure, use the 'immortal PMC' creator instead of the 'mortal'
> one"?  Or, if my compiler is supposed to be smart enough to figure it
> out, then how will it know?  (This sounds like a variation of the
> halting problem to me.)

Ah, good question. We're really talking about two different things
here and I'm glazing over the differences. There are really two
environments where PMCs and STRINGs are used: Internal to Parrot, and
in "PIR-land".

In the general sense of a generational GC, we create all objects into
a "nursery" where we presume all objects are short-lived. We mark and
sweep the nursery regularly. However, if items in the nursery survive
mark and sweep (or survive it X times), we bump it up to the next
generation. Each successively older generation is marked and swept
less often. The heuristic being that the longer an item has survived,
the longer it is likely to survive. We gain huge savings because we
can make presumptions about the longevity of entire generations at
once and waste less effort on objects that statistically aren't going
anywhere.

So in a generational GC under normal operation, objects are promoted
to higher generations automatically. You as the HLL developer just
allocate like normal and GC takes care of the rest.

What I was talking about above are details of Parrot internals where,
as an optimization, we can skip the nursery and allocate directly from
older generations. This saves us the effort for the "trial by fire"
where GC determines the item is long-lived, because we know in some
cases ahead of time that certain PMCs are long-lived and some are
short-lived.

> I also think the term "immortal PMC" is highly misleading and
> open for misinterpretation -- long-lived (but still potentially
> mortal) PMCs appear to be the real issue here.  I'd prefer we stick
> with the "long-lived" phrase instead of "immortal".

Noted.

--Andrew Whitworth