On Sat, Jan 11, 2025 at 12:09 AM John Rose <john.r.r...@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?
