develooper Front page | perl.perl5.porters | Postings from August 2010

Fwd: [perl #75176] Symbol::delete_package does not free certain memory associated with package::ISA

Thread Previous | Thread Next
From:
Father Chrysostomos
Date:
August 22, 2010 17:46
Subject:
Fwd: [perl #75176] Symbol::delete_package does not free certain memory associated with package::ISA
Message ID:
C25294B0-F240-4C3D-B51D-517ACEA1C74C@cpan.org
Oops. I forgot the main part of the message and just sent the postscript. Here it is:

Begin forwarded message:

> From: Father Chrysostomos
> Date: August 22, 2010 5:39:15 PM PDT
> Cc: Nicholas Clark, p5p
> Subject: Re: [perl #75176] Symbol::delete_package does not free certain memory associated with package::ISA
> 
> 
> On Aug 8, 2010, at 12:22 PM, Father Chrysostomos wrote:
> 
>> If PL_sub_generation does not invalidate isa caches, would it be appropriate to add a new PL_isa_generation variable?

I tried PL_sub_generation, and found that it doesn’t work. I tried adding PL_isa_generation (attached, in case you want to see it; not for application), which worked, but then I realised that it would mean iterating through *all* packages afterwards to reconstruct PL_isarev.

So I’ve used a different approach with the other patch attached (1. reset isa...). When a stash is manipulated, it calls mro_isa_changed_in on the affected packages and iterates through their subpackages, doing the same.

It does not yet take into account all methods of manipulating the stashes. More patches will follow.

What does this have to do with the original bug?

Initially I planned to fix the isarev leaks by making appropriate adjustments to it whenever an @ISA is modified or a stash is freed. But, since stashes can be detached from the main tree of stashes ($stash = delete $::{"it::"}), they need to know whether they are still attached, so detached stashes don’t muddle up isarev and delete entries that are still needed (which would be worse than leaking).

In the process of experimenting with that, I found that such stash manipulations already fail to update isa caches, which, too, would cause my proposed isarev changes to introduce regressions. So that’s what this patch is for.

>> 
>>> It's not common, and I don't see an absolute need to calculate the
>>> strict set of packages affected, and call mro_changed_in() for just them.
>> 
>> And I now realise that such would be very inefficient anyway, as nested classes have nothing to do with inheritance. (*p:: = *PPI:: would have to iterate through 94 packages, recalculating the linear isa cache, etc. *p:: = delete $::{"PPI"} would do that iteration twice.)
> 
> I think we will have to live with this inefficiency. Anyway, most of the time I alias packages, it’s just for a few. The most common example in my code is ‘use DDS’ which loads DDS.pm, which aliases DDS:: to Data'Dump'Streamer::.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About