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
EvalServer leaks threads and memory when using Proc::Async #6527
Comments
From @AlexDanielFrom this discussion https://irclog.perlgeek.de/perl6-dev/2017-09-16#i_15171820 4) the EvalServer seems to leak memory. it's no longer possible to run 'make spectest', even with -Xmx6000m |
From @usev6On Sat, 16 Sep 2017 07:31:18 -0700, alex.jakimenko@gmail.com wrote:
My findings so far: 1) The EvalServer does not leak memory per se. Assuming a clean EvalServer instance has been started with './perl6-eval-server -cookie TESTTOKEN -app ./perl6.jar' the following does not leak memory: $ echo 'say 42;' > foo.p6 2) Using 'run' (or calling Proc::Async directly) does not leak memory: $ ./perl6-j -e 'for ^5000 { run("echo", "42") }' 3) Feeding the EvalServer with a program that calls 'run' (or Proc::Async directly) does heavily leak memory, threads and what not (again assuming a clean EvalServer instance started as above): $ echo 'run("echo", "42");' > foo.p6 |
The RT System itself - Status changed from 'new' to 'open' |
From @usev6On Sat, 23 Sep 2017 12:28:53 -0700, bartolin@gmx.de wrote:
I'm still trying to find the cause of the memory leak. Part of the problem seems to be that with each invokation of './eval-client.pl TESTTOKEN run foo.p6' three or four additional threads are started. Those threads are never stopped. Some debug statements in src/core/ThreadPoolScheduler.pm indicate that with each invokation (s.a.) a new AffinityWorker instance and a new GeneralWorker instance are created (and at least one other thread). I guess those newly started Threads stay around until the EvalServer is killed. |
From @peschwaOn Thu, 12 Oct 2017 13:35:27 -0700, bartolin@gmx.de wrote:
I've pushed some improvements for this issue in NQP commit b88de49aad. As the commit message notes, there's probably more out there, but this gets us through spectest on hack.p6c.org at least, with a max RES of around 4.5gb. |
Since the EvalServer is not in a good shape (Raku/old-issue-tracker#6527) it makes more sense to just start a new JVM for each test file. Using the new option makes it possible to get the old behaviour.
Since the EvalServer is not in a good shape (Raku/old-issue-tracker#6527) it makes more sense to just start a new JVM for each test file. Using the new option makes it possible to get the old behaviour.
Migrated from rt.perl.org#132104 (status was 'open')
Searchable as RT132104$
The text was updated successfully, but these errors were encountered: