RFR (XXXS): 8193234: When using -Xcheck:jni an internally allocated buffer can leak
David Holmes
david.holmes at oracle.com
Thu Feb 7 22:59:08 UTC 2019
Hi Aleksey,
Thanks for looking at this.
On 8/02/2019 1:53 am, Aleksey Shipilev wrote:
> On 2/7/19 11:13 AM, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8193234
>> webrev: http://cr.openjdk.java.net/~dholmes/8193234/webrev
>
> The patch looks good.
>
>> Full details in bug report but basically with the use of GuardedMemory in the checked versions of
>> the *ArrayCritical functions we always have to release the GuardedMemory copy.
>
> Ah, oops. It seems fine to free the copy of guarded memory unconditionally. While you are at it,
> switch statement can also be simplified by coalescing case labels. It also makes the dichotomy
> between "normal" and "abort" paths evident:
>
> switch (mode) {
> case 0:
> case JNI_COMMIT:
> memcpy(orig_result, carray, sz);
> break;
> case JNI_ABORT:
> break;
> default:
> ...
> }
The coalescing is only possible because we never uses copies and so
never have to free them - which is the difference between modes 0 and
JNI_COMMIT. But I can do that and add a clarifying comment.
Thanks,
David
> -Aleksey
>
More information about the hotspot-runtime-dev
mailing list