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

So, forgetting all the stuff about faking closures and stuff, your proposing to "just increase the refcount"?

Assuming that you can do that, what happens if the thing you just increased the refcount of, was previously deliberatly weakened by the caller for inclusion into self-referential structure? Or after they've given it to you?

How does it play if your 'array' is initialised by 

tie my @a, 'Compact::Array';

@a = ( 'default' ) x 1_000_000;

[download]

The refcount on the SV pointing at that constant string 'default' is now 1000000. That's a million chances for it never getting cleaned up properly.

I'm not saying that this isn't possible to do--it is--but these are all things I have had problems with.

It gets even more complicated when you start thinking of the effect of storing references to shared objects and how that plays with threads and threads::shared.

I've spent a fair amount of time looking at the code in threads.xs & shared.xs that has to play similar games with reference counts.

The guys that wrote that code are a darn sight cleverer than I, and still those modules have probably been the source of more leakage than amost any other. That tells me that it's not trivial, even if my failure to make it work properly is down to my stupidity.

In each case, there are a subset of situations in which any given solution will work fine, and for a given specific task, they work okay, but for a general purpose solution, you need to consider all these possibilities and more.

Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^8: Techniques On Saving Memory
by Limbic~Region (Chancellor) on Mar 09, 2005 at 23:52 UTC
    BrowserUk,
    Ok, we are no longer talking past each other. Ok, so it isn't that simple. Perhaps a 80% solution is that simple though. You lay out the ground rules. It is the user's perogative to break them or play nice. I know it doesn't help you with your problem but I think it might with mine.

    Cheers - L~R

[reply]

      I just found one example of the sort of thing that scares me in threads: 

          /* The code below checks that anything living on
       the tmps stack and has been cloned (so it lives in the
       ptr_table) has a refcount higher than 0

       If the refcount is 0 it means that a something on the
       stack/context was holding a reference to it and
       since we init_stacks() in perl_clone that won't get
       cleaned and we will get a leaked scalar.
       The reason it was cloned was that it lived on the
       @_ stack.

       Example of this can be found in bugreport 15837
       where calls in the parameter list end up as a temp

       One could argue that this fix should be in perl_clone
    */
      

    while (tmps_ix > 0) {
      SV* sv = (SV*)ptr_table_fetch(PL_ptr_table,     tmps_tmp[tmps_ix
+]);
      tmps_ix--;
      if (sv && SvREFCNT(sv) == 0) {
           SvREFCNT_inc(sv);
           SvREFCNT_dec(sv);
      }
    }

      [download]

      I do not even begin to understand the reasoning or magic that lies behind the need to serially increment and then decrement the refcount of an SV if you've just tested it and it is currently set to 0?

      It's this kinda thing that has made me wary of playing with refcounts.

      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
[reply]
[d/l]

In Section Seekers of Perl Wisdom