Add jit compile helper time to detect @ForceInline annotation

[tajila]

The @ForceInline (jdk.internal.vm.annotation.ForceInline) will be used to notify the JIT that the method will benefit from inlining.

We will introduce a compile time jithelper to so the JIT can query if the method is annotated with @ForceInline or not.

First we will add a VMHelper

//@param clazz, the class that own the field
//@param the cpindex of the method to query
//@return true, if forceinline, false otherwise
BOOLEAN
isMethodTaggedForForceInline(J9Class clazz, UDATA cpIndex);

Take a look at dumpAnnotationInfo in rcdump.c to see how to look up method annotations.
To find the name of the field given a cpIndex romFieldRef = (J9ROMMethodRef *)&clazz->ramConstantPool->romConstantPool[cpIndex];

Compile time helpers are stored in cthelpers.cpp

[tajila]

@gita-omr ^^

[sharon-wang]

I'll take a dive into this

[fjeremic]

See related #2076 which talks about @HotSpotIntrinsicCandidate. I would love to see this made available as well (perhaps @OpenJ9IntrinsicCandidate?). Also may I suggest a slight change to the name:

isMethodTagged **With** ForceInline

[fjeremic]

Also unfortunate for @forceinline 😅
I wonder how often he gets accidentally tagged in issues.

[r30shah]

See related #2076 which talks about @HotSpotIntrinsicCandidate. I would love to see this made available as well (perhaps @OpenJ9IntrinsicCandidate?). Also may I suggest a slight change to the name:

I am experimenting with certain methods which are tagged with @IntrinsicCandidate and was adding those to list of methods calls for which I can skip HCR guards in the compiled code. It would be nice if we have jit compiler helper that can process such tags as well. I would make JIT compiler code cleaner.

[gita-omr]

@tajila could we resume the discussion on what exactly is needed to implement this?

[tajila]

We would need to know the defining class and the method name (or moethodref). Essentially, we need to know which implementation the JIT is referring to.

The challenge is that in polymorhpic callsites there is no way to determine this statically.

[gita-omr]

Right. I was thinking that sometimes we try to de-virtualize a call but not necessarily inline it. At this point, we could check the annotation. Then, we could provide the exact class of the object on which we are invoking the method(might not be the one that have the method implementation though, but some of its parents would).

[tajila]

We can provide something like this:

BOOLEAN
jitIsMethodForceInline(J9Class *definingClass, J9ROMNameAndSignature *nameAndSig)

This means if you dont call this on the defining class you may get FALSE.

[gita-omr]

Not sure we can find the defining class... I think it might be derived class that uses definition of some parent class...

[gita-omr]

@tajila Please see my previous comment

[tajila]

for @forceinline we know that the annotation is always going to be on a final or static method. This means that if you devirtualize a callsite you can always know query the correct method. If pass the VM the implemenation method then we will always be able to respond with the correct answer.

[mzdw89]

Also unfortunate for @forceinline 😅
I wonder how often he gets accidentally tagged in issues.

too often 😔

[tajila]

sorry about that

[gita-omr]

or @forceinline we know that the annotation is always going to be on a final or static method. This means that if you devirtualize a callsite you can always know query the correct method. If pass the VM the implemenation method then we will always be able to respond with the correct answe

Ok, will need to double check, but let's assume that for now.