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

Zoltán Majó 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.

Best regards,

Zoltan

— John

More information about the hotspot-dev mailing list