Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
17
-
b29
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8269550 | 18 | David Holmes | P4 | Resolved | Fixed | b04 |
JDK-8270777 | 17.0.1 | David Holmes | P4 | Resolved | Fixed | b03 |
Description
---
Primitive Array Release Modes:
mode actions
0 copy back the content and free the elems buffer
JNI_COMMIT copy back the content but do not free the elems buffer
JNI_ABORT free the buffer without copying back the possible changes
In most cases, programmers pass "0" to the mode argument to ensure consistent behavior for both pinned and copied arrays. The other options give the programmer more control over memory management and should be used with extreme care.
---
If only mode 0 is used then there are no issues. However if mode JNI_COMMIT is used with an API that introduces a copy of the array, then that copy will "leak" if a second call to the appropriate "release" function is not made with a mode that causes the copy to be freed.
This requirement is not made clear in the specification, and is actually somewhat contradictory in relation to the other aspects of the specification:
- the term "Release" in the API names suggests a single-use method after which the target array has been "released" and must not be referenced again, but we may need to call it again to free the copy
- the specification for Get<X>ArrayElements states "The result is valid until the corresponding Release<X>ArrayElements() function is called." which again suggests only a single call should be made and that the array must not be referenced/used again.
However it is not hard to conceive an intended usage where the array is updated in pieces and the result written back using ReleaseX with mode JNI_COMMIT, before finally (potentially) freeing the buffer with ReleaseX and mode 0/JNI_ABORT. Such usage seems disallowed. Although the spec states "The other options [modes] give the programmer more control over memory management and should be used with extreme care." it sheds no light on the expected or allowed usage of the returned array when JNI_COMMIT is used.
Attachments
Issue Links
- backported by
-
JDK-8269550 [JNI] Clarify the specification in relation to portable use of APIs that involve the Primitive Array Release Modes
- Resolved
-
JDK-8270777 [JNI] Clarify the specification in relation to portable use of APIs that involve the Primitive Array Release Modes
- Resolved
- csr for
-
JDK-8269277 [JNI] Clarify the specification in relation to portable use of APIs that involve the Primitive Array Release Modes
- Closed
- relates to
-
JDK-8300117 Replace use of JNI_COMMIT mode with mode 0
- Resolved
-
JDK-8258186 Replace use of JNI_COMMIT mode with mode 0
- Resolved
-
JDK-8258077 Using -Xcheck:jni can lead to a double-free after JDK-8193234
- Resolved
-
JDK-8300024 Replace use of JNI_COMMIT mode with mode 0
- Resolved