RFR (S) 8247296: Optimize JVM_GetDeclaringClass
david.holmes at oracle.com
Fri Jul 24 06:44:00 UTC 2020
On 24/07/2020 3:54 pm, Yumin Qi wrote:
> Hi, David
> Looks good to me.
Thanks for taking a look at this.
> I have done a quick search and found (may not cover all):
I must stress I am sponsoring Christoph's change and only extended it
within the current file. :) I'm sure there are many, many more
opportunities for similar optimisations. Though you have to be careful
to ensure you don't expose an unhandled oop.
> Where thread_handle resolved multiple times.
True that is unnecessary, but this is a compiler code and I'd need to
extend the review so ... I'll pass on this one.
> Where clazz resolved twice.
Fixed this as it is the same pattern in a core runtime file. Webrev
updated in place.
> Do you want to include those two files in your list?
> On 7/23/20 8:49 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8247296
>> webrev: http://cr.openjdk.java.net/~dholmes/8247296/webrev/
>> Please review this simple optimization contributed by Christoph Dreis
>> in its initial form and then expanded by me to cover other cases in
>> There is a common pattern of code of the form:
>> (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(ofClass)) ||
>> which resolves cls twice. There are also duplicate calls to as_Klass
>> that can be removed in a couple of cases.
>> Testing: tiers 1 - 3
More information about the hotspot-runtime-dev