-
Notifications
You must be signed in to change notification settings - Fork 8
Node::ValueAt may be leaking memory #113
Comments
Original impl used a reference as a key in native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode. This allowed to get rid of global reference in 2 places, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Original impl used a reference as a key in native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode. This allowed to get rid of global reference in 2 places, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Original impl used a reference as a key in a native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode for a map key. This should allow to get rid of global reference in interface lookup, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Original impl used a reference as a key in a native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode for a map key. This should allow to get rid of global reference in interface lookup, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
This is a good observation, but merely implementing the suggestion will result in test failures. I have submitted a patch for what seems to be one of the causes of this at #116 (cann't use refs as keys for the map really) but it is still a partial solution - if global ref is removed there, it will fail the I suggest also adding to the scope of this issue identifying the reason of why does It does not seem to need one for the same reasons, doesn't it? But removing it causes I hope that new materials from #115 on JNI debugging at CONTRIBUTING.m will help to find an answer. IMO it makes sense to start with this one and when fixed 🔪 a release, so added it to v2.0.1 milestone. |
Original impl used a reference as a key in a native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode for a map key. This should allow to get rid of global reference in interface lookup, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Signed-off-by: ncordon <[email protected]>
Signed-off-by: ncordon <[email protected]>
Signed-off-by: ncordon <[email protected]>
Original impl used a reference as a key in a native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode for a map key. This should allow to get rid of global reference in interface lookup, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Signed-off-by: ncordon <[email protected]>
Signed-off-by: ncordon <[email protected]>
Original impl used a reference as a key in a native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode for a map key. This should allow to get rid of global reference in interface lookup, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Signed-off-by: ncordon <[email protected]>
Signed-off-by: ncordon <[email protected]>
Original impl used a reference as a key in a native map, but in JNI object references are neither constant nor unique, and thus were violating the contract on hashCode for a map key. This should allow to get rid of global reference in interface lookup, but there are 2 more (clearly identified) cases where we still rely on side-effects of having a glabal reference and thus leak some memory Signed-off-by: Alexander Bezzubov <[email protected]>
Signed-off-by: ncordon <[email protected]>
Signed-off-by: ncordon <[email protected]>
Closed by #116 |
After a glimpse to the methods in
Node
(C++ side), I have the (untested of course) hypothesis thatValueAt
may be leaking memory.ValueAt
creates new global ref for and objectobj
and callslookupOrCreate(obj)
lookupOrCreate
tries to find aNode
forobj
(if it previously existed, we created a new reference to it, and we are only deallocating one). If noNode
existed, calls the constructor ofNode
, which creates a new reference toobj
, but we do not release the original one at any point D:Proposed solution is end
ValueAt
method with:instead of
The text was updated successfully, but these errors were encountered: