From @zoffixznet

This program starts off at 140MB and rapidly grows to 1.7GB of used RAM by the 1000th iteration​:

perl6 -e 'for ^1000 { say "Iter $_"; "foo".subst​: :g, /<{"abc".comb.join("\\s")}>/, "" }'

If the interpolated string is changed to just "a\\sb\\sc", the issue goes away.

And if we store the computation in a variable first and then use the variable in a regex, the leak seems to be much less severe (but still present; leaks up to about 500MB by the 1000th iteration)​:

perl6 -e 'for ^100000 { say "Iter $_"; my $x = "abc".comb.join("\\s"); "foo".subst​: :g, /<$x>/, "" }'

From @zoffixznet

Present today's HEAD on rakudo-moar a45202

From @jnthn

On Thu Sep 01 09​:28​:21 2016, cpan@​zoffix.com wrote​:

This program starts off at 140MB and rapidly grows to 1.7GB of used
RAM by the 1000th iteration​:

perl6 -e 'for ^1000 { say "Iter $_"; "foo".subst​: :g,
/<{"abc".comb.join("\\s")}>/, "" }'

If the interpolated string is changed to just "a\\sb\\sc", the issue
goes away.

And if we store the computation in a variable first and then use the
variable in a regex, the leak seems to be much less severe (but still
present; leaks up to about 500MB by the 1000th iteration)​:

perl6 -e 'for ^100000 { say "Iter $_"; my $x = "abc".comb.join("\\s");
"foo".subst​: :g, /<$x>/, "" }'

Boiled down to an EVAL-related leak, which was in turn due to a serialization context management bug in MoarVM. Fixed now; it grows to a point then settles.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'