You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
Appologies if the issue ends up not being in your library, I'm trying to debug a memory leak in a larger program and have managed to reproduce it in a small sample, just thought I'd run it past you first.
With the above program the 10 bytes objects are never collected by the GC, I've had a quick look through the threaded executor and thread pool class and it doesn't seem like they hold references to the futures after they've been ran so I'm not sure as to why the bytes objects are not collected.
My understanding is that the closure passed to the submit function will capture the bytes object, and since nothing else has a reference to it (and they won't be on the stack after the function returns) they should be eligiable for collection after the future is completed.
While the debug info and forced GC running is hxcpp specific I get the same behaviour on hashlink. I was kind of hoping writing this all out would help me understand the issue a bit more but I'm still not sure, I could just be mis-understanding how GCs work with closures. In any case it would be good to get a confirmation that the executor shouldn't be holding a reference to anything in this case.
Cheers!
The text was updated successfully, but these errors were encountered:
Hello,
Appologies if the issue ends up not being in your library, I'm trying to debug a memory leak in a larger program and have managed to reproduce it in a small sample, just thought I'd run it past you first.
With the above program the 10 bytes objects are never collected by the GC, I've had a quick look through the threaded executor and thread pool class and it doesn't seem like they hold references to the futures after they've been ran so I'm not sure as to why the bytes objects are not collected.
My understanding is that the closure passed to the submit function will capture the bytes object, and since nothing else has a reference to it (and they won't be on the stack after the function returns) they should be eligiable for collection after the future is completed.
While the debug info and forced GC running is hxcpp specific I get the same behaviour on hashlink. I was kind of hoping writing this all out would help me understand the issue a bit more but I'm still not sure, I could just be mis-understanding how GCs work with closures. In any case it would be good to get a confirmation that the executor shouldn't be holding a reference to anything in this case.
Cheers!
The text was updated successfully, but these errors were encountered: