[9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics
Zoltán Majó
zoltan.majo at oracle.com
Mon Jun 29 10:41:12 UTC 2015
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.
More information about the security-dev
mailing list