High cost of failed Math.*Exact calls

[Charles Oliver Nutter]

On Sat, Jan 11, 2025 at 12:09 AM John Rose <john.r.rose at oracle.com> wrote:

> https://bugs.openjdk.org/browse/JDK-8285871
> Math.multiplyHigh and multiply on same inputs can be computed faster if
> their computation is shared
>

I must admit it seemed odd to me that there was a `multiplyHigh` without a
corresponding `multiplyLow` but it makes sense there'd be a single CPU
instruction to do both.

>
> And FWIW, a lambda-based API could be made generic in the lambda result,
> so that the full BigInteger (or whatever) could be returned immediately:
> ...
> To work efficiently it also needs some sort of box suppression, either by
> reliable inlining and EA, or by handling Long as a value class.
>

At the very least the Long box needs to be supressed so that the 64-bit
safe path can be cheap. In the past, having a branch along the way defeated
HotSpot's EA. Are we likely to see the Long eliminated on today's JDKs?

Of course if we were able to get the lambda to inline as well, that would
be ideal, but I have no idea if any work is being done to profile methods
receiving lambdas (perhaps with a hidden marker interface or simply by
virtue of being single-method interfaces?) to split and inline multiple
paths. Perhaps you know of something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250114/ed7564a5/attachment.htm>