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

[Zoltán Majó]

On 06/29/2015 10:47 PM, John Rose wrote:
> On Jun 29, 2015, at 10:48 AM, Doug Simon <doug.simon at oracle.com 
> <mailto: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.
>
>> 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.

Thank you, Doug, for bringing up these issues.
Thank you, John, for the clarifications.

Best regards,


Zoltan

>
> — John