Releasing Memory Allocated by Native Libraries in Java

638 views Asked by At

If you are running code that makes calls to a native library in Java, what is the usual way of freeing memory allocated by these libraries when the memory allocation should last for the lifetime of the object? In C++, I would use destructors, but Java never really had those and has them even less now.

The specific case I'm most interested in is JOCL, where I have an object that wraps a compiled OpenCL kernel and all of the arguments thereto that are always the same. Structures representing the compiled kernel and the arguments are all allocated on the library side, and JOCL provides a method clReleaseMemObject that you call to decrement a reference counter indicating when the object should be deleted (note that this is a bit different from directly freeing the memory, but I don't think substantially so in this case).

I presume that if the object is still around when the program terminates, everything is cleaned up by the OS, but I'm not so sure about about objects created in a thread. So:

  1. If you want the native memory deallocated when the object is garbage collected, is there a proper place to call the method that releases this memory?

  2. If the object is one that will last for the duration of a thread, is there a proper place to make this call, or is this even necessary?

1

There are 1 answers

1
Peter Lawrey On BEST ANSWER

What you can do is use a Cleaner. This is a more official API in Java 9 but is available in Java 1.4+.

Essentially you give it a Runnable to execute when the resource is cleaned up.

One advantage of using a Cleaner is you can call it to clean up deterministically, but if you forget or fail to do so, the GC will call it after it runs.

There isn't a safe way to clean up an object when a thread dies as the Thread object can live for the life of the program even if dead. A simpler approach is to clean up as you know it is not needed or after the GC determines it is not required.

Another approach is to use a reference queue and a background thread. It's not as elegant but works across Java 8 and later versions.