On Thu, Sep 2, 2010 at 10:35 AM, Patrick R. Michaud <pmich...@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
