Convert Float/Double to Long more accurately

[Blaisorblade]

Warning: don't merge yet.

Double.doubleToLongBits and Float.floatToIntBits are documented to not be fully invertible, because they take extra effort to collapse different NaN values together. Hence, it appears miniboxing could conceivably interfere with (admittedly strange) code that distinguishes different NaNs (say, code also casting across Long and Double, like in some JavaScript engines). Using the Raw variants prevents the issue (and has no overhead at all).

This is untested, done from the browser, and I'm guessing that the goal of this code is to "box" primitives as Long to pass them to the specialized-for-all-primitives version of the interface.

There are more uses of these primitives to review and probably fix. https://github.com/miniboxing/miniboxing-plugin/search?q=doubleToLongBits&type=Code&utf8=%E2%9C%93

[codecov-io]

Current coverage is 90.19%

Merging #220 into wip will change coverage by 0% by dd91fbe

Powered by Codecov

[VladUreche]

Thanks @Blaisorblade! It makes a lot of sense to update the conversions, as we want the fastest version possible. I will update the remaining ones in a later commit.

Still, the default miniboxing transformation now uses three classes per type parameter:

• one for Object, similar to the erased version
• one for integral types (Unit, Boolean ... Long) using long integers as storage
• one for floating-point types (Float and Double) using double-precision fp numbers as storage

This way we avoid jumping from integral to floating-point and back, which is costly (Rex benchmarked this and it's 4 times slower than a conversion from int to long or from float to double). Also, it seems to be handled differently by the JVM, causing some loop unswitching optimizations not to kick in.

[Blaisorblade]

Thanks @VladUreche! I was indeed looking at your miniboxing for guidance on casting on the JVM ;-), so good to know!

[VladUreche]

Well, you have to thank @ichoran for that benchmark!