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

collection.immutable.TreeMap leaks memory on removing the only element #4084

Closed
scabug opened this issue Dec 14, 2010 · 2 comments
Closed

collection.immutable.TreeMap leaks memory on removing the only element #4084

scabug opened this issue Dec 14, 2010 · 2 comments

Comments

@scabug
Copy link

scabug commented Dec 14, 2010

=== What steps will reproduce the problem? ===

  var t = collection.immutable.TreeMap.empty[Int, Int]
  for (i <- 1 to 100000)
    t = (t + (i -> i) - i)   

=== What is the expected behavior? ===

The loop should require constant memory, regardless of the number of iterations.

=== What do you see instead? ===

The memory footprint is increasing while the loop is running.
When it finishes, there are exactly 100001 TreeMap and RedBlack$$Empty$$ instances that cannot be garbage collected until the reference t goes out of scope.

If you run this loop for a larger number of iterations, you will get an OutOfMemoryError (out of JVM heap space).

=== Additional information ===

The problem goes away, when you always keep at least one element in the TreeMap. This code works correctly:

var t = collection.immutable.TreeMap(0 -> 0)  // never removed
for (i <- 1 to 100000)
  t = (t + (i -> i) - i) 

JVisualVM suggests also that the problem might be related to the $$outer reference preventing 0-sized TreeMap objects from being GCed. (https://lampsvn.epfl.ch/trac/scala/ticket/1419)

=== What versions of the following are you using? ===

  • Scala: 2.8.1.final
  • Java: 1.6.0 update 23
  • Operating system: Windows Vista Home Premium, 32-bit
@scabug
Copy link
Author

scabug commented Dec 14, 2010

Imported From: https://issues.scala-lang.org/browse/SI-4084?orig=1
Reporter: Piotr Koaczkowski (pkolaczk)

@scabug
Copy link
Author

scabug commented Dec 14, 2010

@paulp said:
I believe this is fixed in r23767, but I'm not entirely sure that's not papering over the issue. If anyone feels the problem is inadequately addressed please reopen.

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

1 participant