RFR: 8276215: Intrinsics matchers should handle native method flags better
Aleksey Shipilev
shade at openjdk.java.net
Tue Nov 9 13:38:34 UTC 2021
On Tue, 9 Nov 2021 12:13:46 GMT, David Holmes <dholmes at openjdk.org> wrote:
> I find it very hard to evaluate this without understanding why ?native was used in the first place. It seems to indicate "could be native, don't care either way" and now we want a firm is_native or is_not_native. The implications of this are unclear to me.
As far as I can see, this predates OpenJDK history. I suspect `?native` was a matter of "convenience".
But that convenience came with at least two problems: a) you would have to remember this is optional during the reviews, otherwise it leads to [questions](https://github.com/openjdk/jdk/pull/6149#discussion_r740005949); b) you would sometimes care whether the method is native or not, for example when cobbling together intrinsics against native and non-native methods, for example in [StrictMath](https://bugs.openjdk.java.net/browse/JDK-8276217).
Tracking the native-ness more strictly makes it safer too: if we ever change a intrinsified method native-ness, `CheckIntrinsics` would now barf, prompting us to re-evaluate the handling of those intrinsics in interpreter/C1/C2, looking whether such change would be safe. In other words, stronger enforcement of native-ness for intrinsics methods means safer coding.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6187
More information about the hotspot-runtime-dev
mailing list