I’m still learning to use JOCL and I can’t seem to figure out how to fix an apparent memory leak in the JOCLSimpleConvolution.java sample on the JOCL homepage.
Simply put, using the sample .java, .cl, and .png files from the site, it compiles fine and runs fine for about 16 filters, and then crashes with a „CL_OUT_OF_RESOURCES“ error, which appears to be a simple memory leak. What I did to cause the program to crash was just to keep switching between two filters, like to continually switch between Edge Detection and Sharpen. You can see the problem slowly forming in that the times for the JOCL filter application slowly rise, and then about the 16th switch, the problem comes to fruition with an out of resources error.
My first attempt to fix the problem was to try and ensure all of the allocated memory on the device was released after use, so I tried to add some additional lines, like:
adding the line „clReleaseProgram(program);“ at the end of the „JOCLConvolveOp“ function (since it was a local variable)
adding the lines „finalize“ function:
clReleaseContext(context);
clReleaseCommandQueue(commandQueue);
clReleaseKernel(clKernel);
But nope, still crashes. In an effort to better learn how to use JOCL, could someone let me know what the secret is to happy convolution? KThnxBye
Indeed, this example is flawed: The resources are not released properly. However, when they are released, it seems to be working. As a quick test (and only as a test!) I inserted the following
Removed the code that did not completely solve the problem, the new sample has been uploaded to the website
Each time the “create(Kernel kernel)” Method is called, ‘release’ will be called on the object that was previously created. But of course, this is not an appropriate solution, and only for a quick test. I’ll try to find a better solution and update the sample accordingly (although it may be difficult to integrate the OpenCL-specific releasing of resources nicely into the BufferedImageOp - but there’s no alternative to that)
The code snippet that I orginally posted above was not sufficient (other pars of the sample still had been wrong - once again a proof that finalizers should not be used for resource management :o )
Thanks a lot for the help! It turns out that you’re totally right with the „finalize“ being the issue. In some „sandbox“ code I wrote (to help me start learining openCL) I was getting the same „out of resources error,“ and it was solved by moving my "clRelease"s from the „finalize“ function into a separate function.
As far as the simpleConvolution sample, I tried to get the updated version from the web site (jocl.org - Samples) but it was the same one as yesterday with the memory leak I tried to fix the memory leak again myself by moving the "clRelease"s to the end of the „filter“ function, but no luck
I would be interested in seeing the final version of the simpleconvolution example tho when it’s fixed to figure out what I missed to fix the memory leak.
Hm… I just checked it again, it should be the updated version on the website. I also started it and scrolled through the filters several times, and don’t receive any error. Are you sure that you have the version with the newly added “shutdown” method that is called after the convolution kernel has been applied?
The idea of using finalizers is tempting, but it simply does not work. They are called when the JVM wants to call them. This usually means: They are called when the JVM needs more memory. And of course, the memory of the VM is completely unrelated to the OpenCL resources.
I would not do this any longer today, but I created this sample quite a while ago, when I was not so aware of the problems with finalizers, and thought that finalizers would be called “quickly” after the object is not reachable any more, but this is not the case…
If you still encounter problems with the updated version (with the ‘shutdown’ method), could you please tell me which Operating System / OpenCL implementation you are using?
Hokay, I have the new file now. Seems my browser was caching the previous version, but I’ve got the current version now with the „shutdown“ method. Soooo… nope, it still crashes The 16th swap causes it to crash on my system. The only reason I knew to go past 10 swaps is because the time it took JOCL to „sharpen“ was:
JOCL: 4.18 ms
JOCL: 4.28 ms
JOCL: 4.56 ms
JOCL: 5.03 ms
JOCL: 5.17 ms
JOCL: 5.43 ms
JOCL: 5.69 ms
JOCL: 6.05 ms
and then the program crashed. You might consider doing the same test, and if you see the times to sharpen slowly rise, see if your version also crashes or if it reaches a maximum time for JOCL eventually
So, my OS is win 7 64-bit. I’m not sure how to see what openCL version I have, but the top lines of the „device query“ sample says:
Number of platforms: 1
Number of devices in platform NVIDIA CUDA: 1
— Info for device GeForce GTX 460: —
CL_DEVICE_NAME: GeForce GTX 460
CL_DEVICE_VENDOR: NVIDIA Corporation
CL_DRIVER_VERSION: 285.62
CL_DEVICE_TYPE: CL_DEVICE_TYPE_GPU
That’s strange: I started it again, and kept switching quickly between „Edge detection“ and „Sharpen“ for 300 times (!) and did not see any increase in the required time, and no crash. What’s even more surprising is that I’m also using Win7/64 here, so it can not be related to the OS. (My driver version is 285.86, but this should not be related to this issue).
At the moment I have no idea what might be the reason for this Just to be sure: You’re using JOCL 0.1.7, with the latest version of the sample, and after ~16 swaps it still crashes with the same „CL_OUT_OF_RESOURCES“ that you mentioned in the first post!?
I doubt that it will contain anything that will be very helpful in this case, but you might try to add
CL.setLogLevel(LogLevel.LOG_TRACE);
as the first line of the main() method, and possibly post the output here (or via PN or mail), but according to my trace, everything seems to be created and cleaned up properly… -_-
Just as an aside: Did you encounter similar problems in other samples? (Although most other samples are not really “structurally similar” to that one… I’m just trying to figure out whether this problem is related to the sample, JOCL itself, or something else…)
I tried to fix the memory leak again myself by moving the "clRelease"s to the end of the „filter“ function, but no luck 
Just to be sure: You’re using JOCL 0.1.7, with the latest version of the sample, and after ~16 swaps it still crashes with the same „CL_OUT_OF_RESOURCES“ that you mentioned in the first post!?