RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics
zoltan.majo at oracle.com
Tue Jun 30 08:24:34 UTC 2015
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.
> — John
More information about the jdk9-dev