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

[Doug Simon]

> On Jun 29, 2015, at 12:41 PM, Zoltán Majó <zoltan.majo at oracle.com> wrote:
> 
> 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.

I seems just plain wrong for an intrinsic to not implement the same semantics as the intrinsified method. I would expect an intrinsic to perform all necessary runtime checks and only have the compiler omit them if it can prove they are unnecessary. If all intrinsics obeyed this contract, then there’s no need for the @HotSpotIntrinsicCandidate annotation from a semantics perspective. And in terms of the keeping HotSpot in sync with the JDK, the responsibility should fall entirely on HotSpot to check that its intrinsics correspond to existing methods.

> (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.

That is true which is a great reason to avoid an annotation altogether if possible.

-Doug