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.

  Ok.
 
> 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.

  I think they would. I was also imagining that eventually  tied/magic
[SAHG]Vs will become a subclass of their untied equivalent. Maybe
@_/arrays with !AVf_REAL and with AVf_REIFY might become a separate
class as well.

> > 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.

  Eliminatig flags will break code like SvFLAGS(sv) |= ... but I agree
with the general plan. It might be a good idea just killing SvFLAGS().
and having SvFLAGS_get/set.

  My implementation plan is:

1) rearrange inheritance hierarchy, remove perl5cargo_cult
2) merge head and tail keeping  flags, refcount and everything
     in head
3) figure if it is possible to eliminate the tail in some cases

> > 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.

  I need to think it through later. I hope it will work...
 
> 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.

*  AvARRAY: currently Parrot Array PMC uses a sparse array;
   there were plans of changing it, to a "simple" array,
    but in any case I doubt you would be able to peek at the Array PMC   
   internals to implement AvARRAY
* hv_fetch_ent (and all the functions taking HE*).
* hv_iter*: in perl5 the HV owns the iterator, in parrot it does not
   (this might be done through properties, though)
* lvalue accessors like SvFLAGS(sv) |= ... etc

> > 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?

  Yes.

Regards
Mattia