A PMC class for reference counting
Nicholas Clark
Parrot should provide a new PMC class functionally similar to how the
dod_register_pmc/dod_unregister_pmc works. Quite probably it can share
implementation code with the DOD registration system.
My assumption was that if parrot's DOD system and Ponie both want similar
functionality, then it's plausible that other things will too. What the
DOD registry currently provides is a hash where the keys are addresses,
and the values are reference counts
1: A call to register an address, which increases the reference count for
that address.
(The address itself is the key, and is never dereferenced. Internally a
hash entry is created for that key if it didn't exist)
2: A call to deregister an address, which decreases the reference count for
that address.
(The value for that key is decremented by one. If it hits zero, the
hash entry is deleted. The current implementation silently ignores
unregistering addresses it doesn't know about.)
3: The PMC marks all the addresses (keys) it knows about, when the DOD visits
it.
(The current implementation is effectively a singleton implementation in
the root set)
You can't enquire what the value (reference count) is for a key. I think that
not being able to do this is a good thing for the DOD registry.
In Perl 5, you *can* already enquire what the reference count is. There's
code doing this Which is possibly a bad thing, as code might rely on it
"behaving itself", and not being a constant "2" because someone has replaced
reference counting with GC.
Anyway, what Ponie needs from a PMC class on top of what the private DOD
hash gives is
4: The value of the reference count.
(So for now, things still work totally as expected)
5: The ability to iterate over all keys.
(Because it seems that it's useful to be able to visit all the SVs)
I'm not sure what Parrot vtable entries are best to use for the register
and unregister. set_pmc_keyed(), ignoring the value, and delete_pmc_keyed()?
[Although that has the rather undead feel because keys wouldn't necessarily
disappear from this hash when you first called delete on them]
and get_pmc_keyed() to get the value?
Names are the bikeshed issue. Everyone can play along here even if they don't
have an opinion on the above details. Autrijus liked AddrHash and PtrHash.
I'm not too worried about the "Hash" bit. AddrRegistry? To me, it's not
important that it's a hash. It's important that it is a thing for registering
addresses of things with.
Nicholas Clark
Leopold Toetsch
> Following on our discussion on IRC, what I think we agreed on was that
> Parrot should provide a new PMC class functionally similar to how the
> dod_register_pmc/dod_unregister_pmc works. Quite probably it can share
> implementation code with the DOD registration system.
Done.
$ perldoc -F classes/addrregistry.pmc
Some tests are in t/op/gc.t
There is also a new interface in extend.c to get the Parrot registry:
Parrot_PMC Parrot_get_dod_registry(Parrot_INTERP);
> Nicholas Clark
leo
Nicholas Clark
> Nicholas Clark wrote:
> >Following on our discussion on IRC, what I think we agreed on was that
> >Parrot should provide a new PMC class functionally similar to how the
> >dod_register_pmc/dod_unregister_pmc works. Quite probably it can share
> >implementation code with the DOD registration system.
>
> Done.
Thanks.
Would it make sense if it returned 0 rather than -1 on "not found"?
The implementation can never return a reference count of 0, because keys
are automatically deleted when they are decremented to 0.
Nicholas Clark
Leopold Toetsch
On Sep 8, 2005, at 18:59, Nicholas Clark wrote:
>
> Would it make sense if it returned 0 rather than -1 on "not found"?
> The implementation can never return a reference count of 0, because
> keys
> are automatically deleted when they are decremented to 0.
Yep. Just change it.
>
> Nicholas Clark
leo
Nicholas Clark
Done.
Nicholas Clark