in reply to Re^5: Techniques On Saving Memory
in thread Techniques On Saving Memory

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.

Replies are listed 'Best First'.
Re^7: Techniques On Saving Memory
by japhy (Canon) on Mar 10, 2005 at 17:37 UTC
    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]
        You don't lose the type and blessed information, per se. The address, when turned back into a reference, regains that data, if you do it the way I did it in my XS code: RETVAL = newRV((SV *) addr); Doing it like that restores the reference fully.

        What I don't get, though, is what this is good for. The memory for the data structure must still be allocated. In which case, why not just use a reference (which is an SV) instead of a number stored in an SV?

        _____________________________________________________
        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]
[d/l]

In Section Seekers of Perl Wisdom