Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak caused by inability to notify Julia GC about memory allocated by C++ #73

Open
archit120 opened this issue Nov 26, 2020 · 2 comments
Labels
bug Something isn't working

Comments

@archit120
Copy link

archit120 commented Nov 26, 2020

I was tracking the cause behind a memory leak related to a CxxWrap based project. https://stackoverflow.com/questions/64978891/how-do-i-fix-a-julia-opencv-cxx-memory-leak-in-image-capturing

It seems that Julia's garbage collector does not realize the actual size of objects allocated by C++ and this can cause a memory leak like scenario because the garbage collector isn't destroying objects whose references have already been lost. The underlying issue is that to Julia's garbage collector all C++ allocated objects appear as the size of a pointer. A manual GC run is able to free lost references correctly so the only issue is of having the GC run automatically when needed.

The solution probably involves some way of making Julia GC aware of the real size of objects being allocated by C++ so that the GC can run automatically at appropriate times.

@fingolfin
Copy link
Contributor

I think the title of this issue is not quite correct; there is no leak here, just a failure to trigger GC automatically, which means memory is collected later than desired or even "too late" because some C++ allocation in the meantime fail.

In general it is a difficult problem to handle external memory pressure in a garbage collector. One trick one can use is to replace allocation operations (e.g. in C++ code, use custom new/delete operators). The replacements can either go through the Julia allocator; or they can call the regular allocator, but catch any allocation errors, checking if they are of the "out of memory" kind; if so, run a GC, and try again (and if it fails again, then throw for real).

It's not clear to me whether either could be done in a fully generic fashion, though, esp. since the linked C++ code might also use alternate new/delete implementations...

@archit120
Copy link
Author

Yeah, you're right about the naming. Even though my problem could be mostly resolved with the help of the alternate allocation functions, the checking if "out of memory" method seems somewhat inefficient though because Julia would be sitting on a large pile of unused memory. Another workable fix would be if there was some way to inform Julia about the memory pressure without having to allocate memory through Julia.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants