> On Jun 29, 2015, at 10:47 PM, John Rose <john.r.r...@oracle.com> wrote: > > On Jun 29, 2015, at 10:48 AM, Doug Simon <doug.si...@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
