RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics
doug.simon at oracle.com
Mon Jun 29 17:48:46 UTC 2015
> On Jun 29, 2015, at 3:01 PM, Andrew Haley <aph at redhat.com> wrote:
> On 06/29/2015 01:38 PM, Doug Simon wrote:
>> I seems just plain wrong for an intrinsic to not implement the same
>> semantics as the intrinsified method. I would expect an intrinsic to
>> perform all necessary runtime checks and only have the compiler omit
>> them if it can prove they are unnecessary. If all intrinsics obeyed
>> this contract, then there’s no need for the
>> @HotSpotIntrinsicCandidate annotation from a semantics
>> perspective. And in terms of the keeping HotSpot in sync with the
>> JDK, the responsibility should fall entirely on HotSpot to check
>> that its intrinsics correspond to existing methods.
> Don't you think you're being rather idealistic? The other side of the
> argument is that it's much easier to write and maintain the
> arg-checking code if it's written in Java, and it also has the
> advantage that it benefits from profile data to guide the JIT.
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?
I understand that writing the checking logic in Java is desirable. Indeed, it’s possible:
Adding these checks did not impact the score for the SPECjvm2008 crypto.aes benchmark on Graal. I’m not sure if this performance non-impact holds for all existing intrinsics but unless one can guarantee an intrinsified method will only be executed after the necessary checks have been performed, one is asking for trouble. Maybe hiding the intrinsifiable methods from reflection is sufficient?
More information about the hotspot-dev