Re: Patches that will come...

On Sat, Aug 28, 2004 at 08:21:40PM +0200, Mattia Barbon wrote:
> On Sat, 28 Aug 2004 15:35:42 +0100 Nicholas Clark <[email protected]> wrote:

> >  Full PMC hierarchy
> 
>   I assume the PMC hierarchy resembles/is equal to the one described in the
> "illustrated guts" by Gisle Aas?

I think that that's out of date. There was a change last year, IIRC involving
PVGV and PVLV. The ASCII art diagram somewhere in ext/B is accurate.

I'm also not sure whether pads, stacks and stashes would benefit from being
new types distinct from and derived from arrays, arrays and hashes.

> The snapshot 3 announcement talked about
> 
> > * Make ponie's PMCs properly inherit in the perl5 class hierarchy
> > * Move all the data access to PMC methods.
> >
> > which will allow all the perl data structures currently dangling off the PMCs
> > to be eliminated.
> 
>   I do not understand: Perl5 PMCs will always need some data structures dangling
> off the PMCs. Was that sentence talking about eliminating the head/tail split?
> And anyway: what is the plan for the head/tail split? Currently we have
> 
> RV:    PMC -> referenced value (OK)
> IV/NV: PMC -> head[IV/NV,flags,refcount,any(unused)]
> other: PMC -> head[flags,refcount,IV/NV(unused),any]
>               -> tail[more or less with the Perl5 layout]
> 
> where the head is the same for all SV types. The transition
> I have in mind (and it might not work and might not be something needed)
> is: eliminate the head, move the IV, NV, flags and refcount (until it is needed)
> into the tail and have the tail hang off the PMC_data member.

This is roughly what I was thinking. Except that the flags may well want
faking (or indirecting) so that there is no tail for the simple types (IV, NV,
RV and possibly pure PV). Likewise use the pmc cache slots for the NV and IV
data. That way at least some of the simple types don't need anything hanging
off.


> 2) switch to GC:
> kill the refcount field, making SvREFCNT* no-ops and adding mark() methods
> to compound data structures. This will break a lot of existing XS, and has
> a deep impact on Perl code relying on the current refcount implementation.
> 
> The option 2 requires further discussion about the guarantees for object
> finalization (Perl5 is "as soon as the SV is not referenced", Perl6 
> (IIRC) is "at the end of a scope", other languages have "eventually" and "maybe").
> And about its feasibility, of course.

My/Arthur's thoughts were that SvREFCNT* is a no-op in the core (with
marking etc as you describe). But outside the core (and the default
for XS passed through xsubpp) is that SvREFCNT* isn't a no-op and marks
by calling the parrot API for marking an external reference to a PMC.

(plus all the AV, HV and RV API calls also need to change into something
that knows to release the external refcount as that "reference" is now
"owned" by core that is garbage collected.)

This is complicated. It may be too complicated.

To us the first step is to abolish the refcount field and let parrot do all
the refcounting via its PMC reference marking.

As to scope, I'm hoping that the parrot fast DOD for live objects is fast
enough. And with lexical pragmas it would be possible for ponie aware projects
to disable it.

> >  Convert arrays,pads,hashes,stashes to something native PMC
> 
>   Hmm. If I read this as "Convert arrays,pads,hashes,stashes to be
> properly-implemented PMCs, having Ponie guts accessing them (mostly) through
> PMC vtable" I can see ways of doing it. But if for "native PMC" you
> mean the PerlHash/Hash from Parrot, I don't think there is any way of doing
> it keeping the current av_/hv_* API for XS.

I did mean that, and I'd not seen a fundamental stumbling block to this.
Why do you think that there's potentially a big problem with this?
The av_/hv_* API would be veneers over the PMCs, as I saw it.

> Currently my short term TODO list is:
> 
> * rework PMCs in the correct inheritance hierarchy
> * try to fix whatever needs fixing in the refcount/GC mess
> * implement Parrot_call_method (Parrot work, done, need to send patch)
> * finalize the patch for Perl -> Parrot calls,
>   adding methods as well
> * implement tied/magical arrays/hashes

Is this in the order you intend to attack it in?

> the bad news is that I have no idea when I will have the time for even the
> first item :-( I will send a warning when/if I start working on something,
> just to avoid effort duplication.

That would be good. I hope that you get more time to work on fun projects
(both ponie/parrot and others) soon.

Nicholas Clark