Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8258185

[JNI] Clarify the specification in relation to portable use of APIs that involve the Primitive Array Release Modes

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b29

      Backports

        Description

        The ReleasePrimitiveArrayCritical and Release<X>ArrayElements APIs both use a "release mode" to determine how to update the target array and how to free it if it were a copy:

        ---
        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

              Activity

                People

                Assignee:
                dholmes David Holmes
                Reporter:
                dholmes David Holmes
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: