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

[Vladimir Kozlov]

On Wed, 19 May 2021 03:07:36 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix crash problem
>
> 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,

Can you show pseudo code for your fast/slow path suggestion?
What is most frequent (performance critical) path is used?
If it simplify code I am for it.

I am not sure about implementing it in C1 since in default mode methods will be compiled by C2. So for C1 to call native implementation could be fine and we can remove code there. Or you can file followup RFE to fix it in C1 later.

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

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