[9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics

[Zoltán Majó]

Hi,


On 06/29/2015 11:45 AM, Andrew Haley wrote:
> Hi,
>
> On 29/06/15 10:41, Zoltán Majó wrote:
>> On 06/27/2015 10:05 AM, Andrew Haley wrote:
>>> On 25/06/15 12:49, Zoltán Majó wrote:
>>>> Problem: There is need to indicate Java methods that are potentially
>>>> intrinsified by JVM.
>>> It's a great idea but is it a good name?  HotSpot is not the only Java
>>> VM.  Do we expect people from to come along and add
>>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on?
>> thank you bringing up this issue.
>>
>> The name HotSpotIntrinsicCandidate resulted from a private discussion
>> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was
>> picked is to make clear that a marked method's interaction with the VM
>> (specifically with the HotSpot VM implementation) needs special attention.
> OK, cool.  So has any thought been given to the other VMs?  Do you
> expect that, say, J9 will use the HotSpotIntrinsicCandidate
> annotattion, or do you expect we will have similar annotations for
> each VM which uses OpenJDK libraries?  Or is the need for this
> annotation totally HotSpot-specific?

the need for this annotation resulted from the way HotSpot handles 
intrinsics. Here are the two main reasons:

(1) Intrinsics in the HotSpot VM omit some checks (typically null checks 
and array bounds checks) that are instead performed in the JDK code. If 
HotSpot intrinsic code is changed, the matching JDK code must be changed 
as well (and vice versa). Otherwise we might run into correctness 
problems (e.g., the HotSpot intrinsic and the JDK method have different 
semantics) and/or performance problems (HotSpot suddenly not intrinsify 
a method because, e.g., the method's signature has changed and HotSpot's 
intrinsic list was not updated accordingly). Annotating intrinsified 
methods makes it less likely that a "mismatch" between a JDK method and 
its HotSpot-level intrinsic counterpart can be introduced.

(2) With the newly added CheckIntrinsic flag, HotSpot verifies if all 
annotated methods are backed by intrinsics at the VM level and that all 
intrinsics are marked appropriately in the JDK.

Other VM implementations will most likely intrinsify a different set of 
methods. So, if those methods were marked with the same annotation as 
HotSpot is looking for, it would be difficult for HotSpot to check the 
match between intrinsics and the JDK code they replace (Reason 2 from 
above). Also, if a JDK method is updated for which VM_A but not VM_B 
defines and intrinsic, only VM A's intrinsic code must be updated to 
match the JDK code, so it is maybe better to mark clearly which VM 
implementation intrinsifies an annotated method.

So, the current design would require introducing a similar annotation 
for every VM that decided to implement what we just proposed for HotSpot 
with the current changeset.

Thank you and best regards,


Zoltan


>
> Andrew.