Front page | perl.perl5.porters |
Postings from August 2010
Re: [perl #75176] Symbol::delete_package does not free certain memory associated with package::ISA
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
August 1, 2010 12:17
Subject:
Re: [perl #75176] Symbol::delete_package does not free certain memory associated with package::ISA
Message ID:
9DBA34CF-C885-46D0-8348-BD502694C230@cpan.org
On Jul 27, 2010, at 7:25 AM, Nicholas Clark wrote:
> On Sun, Jul 25, 2010 at 12:57:02PM -0700, webmasters@ctosonline.org wrote:
>> This was caused by change 31239/70cd14 which fixes *ISA=[] to call mro_isa_changed_in.
>>
>> The actual underlying cause is explained in mro?s manpage, under mro::get_isarev:
>>
>> Currently, this list only grows, it never shrinks. This was a
>> performance consideration (properly tracking and deleting isarev
>> entries when someone removes an entry from an @ISA is costly, and it
>> doesn't happen often anyways).
>>
>> If it doesn?t happen often, then the cost will not be incurred very often.
>>
>> Normally, the list of parent classes is cached, so Perl_mro_isa_changed_in can be made to compare it with the new list and delete isarev entries as appropriate. This may not be very efficient, but, again, it won?t happen very often, as the existing cached list will normally be empty.
>>
>> S_hfreeentries is the only other routine that clears the cache, so I can make that remove isarev entries, too.
>>
>> If I write a patch for this, is there any remote possibility of its being applied, or would it be a waste of time?
>
> The documentation you quoted continues with:
>
> The fact that a class which no longer truly "isa" this class at
> runtime remains on the list should be considered a quirky
> implementation detail which is subject to future change. It shouldn't
> be an issue as long as you're looking at this list for the same
> reasons the core code does: as a performance optimization over having
> to search every class in existence.
>
>
> Yes, finding an efficient way to fix this would be useful and welcomed.
OK, now for the next set of questions:
This script shows a regression in 5.10, with regard to stash assignments. I can rearrange packages to my heart’s content without triggering mro_isa_changed_in.
@a'ISA = 'b';
@b'ISA = 'c';
sub c'bark { warn "Woof!" }
sub d'bark { warn "Bow-wow!" }
$a = bless [], a;
$a->bark; # Woof!
@e'ISA = 'd';
$b = delete $::{'b::'};
$::{'b::'} = delete $::{'e::'};
$a->bark; # Woof! in 5.10; Bow-wow! in 5.8
undef $b;
$a->bark; # Bow-wow!
print *{"b::"},"\n"; # Shows that it still thinks it is *e::
For my proposed isarev changes to work, every stash (or the glob containing the stash) needs to know whether it is still part of the main stash hierarchy, or whether it has been orphaned, so that it won’t delete isarev entries that do not belong to it.
In the script above, ‘delete $::{'b::'}’ needs to trigger mro_isa_changed_in and the return value flagged such that it knows not to
remove isarev entries when its @ISA is changed.
For instance, c and d could both inherit from f. Without such a flag, @{*{$$b{'ISA::'}}{ARRAY}} = () will remove a from f’s isarev, which shouldn’t happen.
The flags on SVs seem to be a rather crowded space. Am I right in thinking hashes cannot have get-magic? If that is the case, I can re-use SVs_GMG for this purpose.
And then each stash needs to know its effective name, as opposed to its original name (see the last line of the script above). What would be the best way to do this? Store it in magic?
Thread Previous
|
Thread Next