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

Actors memory leak #1801

Closed
scabug opened this issue Mar 17, 2009 · 4 comments
Closed

Actors memory leak #1801

scabug opened this issue Mar 17, 2009 · 4 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Mar 17, 2009

Code to reproduce the leak:

import scala.actors.Actor._

object Test {

val rt = Runtime.getRuntime()

val sender = actor {
while(true) {
receiver ! new Array[Int] (1048576)
System.gc()
println ("Used Mem: " + (((rt.totalMemory() - rt.freeMemory()) / 1048576.) formatted "%.2f") + " Mb")
}
}

val receiver = actor {
loop {
react {
case x: Array[Int] => println ("received ["+x.length+"]")
}
}
}

def main (args: Array[String]) {
sender
}

}

I does not leak with receive instead of react.
It happens only when sending from another Actor, as was mentioned on mailing list.

Does not leak commenting FJTaskRunner stuff in scala.actors.Scheduler.execute and leaving only
sched execute { fun }

Calling FJTaskRunner.put instead of .push reduces leak gradually but it's still there.
Same happens when calling take() instead of get() in FJTaskRunner.confirmTake, but there is comment why it should not be done.

Anyway, direct calling FJTaskRunner.push from Scheduler.execute seems like a hack, since it is declared "/protected/ public" - it seems it was originally protected and was not supposed to be called from outside.

I can't figure out why is still leaks even with FJTaskRunner.take instead of get, but anyway I see this as potential problem, since VolatileTaskRef is only cleaned in checkOverflow() method which is very rarely called, if ever.

I think the safe way is to leave FJTaskRunner.push as protected, never call it, use only "sched execute { fun }", but I am not sure.

@scabug
Copy link
Author

scabug commented Mar 17, 2009

Imported From: https://issues.scala-lang.org/browse/SI-1801?orig=1
Reporter: Alex Yakovlev (alex14n)

@scabug
Copy link
Author

scabug commented Mar 18, 2009

Alex Yakovlev (alex14n) said:
One more thing I suggest is to add in the end of scala.actors.Reaction.run()

  this.a = null
  this.f = null
  this.msg = null

Thus even if FJTaskRunner will hold 'leaked' references to FJTask and Reaction, it will hold no references to user's (huge) data. This can happen if we create a lot of actors that will fill FJTaskRunner's array of VolatileTaskRef that are not nulled because of get() instead of take()

@scabug
Copy link
Author

scabug commented Mar 25, 2009

@phaller said:
Fixed in r17380 (trunk) and r17381 (2.7.x).

@scabug
Copy link
Author

scabug commented Dec 2, 2009

@phaller said:
(In r19988) Moved non-deterministic test for see #1801 to pending.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants