[perl #70183] [BUG] Recently introduced memory leak in loops

2009-11-03 Thread via RT
# New Ticket Created by  Carlin Bingham 
# Please include the string:  [perl #70183]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=70183 >


This did not occur in 657d55cce1f1ded33fd1f731344bd31b33099cb8 but is
present in 6b04b37bb3c06bfb5eb306844b3efbbd54a357cc onwards (I wasn't
unable to get the revisions in between to run).

For example:

loop { my $x = 1; }

The idle REPL from 657d55cce allocated 48.1 MiB (according to System
Monitor). After running that loop for 10 minutes it sat at a constant
49.6 MiB.

Before killing the process, 'free -m' reported:

 total   used   free sharedbuffers cached
Mem:  3900   2620   1279  0341   1282


After killing, it reported:
Mem:  3900   2570   1330  0341   1282


The latest Rakudo (74f561eb77cfe4d7384c1a82ab484d7b63ba8073) allocated
50.8MiB on opening on the REPL.
After 5 minutes of running that loop it had allocated 1GiB.

Before stopping it:

 total   used   free sharedbuffers cached
Mem:  3900   3650249  0341   1282

After:

Mem:  3900   2567   1332  0341   1282

--
Carlin


Re: How does List.map: { .say } work?

2009-11-03 Thread Moritz Lenz
On Mon, Nov 02, 2009 at 10:16:39AM -0500, Solomon Foster wrote:
> On Mon, Nov 2, 2009 at 9:53 AM, Moritz Lenz  wrote:
> > Hi,
> >
> > the current spec doesn't allow immutable containers to call .map with a
> > block that implicitly uses $_ as an implicit parameter.
> >
> > Here's why:
> >
> > S06 says
> >
> >> The C<$_> variable functions as a placeholder in a block without any
> >> other placeholders or signature.  Any bare block without placeholders
> >> really has a parameter like this:
> >>
> >>     -> $_ is rw = OUTER::<$_> { .mumble }
> >
> > So $_ is marked as rw, which is checked at binding time.
> >
> > Now lists are immutable, meaning that you can't bind a list item rw, so
> > even if the block doesn't try to modify $_, calling the { .say } block
> > fails.
> >
> > (Note that 'for' has the same problem)
> >
> > How should that be resolved? Should a temporary variable be created that
> >  can be changed, without any effect? or should it fail() on detecting a
> > modification? Somehow this approach seems very backward to me...
> 
> Is there a reason $_ is readonly isn't a possible solution?

I have no idea how often $_ as an implicit parameter is actually used.
Note that if you want s/// to work, you really need a mutable $_.

If it were just for iteration, I'd not object to making it an ro-alias by
default, requiring an explict rw signature (for example with <-> $_ { ... })
otherwise.

Cheers,
Moritz


Re: How does List.map: { .say } work?

2009-11-03 Thread Carl Mäsak
Moritz (>), Solomon (>>), Moritz (>>>):
>> > the current spec doesn't allow immutable containers to call .map with a
>> > block that implicitly uses $_ as an implicit parameter.
>> >
>> > Here's why:
>> >
>> > S06 says
>> >
>> >> The C<$_> variable functions as a placeholder in a block without any
>> >> other placeholders or signature.  Any bare block without placeholders
>> >> really has a parameter like this:
>> >>
>> >>     -> $_ is rw = OUTER::<$_> { .mumble }
>> >
>> > So $_ is marked as rw, which is checked at binding time.
>> >
>> > Now lists are immutable, meaning that you can't bind a list item rw, so
>> > even if the block doesn't try to modify $_, calling the { .say } block
>> > fails.
>> >
>> > (Note that 'for' has the same problem)
>> >
>> > How should that be resolved? Should a temporary variable be created that
>> >  can be changed, without any effect? or should it fail() on detecting a
>> > modification? Somehow this approach seems very backward to me...
>>
>> Is there a reason $_ is readonly isn't a possible solution?
>
> I have no idea how often $_ as an implicit parameter is actually used.
> Note that if you want s/// to work, you really need a mutable $_.
>
> If it were just for iteration, I'd not object to making it an ro-alias by
> default, requiring an explict rw signature (for example with <-> $_ { ... })
> otherwise.

That would make statement modifier for loops less useful. For those,
there's nowhere to put the lambda arrow.

  ++$_ for @things;

// Carl