RFR: 8265129: Add intrinsic support for JVM.getClassId [v6]

Denghui Dong ddong at openjdk.java.net
Fri May 21 08:22:33 UTC 2021


On Wed, 19 May 2021 09:25:07 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Hi Vladimir,
>> 
>> Thanks for your comment.
>> 
>> Yes, the native implementation for `getClassIdNonIntrinsic`/`getClassId` is located in `jfrTraceId.cpp#L178` just as you said, more specifically, there are two path, one(JfrTraceId::load) for normal class and one(load_primitive) for primitive class (includeing void.class).
>> 
>> My pseudo-code(the comment of `LibraryCallKit::inline_native_classID`) is consistent with the implementation of these two paths.
>> 
>> And in the normal class implementation path, there are fast path and slow path(see JfrTraceIdLoadBarrier::load), only some comparison and shift operations are needed to obtain the class ID in the fast path, and that's where I think intrinsic can bring performance improvements, I saw about 20x improvement from my microbenchmark.
>> 
>> Judging from the current JFR implementation, there are already some events that need to rely on this API, such as `ExceptionThrownEvent` and `ErrorThrownEvent` use `thrownClass` to record the type of exception, and I also noticed that there is a new PR(https://github.com/openjdk/jdk/pull/4101) to add `FinalizerEvent` which include a field named `finalizedClass` to record the type information. Therefore, I have reason to believe that this API will be frequently used during the JFR activation process.
>> 
>> As far as the current implementation is concerned, it is indeed a bit complicated, I think some simplifications can be made, for example, only the fast path for the normal class is retained, and other paths are directly implemented by calling the native function. What do you think?
>> 
>> @egahlin @mgronlun
>> And I hope JFR's folks could give some suggestions on this PR:)  
>> 
>> Best,
>> Denghui
>
> Hi @D-D-H, sorry for the late reply.
> 
> I am currently a bit busy but hope to get around taking a look at this soon.
> 
> Thanks
> Markus

Hi @mgronlun @vnkozlov ,

Thank you very much for your comment, I have updated my patch, please help to review it again when you have time.

Best,
Denghui Dong

-------------

PR: https://git.openjdk.java.net/jdk/pull/3470


More information about the hotspot-compiler-dev mailing list