Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory leak on eval #2133

Closed
p6rt opened this issue Sep 2, 2010 · 11 comments
Closed

memory leak on eval #2133

p6rt opened this issue Sep 2, 2010 · 11 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Sep 2, 2010

Migrated from rt.perl.org#77644 (status was 'resolved')

Searchable as RT77644$

@p6rt
Copy link
Author

p6rt commented Sep 2, 2010

From @bbkr

Star 2010.08 release

Run folloing code and it will start eating up memory quite fast.

$ perl6 -e 'use Test; eval_lives_ok "" for 1..10000'

[11​:59] <moritz_> eval '' while 1; also leaks
[11​:59] <moritz_> so I think it's eval() that leaks

@p6rt
Copy link
Author

p6rt commented Sep 2, 2010

From @pmichaud

On Thu, Sep 02, 2010 at 03​:02​:43AM -0700, PaweÅ� Pabian wrote​:

Star 2010.08 release

Run folloing code and it will start eating up memory quite fast.

$ perl6 -e 'use Test; eval_lives_ok "" for 1..10000'

[11​:59] <moritz_> eval '' while 1; also leaks
[11​:59] <moritz_> so I think it's eval() that leaks

Currently each eval() execution results in compiling and
loading at least two additional Parrot subs into memory
that represent the eval'ed code. As far as I can tell,
once loaded there's currently no way for a Parrot Sub PMC
to become "unloaded" or GC'ed -- it stays in memory until
the process ends. So, it's not too surprising the above leaks.

We probably need to file a Parrot ticket to get Parrot to
support garbage collection of Sub PMCs when they're no
longer used.

We might be able to find a way for eval() to cache the
results of its compilation, so that if it's called again
given the same string and from the same outer context
it re-uses an already-compiled version rather than
re-compiling things anew. But I don't envision that
being done anytime soon, and it won't help in the case
where each eval string is in fact different on each
evaluation.

Pm

@p6rt
Copy link
Author

p6rt commented Sep 2, 2010

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

@p6rt
Copy link
Author

p6rt commented Sep 2, 2010

From @coke

On Thu, Sep 2, 2010 at 10​:35 AM, Patrick R. Michaud <pmichaud@​pobox.com> wrote​:

On Thu, Sep 02, 2010 at 03​:02​:43AM -0700, PaweÅ� Pabian wrote​:

Star 2010.08 release

Run folloing code and it will start eating up memory quite fast.

$ perl6 -e 'use Test; eval_lives_ok "" for 1..10000'

[11​:59] <moritz_> eval '' while 1; also leaks
[11​:59] <moritz_> so I think it's eval() that leaks

Currently each eval() execution results in compiling and
loading at least two additional Parrot subs into memory
that represent the eval'ed code.  As far as I can tell,
once loaded there's currently no way for a Parrot Sub PMC
to become "unloaded" or GC'ed -- it stays in memory until
the process ends.  So, it's not too surprising the above leaks.

We probably need to file a Parrot ticket to get Parrot to
support garbage collection of Sub PMCs when they're no
longer used.

We might be able to find a way for eval() to cache the
results of its compilation, so that if it's called again
given the same string and from the same outer context
it re-uses an already-compiled version rather than
re-compiling things anew.  But I don't envision that
being done anytime soon, and it won't help in the case
where each eval string is in fact different on each
evaluation.

Pm

I wonder if this related to http://trac.parrot.org/parrot/ticket/783

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Sep 2, 2010

From @pmichaud

On Thu, Sep 02, 2010 at 11​:20​:52AM -0400, Will Coleda wrote​:

Currently each eval() execution results in compiling and
loading at least two additional Parrot subs into memory
that represent the eval'ed code.  As far as I can tell,
once loaded there's currently no way for a Parrot Sub PMC
to become "unloaded" or GC'ed -- it stays in memory until
the process ends.  So, it's not too surprising the above leaks.

We probably need to file a Parrot ticket to get Parrot to
support garbage collection of Sub PMCs when they're no
longer used.

I wonder if this related to http://trac.parrot.org/parrot/ticket/783

Indeed it is, the script in that ticket is quite similar to the
one I used to verify that anonymous subs don't get gc'd.
Great catch, we can keep an eye on TT #​783 for this one.

Pm

@p6rt
Copy link
Author

p6rt commented May 28, 2012

From @coke

On Thu Sep 02 08​:37​:25 2010, pmichaud wrote​:

On Thu, Sep 02, 2010 at 11​:20​:52AM -0400, Will Coleda wrote​:

Currently each eval() execution results in compiling and
loading at least two additional Parrot subs into memory
that represent the eval'ed code. �As far as I can tell,
once loaded there's currently no way for a Parrot Sub PMC
to become "unloaded" or GC'ed -- it stays in memory until
the process ends. �So, it's not too surprising the above leaks.

We probably need to file a Parrot ticket to get Parrot to
support garbage collection of Sub PMCs when they're no
longer used.

I wonder if this related to http://trac.parrot.org/parrot/ticket/783

Indeed it is, the script in that ticket is quite similar to the
one I used to verify that anonymous subs don't get gc'd.
Great catch, we can keep an eye on TT #​783 for this one.

Pm

This trac ticket was closed 7 months ago​:

"This issue is going to be fixed with GC-able packfiles, which are high up on our TODO list of
development priorities. Since this is basically just a TODO item, I'm going to close this ticket.
There's no chance that we just forget about the underlying need."

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Oct 23, 2014

From @usev6

As a status update​: An empty EVAL combined with "while 1" still seems to consume more and more memory (happens on Moar, Parrot and JVM)​:

$ perl6 -e 'EVAL q[] while 1'

1 similar comment
@p6rt
Copy link
Author

p6rt commented Oct 23, 2014

From @usev6

As a status update​: An empty EVAL combined with "while 1" still seems to consume more and more memory (happens on Moar, Parrot and JVM)​:

$ perl6 -e 'EVAL q[] while 1'

@p6rt
Copy link
Author

p6rt commented Feb 17, 2017

From @MasterDuke17

On Thu, 23 Oct 2014 11​:55​:01 -0700, bartolin@​gmx.de wrote​:

As a status update​: An empty EVAL combined with "while 1" still seems
to consume more and more memory (happens on Moar, Parrot and JVM)​:

$ perl6 -e 'EVAL q[] while 1'

Memory use while running this is now constant as of Rakudo version 2017.01-221-gc2349d1a6 built on MoarVM version 2017.01-72-g542baec7 implementing Perl 6.c.

@p6rt
Copy link
Author

p6rt commented Mar 25, 2017

From @MasterDuke17

perl6 --version
This is Rakudo version 2017.02 built on MoarVM version 2017.02

`perl6 -e 'EVAL q[] while 1'` ran for 30+ min with constant RAM used, so I'm resolving this ticket.

@p6rt
Copy link
Author

p6rt commented Mar 25, 2017

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

@p6rt p6rt closed this as completed Mar 25, 2017
@p6rt p6rt added the perf label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant