RFR 8062116: JVMTI GetClassMethods is Slow
David Holmes
david.holmes at oracle.com
Mon Nov 3 02:29:29 UTC 2014
Again adding in serviceability.
David
On 1/11/2014 6:17 AM, Jeremy Manson wrote:
> Thanks, Coleen - I saw that you committed it, but the change had a long
> contributed-by line, so I wasn't sure whether you were the right person to
> reach out to.
>
> Jeremy
>
> On Fri, Oct 31, 2014 at 8:36 AM, Coleen Phillimore <
> coleen.phillimore at oracle.com> wrote:
>
>>
>> Jeremy,
>> I will review and sponsor this for you since I wrote the original code.
>> Thanks,
>> Coleen
>>
>>
>> On 10/30/14, 1:02 PM, Jeremy Manson wrote:
>>
>>> There's a significant regression in the speed of JVMTI GetClassMethods in
>>> JDK8. I've tracked this down to allocation of jmethodids in a tight loop.
>>> The issue can be addressed by preallocating enough space for all of the
>>> jmethodids when starting the operation and not iterating over all of the
>>> existing jmethodids when you allocate a new one.
>>>
>>> A patch is here:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/
>>>
>>> A reproducible test case can be found here:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8062116/repro/
>>>
>>> It's a benchmark, though: I have no idea how to turn it into a test.
>>>
>>> For whoever reviews it: can you explain to me why it is okay that this
>>> code
>>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a lot of
>>> problems stemming from accidental reuse.
>>>
>>> Jeremy
>>>
>>
>>
More information about the serviceability-dev
mailing list