RFR (XXS) JDK-8046919: jni_PushLocalFrame OOM - increase MAX_REASONABLE_LOCAL_CAPACITY

[David Simms]

Thanks Harold...temperate in Stockholm is obviously getting to me...nice 
catch.

I've updated the web review.

Cheers
/D

On 2014-07-08 15:44, harold seigel wrote:
> Hi David,
>
> Should line 840 in jni.cpp be (MaxJNILocalCapacity *<=* 0) || ... ?
>
>  833 JNI_LEAF(jint, jni_EnsureLocalCapacity(JNIEnv *env, jint capacity))
>  834   JNIWrapper("EnsureLocalCapacity");
>  835
>  836   HOTSPOT_JNI_ENSURELOCALCAPACITY_ENTRY(env, capacity);
>  837
>  838   jint ret;
> *  839   if (capacity >= 0 &&**
> **  840       ((MaxJNILocalCapacity == 0) || (capacity <= 
> MaxJNILocalCapacity))) {*
>  841     ret = JNI_OK;
>  842   } else {
>  843     ret = JNI_ERR;
>  844   }
>
> Thanks,
> Harold
>
> On 7/8/2014 9:30 AM, Daniel D. Daugherty wrote:
>> On 7/8/14 5:07 AM, David Simms wrote:
>>> Greetings,
>>>
>>> And here it is again with a flag "MaxJNILocalCapacity" (will require 
>>> CCC before pushing).
>>
>> I don't believe that '-XX:' flags require a CCC approval.
>>
>> Dan
>>
>>
>>>
>>> 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
>>>>>
>>>>
>>>
>>
>