[patterns-instanceof-primitive] RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch [v2]

[Aggelos Biboudis]

On Fri, 10 Mar 2023 00:01:28 GMT, Michael Hixson <duke at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update int_float, long_float, long_double
>>   
>>   Co-authored-by: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
>>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>
> src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 178:
> 
>> 176:                 (64 - (Long.numberOfLeadingZeros(n) +
>> 177:                         Long.numberOfTrailingZeros(n))) ;
>> 178:     }
> 
> Are you interested in optimizing the performance of these methods at this time?
> 
> For example, in this method:
> * You can remove the `Long.MIN_VALUE` check.  That value "accidentally" works out with the rest of the logic; it has no leading zeros and 63 trailing zeros.  This optimization assumes that `Long.MIN_VALUE` isn't common enough to deserve its own fast path (at the expense of every other input), which seems true.
> * If you assume that most inputs to this method are "small" integers that do fit in doubles (which I think is true), you can optimize for them by checking trailing zeros lazily.
>   ```java
>   n = Math.abs(n);
>   int z = Long.numberOfLeadingZeros(n);
>   return z > 10 || z + Long.numberOfTrailingZeros(n) > 10;
>   ```
> 
> I can share benchmarks if that's useful.  (I needed this method years ago, and I wrote benchmarks back then.)
> 
> I'm assuming these methods are invoked whenever an expression like `longValue instanceof double` is evaluated, and that these methods aren't intrinsified (yet), so they seem worth optimizing.  But I could be mistaken.

Thanks for leaving a comment @michaelhixson. The final implementation could contain more compact versions like `n == (long)(double)n && n != Long.MAX_VALUE;`. This prototype on the amber repo is to assess correctness for now. But indeed we can proceed by putting the less readable but more performant versions we have for some methods (@rgiulietti). You are right, these methods are not intrinsified.

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

PR: https://git.openjdk.org/amber/pull/91