- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Another problem with TreeMap: possible memory leak?
Tue, 2010-12-14, 18:08
Hello,
I'm debugging a memory leak in my application and I've found some thing
that worries me. My application runs some process in iterations - every
iteration modifies a few queues of events. The queues are implemented as
immutable TreeMaps (long story why a TreeMap, and not a Queue, but
irrelevant to this problem).
After performing 10000 iterations, the heap dump made by the JVisualVM
reports extremely large number (20000) of TreeMap and RedBlack$Empty$
objects (about 20000 + a few). Moreover, almost all of these TreeMap
objects are of size 0 (only 4 objects are of size >0, the largest
TreeMap has size 4). From the reference graph in JVisualVM I can see
that these 0-sized TreeMaps are connected with long chains of references
in a form of:
this <- $outer <- t <- $outer <- t <- $outer <- .....
where t is a TreeMap, and $outer is a RedBlack$Empty$.
These chains can be several **hundred** **different** objects long (or
more, I don't know how to check that exactly). Except a few root
objects, JVisualVM heap analyzer does not report large number of
references from objects of other types pointing to TreeMaps :(
Ok, so now the questions:
1. Is it normal behaviour?
2. How can I debug it better - whether it is my bug, or Scala bug?
BTW: I'm working hard on isolating the issue, but unfortunately the
program is quite complex and it is not an easy task. TreeMaps are used
in several places - I must check them all... It would be probabnly
easier if there existed some other immutable TreeMap implementation with
a similar API, so that I could switch to it and check if the problem
disappears.
Regards,
Piotr Kołaczkowski
Tue, 2010-12-14, 18:57
#2
Re: Another problem with TreeMap: possible memory leak?
Hi!
Ok, so I now isolated the issue.
Here is the code:
var t = collection.immutable.TreeMap.empty[Int, Int]
for (i <- 1 to 100000)
t = (t + (i -> i) - i)
println(t.size) // prints 0
Run this and see that this creates 100001 instances of TreeMap objects
that are **not** GCed.
A slight modification makes the memory leak disappear:
var t = collection.immutable.TreeMap(0 -> 0)
for (i <- 1 to 100000)
t = (t + (i -> i) - i)
println(t.size) // prints 1
So I guess there is some problem with how empty maps are implemented...
Where to file the bug report?
Regards,
Piotr Kołaczkowski
W dniu 2010-12-14 18:19, Paul Phillips pisze:
> On Tue, Dec 14, 2010 at 06:07:20PM +0100, Piotr Kołaczkowski wrote:
>> this<- $outer<- t<- $outer<- t<- $outer<- .....
>
> For some related issues see:
>
> https://lampsvn.epfl.ch/trac/scala/ticket/854
> https://lampsvn.epfl.ch/trac/scala/ticket/1419
>
> It may be more difficult to address in this example. The issue has been
> steadily rising in urgency.
>
Tue, 2010-12-14, 19:27
#3
Re: Re: Another problem with TreeMap: possible memory leak?
On Tue, Dec 14, 2010 at 06:29:53PM +0100, Piotr Kołaczkowski wrote:
> So I guess there is some problem with how empty maps are implemented...
In r23767 I made it create a fresh empty if you remove the last element.
Your example runs in constant space.
On Tue, Dec 14, 2010 at 06:07:20PM +0100, Piotr Kołaczkowski wrote:
> this <- $outer <- t <- $outer <- t <- $outer <- .....
For some related issues see:
https://lampsvn.epfl.ch/trac/scala/ticket/854
https://lampsvn.epfl.ch/trac/scala/ticket/1419
It may be more difficult to address in this example. The issue has been
steadily rising in urgency.