RFR (XXS) JDK-8046919: jni_PushLocalFrame OOM - increase MAX_REASONABLE_LOCAL_CAPACITY
Frederic Parain
frederic.parain at oracle.com
Tue Jul 8 11:49:09 UTC 2014
Two minors points:
src/share/vm/runtime/globals.hpp:
line 1221: typo Capicity -> Capacity
src/share/vm/prims/jni.cpp:
line 735: parentheses around "capacity < 0"
looks superfluous but test is correct
Once fixed, it looks good to me.
Fred
On 08/07/2014 13:07, David Simms wrote:
> Greetings,
>
> And here it is again with a flag "MaxJNILocalCapacity" (will require CCC
> before pushing).
>
> Web review: http://cr.openjdk.java.net/~dsimms/8046919/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8046919
>
> /David Simms
>
> On 2014-07-07 14:47, David Simms wrote:
>>
>> Agree on adding a flag, will update the patch...
>>
>>
>> On 2014-07-07 13:40, Frederic Parain wrote:
>>> Looks good to me.
>>> I'm just wondering if we really want to keep an arbitrary
>>> value hard code in our code, or if there's a real use
>>> case to have a tunable parameter to implement this limit
>>> (I'm OK with both solutions).
>>>
>>> Regards,
>>>
>>> Fred
>>>
>>> On 07/07/2014 13:25, David Simms wrote:
>>>> Greetings,
>>>>
>>>> Small fix to adjust the local JNI handle capacity check
>>>> (MAX_REASONABLE_LOCAL_CAPACITY) for "EnsureLocalCapacity" and
>>>> "PushLocalFrame", from 4k to 64k handles.
>>>>
>>>> This fairly arbitrary number is currently meant for sanity checking the
>>>> "capacity" argument, actual handle allocation is "lazy on demand" as
>>>> "JNIHandleBlock" are never freed (but placed on free list).
>>>>
>>>> Bug URL: https://bugs.openjdk.java.net/browse/JDK-8046919
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~dsimms/8046919/
>>>>
>>>> Testing: jprt, Test7007040 (see: JDK-7007040), and internal tests:
>>>> "vm.quick.testlist nsk.jvmti.testlist vm.runtime.testlist
>>>> WeblogicMedrec
>>>> runThese Kitchensink"
>>>>
>>>> Cheers
>>>> /David Simms
>>>
>>
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
More information about the hotspot-runtime-dev
mailing list