Quote:
Originally Posted by Colby Skeggs
We couldn't figure out exactly why this happened, but it may be related to the fact that WPILibJ allocates a DirectByteBuffer and lets the Garbage Collector collect it ... every single time that it makes a JNI call. However, I couldn't seem to fix this by caching them, so I'm not sure if it was the issue.
|
There is no real way to guarantee that a DBB is freed, even if you give a user the option. Especially in a Real-Time Operating System where terminating the memory may not necessarily free all reserved memory (WPILib's Deploy Task does kill the process) but you would hope this was tested.
To the OP, you have a few options:
1) Provide an explicit native method that de-allocates the resources held by the native code. This requires direct action but does not require too many changes to your C++ code. Although it does depend on the code itself. The standard library itself has this option although it is hidden in DirectByteBuffer as a Deallocator which makes calls to the hidden VM class, hidden Bits class and makes extensive use of Unsafe operations (obviously... it's native memory). As a side project I worked on more secure DirectBuffer allocation/deallocation myself.
2) Change your code to be re-usable, this is an extension of option 1 really but it just takes that and prevents you from allocating a new Java Object.
3) Run a Profiler. I have been trying to figure out the best way to do it and I don't have access to any kind of control module but deploying in Debug mode should active something from what I have read and seen. Learning how to debug a Java program on Linux might be useful as well, look into using opkg to install some helpful tools. Command Line profiling is always the best.
This is assuming you are
absolutely confident that the problem is the native code and not some other memory allocation gone awry. Watch your references and always micro-test when possible.