VanillaChronicleMap instances stay in heap.

[jdoe]

Hello,

After using of few dozens of CroniclaMap instances and proper closing them I noticed that Java heap still contains lots of VanillaChronicleMap instances. GC root of this objects leads to a ThreadLocal storage that together seems to make a loop. 

Is it a leak? Can I do something with these instances that keep staying there in order to discard them?

Thanks in advance!

[Roman Leventov]

This is a leak, which should be fixed in the new release: https://github.com/OpenHFT/Chronicle-Map/releases/tag/chronicle-map-3.11.0

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicle+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jdoe]

Thanks for your response, but it seams that there's still a lot to amend: under 3.10.1 profiler showed 54 VanillaChronicleMap instances retained. Now (under 3.11.0) they gone but difference between two sequential runs of the same task clearly shows that few leaks are still there (keep in mind original 54 instances):

On Monday, November 21, 2016 at 5:08:33 AM UTC+2, Roman Leventov wrote:

This is a leak, which should be fixed in the new release: https://github.com/OpenHFT/Chronicle-Map/releases/tag/chronicle-map-3.11.0

On 20 November 2016 at 11:50, jdoe <ua.s...@gmail.com> wrote:

Hello,

After using of few dozens of CroniclaMap instances and proper closing them I noticed that Java heap still contains lots of VanillaChronicleMap instances. GC root of this objects leads to a ThreadLocal storage that together seems to make a loop. 

Is it a leak? Can I do something with these instances that keep staying there in order to discard them?

Thanks in advance!

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.

[Roman Leventov]

Thanks for this analysis. Are you sure this is a dump of live, not all objects? Maybe those object just not yet collected by GC, because it needs another GC cycle, after VanillaChronicleMap is collected itself? Because I cannot understand how those objects on your chart could leak, if VanillaChronicleMap is collected. ThreadLocal is an instance field of VanillaChronicleMap (cxt) and seems that it doesn't leak anywhere, I've just double-checked that.

To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicle+unsubscribe@googlegroups.com.

[jdoe]

Yes, I'm sure I performed a lot of GCs in order to get the real picture. Having played with a randomly picked item from the list I also noticed some ThreadLocal instances that hold reference on it.

[Roman Leventov]

Ok, I think the likely reason is that ThreadLocalMap's entries are not cleared automatically over time and GC cycles -- they are cleared only when some other ThreadLocal in the subject thread is inserted or updated. So if in your threads there is no (much) other ThreadLocal activity, entries, strongly referencing Chronicle Map's contexts (CompiledMapQueryContext on your chart) might stay on heap for long time.

I acknowledge this is a problem and will fix this in the next release.

To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicle+unsubscribe@googlegroups.com.