Hhot-swap memory leak?

Poster Content
nk4um Administrator
Posts: 607
January 28, 2016 09:04

It's bounded because unlike resources which can be infinite and dynamically instantiated classes are static and finite being bound to .class files inside deployed modules.

Cheers, Tony

Like · Post Reply
nk4um User
Posts: 90
January 28, 2016 08:26

Hello Tony,

good to hear from you.

>>However the number of Java classes is not unbounded unless modules are dynamically reloaded.

I'm curious how this is done. The JavaRuntimeAccessor has an mEndpointCache and this is a private member without getters/setters. How is the number bound? Is the endpoint re-instantiated from time to time?

Thanks for the quick response, Stefan

Like · Post Reply
nk4um Administrator
Posts: 607
January 27, 2016 19:42

Hi Stefan,

I've looked at the JavaRuntimeAccessor and indeed it doesn't clear cached classes. This is probably an oversight. However the number of Java classes is not unbounded unless modules are dynamically reloaded.

This is in contrast to the groovy runtime which has a cache which is actively managaged because it's classes can be dynamically instantiated from other resources.

I'll make a fix to this and we'll release it soon,

Cheers, Tony

Like · Post Reply
nk4um User
Posts: 90
January 27, 2016 14:33Hhot-swap memory leak?

Hello,

I'm working on an application and use the modeule.d directory together with the gradle plugin to build and hot-swap my modules. After around a day a heap memory problem occurs and I tried to find the cause. I think it's the JavaRuntimeAccessor accumulating cached endpoints between the unloading and loading of the modules during the hot-swap.

This is a screenshot of a heap dump after a fresh NK start and some computing:

heap dump 1

You can see that there is one cached endpoint in inside mEndpointCache of type stefan.lm.files.FindDuplicateFilesAccessor which is correct. It delivers a 4MB response string which can be found in the representation cache as desired.

This is the picture after several hot-swaps, each hot-swap adding another endpoint to mEndpointCache and eating up heap space:

Heap dump 2

This behaviour can be reproduced. Now my questions:

- What can be done to avoid this?

- Has this something to do with configuration or bad design of my endpoints or module structure or the kind of hot-swap via gradle or is it something else?

- It looks like several runtime accessors have their own cache (e.g. GroovyRuntime). Aren't these caches vulnerable to memory leaks or is there a process that takes care of this?

- Is it advisable to use hot-swap in productions systems (I'm using NK SE)?

Thanks, Stefan

Like · Post Reply