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.) 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". And to err on the side of being extra explicit, I should be clear that *all* of the long-lived PMCs that cause the slowdown in the fib.nqp benchmark are created from PIR, at :load :init time. There's no special-purpose PMCs involved, nor any calls to NCI subroutines, nor anything that would yet be able to somehow make use of a "Parrot_new_immortal_pmc()" interface. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
