Bug #52537 for Moose: Memory leak (cycle) Moose::Meta::Method::Delegation body member and $self

Mon Dec 07 14:42:23 2009 harv [...] ruin.nu - Ticket created

Subject:

Memory leak (cycle) Moose::Meta::Method::Delegation body member and $self

Moose::Meta::Method::Delegation::_initialize_body creates a sub which gets $self from closure, creating a cycle. As far as I know it can be fixed by using Scalar::Util::weaken on $self. Cycle (1): $Class::MOP::Class::Immutable::Moose::Meta::Class::A-> {'methods'} => \%B $B->{'execute'} => \ %MooseX::Method::Signatures::Meta::Method::C $MooseX::Method::Signatures::Meta::Method::C-> {'parsed_signature'} => \%Parse::Method::Signatures::Sig::D $Parse::Method::Signatures::Sig::D->{'_positional_params'} => \ %Parse::Method::Signatures::ParamCollection::E $Parse::Method::Signatures::ParamCollection::E->{'params'} => \@F $F->[0] => \ %Class::MOP::Class::__ANON__::SERIAL::5::G $Class::MOP::Class::__ANON__::SERIAL::5::G->{'__MOP__'} => \ %Moose::Meta::Class::H $Moose::Meta::Class::H->{'_meta_instance'} => \ %Moose::Meta::Instance::I $Moose::Meta::Instance::I->{'attributes'} => \@J $J->[5] => \%Moose::Meta::Attribute::K $Moose::Meta::Attribute::K->{'associated_methods'} => \@L $L->[2] => \ %Moose::Meta::Method::Delegation::M $Moose::Meta::Method::Delegation::M->{'body'} => \&N $N variable $self => \$O $$O => \ %Moose::Meta::Method::Delegation::M

Mon Dec 07 14:48:57 2009 hdp [...] cpan.org - Correspondence added

Why do you think this cycle is a leak? The one does not necessarily imply the other.

Mon Dec 07 14:48:58 2009 The RT System itself - Status changed from 'new' to 'open'

Mon Dec 07 14:52:55 2009 stevan.little [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #52537] Memory leak (cycle) Moose::Meta::Method::Delegation body member and $self
Date:	Mon, 7 Dec 2009 14:52:36 -0500
To:	bug-Moose [...] rt.cpan.org
From:	Stevan Little <stevan.little [...] iinteractive.com>

Michael, It is actually common for us to have cycles within the MOP as the MOP is not meant to go away until the interpreter exits. This would be fixed pretty easily by either doing what you say or by just extracting the values we are using and closing over them instead. However, I would like to understand what it is your doing that is causing you to feel this cycle is actually a leak and therefore a problem. Thanks, - Stevan On Dec 7, 2009, at 2:42 PM, Michael Andreen via RT wrote: Show quoted text

> Mon Dec 07 14:42:23 2009: Request 52537 was acted upon. > Transaction: Ticket created by harv > Queue: Moose > Subject: Memory leak (cycle) Moose::Meta::Method::Delegation > body member > and $self > Broken in: 0.93 > Severity: Normal > Owner: Nobody > Requestors: harv@ruin.nu > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=52537 > > > > Moose::Meta::Method::Delegation::_initialize_body creates a sub which > gets $self from closure, creating a cycle. > > As far as I know it can be fixed by using Scalar::Util::weaken on > $self. > > Cycle (1): > $Class::MOP::Class::Immutable::Moose::Meta::Class::A-> > {'methods'} => \%B > $B->{'execute'} => \ > %MooseX::Method::Signatures::Meta::Method::C > $MooseX::Method::Signatures::Meta::Method::C-> > {'parsed_signature'} => \%Parse::Method::Signatures::Sig::D > $Parse::Method::Signatures::Sig::D->{'_positional_params'} => \ > %Parse::Method::Signatures::ParamCollection::E > $Parse::Method::Signatures::ParamCollection::E->{'params'} => > \@F > $F->[0] => \ > %Class::MOP::Class::__ANON__::SERIAL::5::G > $Class::MOP::Class::__ANON__::SERIAL::5::G->{'__MOP__'} => \ > %Moose::Meta::Class::H > $Moose::Meta::Class::H->{'_meta_instance'} => \ > %Moose::Meta::Instance::I > $Moose::Meta::Instance::I->{'attributes'} => > \@J > $J->[5] => \%Moose::Meta::Attribute::K > $Moose::Meta::Attribute::K->{'associated_methods'} => > \@L > $L->[2] => \ > %Moose::Meta::Method::Delegation::M > $Moose::Meta::Method::Delegation::M->{'body'} => > \&N > $N variable $self => \$O > $$O => \ > %Moose::Meta::Method::Delegation::M >

Mon Dec 07 15:12:30 2009 harv [...] ruin.nu - Correspondence added

Hi Thanks for your fast reply. It is related to a bug I filed for MooseX- Declare. I'm trying to use anonymous classes for plugins, and would like the memory for old plugins to be reclaimed when they're unloaded or replaced with an updated version. http://rt.cpan.org/Public/Bug/Display.html?id=52295 On Mon Dec 07 14:52:55 2009, STEVAN wrote: Show quoted text

> It is actually common for us to have cycles within the MOP as the

MOP Show quoted text

> is not meant to go away until the interpreter exits. This would be > fixed pretty easily by either doing what you say or by just

extracting Show quoted text

> the values we are using and closing over them instead. However, I > would like to understand what it is your doing that is causing you

to Show quoted text

> feel this cycle is actually a leak and therefore a problem.

Mon Dec 07 15:15:41 2009 stevan.little [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #52537] Memory leak (cycle) Moose::Meta::Method::Delegation body member and $self
Date:	Mon, 7 Dec 2009 15:15:10 -0500
To:	bug-Moose [...] rt.cpan.org
From:	Stevan Little <stevan.little [...] iinteractive.com>

Michael, Okay, this sounds like a reasonable use case, but I think it requires discussion on a level that RT.cpan cannot provide. Please come into IRC so we can discuss. Thanks, - Stevan On Dec 7, 2009, at 3:12 PM, Michael Andreen via RT wrote: Show quoted text

> Queue: Moose > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=52537 > > > Hi > > Thanks for your fast reply. It is related to a bug I filed for MooseX- > Declare. I'm trying to use anonymous classes for plugins, and would > like the memory for old plugins to be reclaimed when they're unloaded > or replaced with an updated version. > > http://rt.cpan.org/Public/Bug/Display.html?id=52295 > > On Mon Dec 07 14:52:55 2009, STEVAN wrote:

>> It is actually common for us to have cycles within the MOP as the

> MOP

>> is not meant to go away until the interpreter exits. This would be >> fixed pretty easily by either doing what you say or by just

> extracting

>> the values we are using and closing over them instead. However, I >> would like to understand what it is your doing that is causing you

> to

>> feel this cycle is actually a leak and therefore a problem.

>

Thu Feb 04 19:19:45 2010 hdp [...] cpan.org - Correspondence added

RT isn't the right place for this discussion.

Thu Feb 04 19:19:48 2010 hdp [...] cpan.org - Status changed from 'open' to 'rejected'