On Mon, 27 Jul 2026 19:51:25 GMT, Vladimir Ivanov <[email protected]> wrote:

>>> We could keep the originally designed permissiveness by adding a Java 
>>> wrapper that handles the any corner cases refused by the intrinsic. That’s 
>>> where hacks like unsafe unaligned loads and masking would go, in the 
>>> wrapper. And the wrapper would do ALL the work, if the intrinsic is 
>>> disabled for some reason – it can return ~N, saying "please do it all, 
>>> Java". That should go in one place. Do we find ourselves replicating such 
>>> defensive logic today?
>> 
>> The answer is 'yes'. The defensive logic is replicated several times.
>> 
>> I'm not suggesting that we change the contract of the intrinsic stub. I 
>> totally agree that work that can be done effectively in Java should be done 
>> in Java, not in assembly. But, right now it seems that the contract of the 
>> intrinsic stub is exposed _directly_ to clients, which then have to 
>> replicate the fixup logic in case the intrinsic returns ~N.
>> 
>> The point I'm trying to make (and Chen as well I think), is that we should 
>> do the additional fixup in the Java code immediately enclosing the intrinsic 
>> stub, instead of 'exporting' that as an internal API.
>
>> The point I'm trying to make (and Chen as well I think), is that we should 
>> do the additional fixup in the Java code immediately enclosing the intrinsic 
>> stub, instead of 'exporting' that as an internal API.
> 
> Intrinsic guidelines recommend shaping intrinsic-related code into safe and 
> unsafe tightly coupled counterparts where unsafe part is well-known to the 
> JVM while "safe" wrappers perform necessary pre-/post-processing and are used 
> outside. The wrapper is the best place for fixup logic.
> 
> I'm perfectly fine to turn `ArraysSupport.vectorizedMismatch` into a wrapper 
> (around a private intrinsified method) which is forbidden to return anything 
> besides "> -1" values.

@iwanowww Could you review it again? thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-5246980480

Reply via email to