refcounting hash

[Nicholas Clark]

Right now ponie is still reference counting. In effect it's duplicating the
work of parrot's DOD registration scheme. For space and efficiency reasons it
would be very useful to move the ponie reference counts outside the actual
PMCs, and effectively store them in a hash, much like the DOD reference
counting system.

However, I think it's wrong to use the DOD reference counting system for a
couple of reasons

1: The Perl refcounting API lets you get (and set) the actual refcount value.
Whilst I'm quite happy to refuse to support general purpose setting it, I
suspect that getting it is still needed. Certainly it's needed in the
interim for code migration
2: Code should care about the reference count. (Although I believe that some
does). I'd not like to (ask to) extend parrot's DOD registration API to
get the reference count out, because that opens it up to (ab)use by parrot
extensions. The DOD reference count is "none of your business"
3: I think I might need the ability to iterate over all the allocated Ponie
PMCs

So I think what I'd like is a PMC that provides the same functionality as
dod_register_pmc in pmc.c [see http://svn.perl.org/parrot/trunk/src/pmc.c ]
wrapped into a regular PMC. Basically it provides a hash keyed on addresses,
value is a reference count, where the key/value pair is automatically deleted
if the reference count drops to 0. Only it is (in effect) a singleton.

I'd like to be able to provide this as a non-singleton PMC class, with the
addition of a value lookup, and (possibly) iteration. But cut and paste is
evil. So does anyone have suggestions on the best way to be able to
refactor the code in pmc.c such that it can provide a (private) API for a
core PMC to wrap, without slowing down the DOD's use of the same code.

Does this seem sane? Can anyone see a good way of doing this?

Nicholas Clark

[Leopold Toetsch]

Nicholas Clark wrote:

> I'd like to be able to provide this as a non-singleton PMC class, with the
> addition of a value lookup, and (possibly) iteration. But cut and paste is
> evil.

Well, the more general question is: how can we parameterize our
aggregates. We already have tons of arrays with (bit, double, int, PMC*,
STRING*) values.

For hashes it could get worse:

key / value
STRING* / PMC* Hash
PMC * / PMC * Python / Perl6
&PMC / INTVAL ref hash
x y Perl6

The hash functions in src/hash.c can handle this (probably), with
key/value type and with user defined compare/hash functions already
inside..

We need an interface above that constructs appropriate vtable pieces for
key and value access from the PMC side.

> Nicholas Clark

For now c&p helps :-)
leo

[Nicholas Clark]

On Thu, Jul 14, 2005 at 06:14:52PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >I'd like to be able to provide this as a non-singleton PMC class, with the
> >addition of a value lookup, and (possibly) iteration. But cut and paste is
> >evil.
>
> Well, the more general question is: how can we parameterize our
> aggregates. We already have tons of arrays with (bit, double, int, PMC*,
> STRING*) values.

> For now c&p helps :-)

I don't agree. c&p is evil, because it causes code bloat and propagates bugs.

And I'm not after parameterising the aggregates - I'd like to instantiate
another instance of what is currently a singleton, for the same type, with
the same specific, specialised behaviour.

Nicholas Clark

[Leopold Toetsch]

On Jul 20, 2005, at 21:35, Nicholas Clark wrote:

>> For now c&p helps :-)
>
> I don't agree. c&p is evil, because it causes code bloat and
> propagates bugs.
>
> And I'm not after parameterising the aggregates - I'd like to
> instantiate
> another instance of what is currently a singleton, for the same type,
> with
> the same specific, specialised behaviour.

Well, with c&p I ment, you have to create a new PMC type, with mostly
c&p code from e.g. the registry hash, then we can instantiate one of
these for the registry and you can use them as well.

> Nicholas Clark

leo