I'm not sure why you need to increment the ref count. Could you explain the reason?
See the discussion in this thread at Re^6: Techniques On Saving Memory. Basically, if you take a smashed reference, perl doesn't know you have it, so by the time you get to unsmash it, the thing you took a reference too could have been GC'd. If the refcount was (optionally) increased when a smashed refence was taken, and decremented when it was unsmashed, it would appear like an ordinary reference had been taken and GCing would be delayed.
I still have doubts about how this would interact with other things, especially threads and shared vars, but if all that functionality was wrapped in a single place, it might at least allow the idea to be tested.
It's already possible to do all of that using bist a pieces from half a dozen existing modules, but it would be useful to get it all from one.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
| [reply] |
Ah, I see. I was thinking "why would a person who accidentally stringified a reference need to do this?", but now I realize that, because this technique now exists, you might stringify it intentionally.
_____________________________________________________
Jeff japhy Pinyan,
P.L., P.M., P.O.D, X.S.:
Perl,
regex,
and perl
hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart
| [reply] |
Devel::Pointer has a deref() function, which allows you to get you hands upon the address without literally stringifying it. What you loose, is the type and blessedness information. If you can get that all in a single call rather than messing around with parsing the stringified representation that would just make things simpler.
The other side is if it is possible to recover that information from the SV pointed at, rather than having to store it and related it back later when you unsmash it, that would make life a great deal easier and remove another level of storage requirement and lookup.
With both sides, plus the appropriate refcount manipulations, you have the possibility to retain a single 32-bit value as a handle to anything. That makes the whole compact array idea almost practical.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
| [reply]
[d/l] |