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

[Doug Simon]

> On Jun 29, 2015, at 10:47 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Jun 29, 2015, at 10:48 AM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What’s to prevent a direct call to the latter via reflection that by-passes the first method?
> 
> The answer is simple:  We mark the dangerous method private.
> 
> I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways.  At that point having a surprising intrinsic is the least of our problems.

Ok, thanks for the clarification John. I’ll admit to occasionally forgetting that setAccessible is as unsafe as, well, Unsafe.

>> I understand that writing the checking logic in Java is desirable. 
> 
> Indeed, that is the key compromise here.  Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle.  You need Maxine/Graal snippets or real Java code to get it right.

Snippets certainly make it easier. I’m surprised though that existing C2 IR logic for expressing runtime checks cannot be easily leveraged for some intrinsics. My perspective may shift rapidly though were I tasked with doing it ;-)

-Doug