Hello,
So i've adapted/improved the source code that someone post on the InMoov website that lets you control a robothand with leapmotion, its working pretty decently but i have an issue where memory keeps increasing, as if there was a memory leak, here is the source code :
Is it a python memory leak or Java ?
Thanks in advance.
Hi Herzeh, Rarely does Java
Hi Herzeh,
Rarely does Java have a memory leak. Memory leak is memory which can not be recovered, and Java was one of the first popular languages which had its own garbage collection. "Garbage" in this context means "memory which will no longer be used".
Typically in Java its - "Memory mismanagement" - where a billion objects are created, but references to them are never released - and you don't care about them anymore.
You asked if the memory leak would be in Python or Java. In MRL we are using Jython which is Python completely implemented in Java .. so really its still Java.
There is a possiblity of a true memory leak in the JNI layer and/or LeapMotion SDK dlls. Since its written in C it is vulnerable to memory not being manually deallocated.
I listed the general possibilities, now lets look at some of the specifics.
Its a huge Python script - so that makes it a little challenging. The first thing I would look for is containers (Arrays, Map, Dictionaries) .. which are being added to, but nothing removed. It looks clear of that problem.
The next thing I would probably consider is the speed and quanity of new objects being created. Java garbage collection is a wonderful thing, but its rate at getting back memory sometimes needs to be tuned. The frame says 40 times a second, which is not "super quick", but that's not the whole story. If your given 40 marbles a second you won't run out of room, but if someone gives you 40 bookcases a second - you would be squashed.. quickly.
The first thing I would do is let it run for a while... This will provide a little insite into the nature of the problem. Does it crash with an error which says "Java Heap out of memory" .. or does it continue on for a very long time with a lot of memory but not crashing?
The next thing I would is try to reduce the complexity of the problem. Just try it without any of the Python code except maybe printing some part of the frame. Does that behave the same way?
Guess we're going to need a bigger heap...
Upon a quick review of the code, as GroG mentioned, the python code does not seem to have anything that jumped out at me as growing memory out of control.
The problem might be in the JNI layer (if so, it's not heap related.. and we'll have to see if maybe there's a new version of the leap motion apis. that might help.)
If the problem is in java land, there's 2 possibilities.
1. it actually takes this much memory.
2. there is a leak.
3. there is no leak, it just looks like one.
If the case is #1 , try launching java / myrobotlab with a larger heap size.. from the command prompt you should be able to run something like the following
java -Xmx2g -jar myrobotlab.jar
This will launch java with a 2GB heap size. (not sure what the default is.. but you can try increasing that number...
If it's case #2 .. well. we'll have to review the java code to see if there's any lists/sets/maps that are growing out of control...
If it's number #3 ... well.. the question is do you ultimately end up with an OutOfMemory exception in the log files? Java will allocate system memory until it reaches the max heap size (as specified by the -Xmx value.) Java will never release this memory back to the operating system. If you don't see the OutOfMemory exception, perhaps you're just observing this behavior of Java..
Alright ill check all of this
Alright ill check all of this monday once i get back to work.
Resent Herzeh's log-files to
Resent Herzeh's log-files to your email's (GroG & kwatters). Maybe they help, they mostly contain that onFrame was called, followed by a few servo-movements.
I've tried this inmoov script
I've tried this inmoov script and it takes up to 1.4Go of memory : https://github.com/MyRobotLab/pyrobotlab/blob/master/toSort/InMoov2.Cop…
Also i noticed that the leapmotion script posted actually doesn't exceed 1.2Go of ram, it doesn't go down when i don't put my fingers in front of leapmotion either so i don't know if thats normal behavior ?
Doesnt exceed is good ... it
Doesnt exceed is good ... it sounds like many intermediate objects are being created very fast and the garbage collector finds it difficult with its current settings to keep up.
Without similar hardware its difficult for us to diagnose