port HotSpot assembler math stubs to Java

[dougxc]

The underlying problem in #296 is that there are bugs in the contributed assembler stubs for the Math exp, pow, sin, cos, tan and log methods. Since the contributor is no longer available to fix the problems and no one on the current team has sufficient knowledge of the assembler, we've disabled these stubs by default (0227108).

The plan is to port the HotSpot stubs added in JDK 9 (see the macroAssembler_x86_*.cpp files at http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/cpu/x86/vm) to Java. While this involves more work than simply using the HotSpot stubs for Graal, it has the benefit that SVM will also be able to use these stubs. We have to ensure that the translation to Java stays in sync with the HotSpot stubs to ensure monoticity (i.e. the interpreter, C1, C2 and Graal always produce the same results).

[theRealAph]

Wouldn't it be safer, not to say much easier, to call directly into the HotSpot stubs from Graal-generated code? Very little is gained from expanding these methods inline.

[dougxc]

That would work fine when running on HotSpot. However, when running on SVM, HotSpot stubs are not available.

[theRealAph]

Ewww, that's horrible. I guess that means we'll have to translate all of the stubs from HotSpot into Graal. It'd be nice to try to figure out how to do it better.

[dougxc]

Most stubs are specific to HotSpot internals so are not applicable to SVM. These arithmetic assembler stubs should be completely VM independent and so I'm hoping we can automate the translation to Java (maybe with the assistance of some stylistic changes to the HotSpot code). This would mean we can not only do an accurate initial port but also automatically detect and adopt subsequent fixes/changes to the HotSpot code. (/cc @mur47x111 @christianwimmer )

[theRealAph]

Mmm, okay. Even if most of the stubs are specific to HotSpot internals, there remain many which aren't. Some sort of common assembler form wouldn't be a bad idea. The AArch64 assembler format is very different between Graal and Hotspot (historical accident, not my fault.) I'll give it some thought.

[dougxc]

Maybe you could list some of the stubs that are VM agnostic so we can investigate whether there are already Graal stubs for the same functionality and if not, whether we should consider converting them in addition to the arithmetic stubs.

[iwanowww]

We have to ensure that the translation to Java stays in sync with the HotSpot stubs to ensure monoticity (i.e. the interpreter, C1, C2 and Graal always produce the same results).

From maintenance perspective, it would be really nice to get rid of those stubs in HotSpot as well and rely on Java implementations instead. They were implemented and contributed in assembly form because they originate from Intel C Compiler and Intel folks have enough resources only to port them to macroAssembler and not to rewrite them in Java.

So, I don't expect the stubs to change much (except bug fixes), but more likely be replaced with Java implementations at some point.

[theRealAph]

That's a nice thought, but we're going to have to do some pretty major improvements in code generation to get there. In particular, the use of vector addressing will have to be very carefully done. On the other hand, it'd be far more maintainable, that's for sure.

[dougxc]

@iwanowww , in terms of porting these to Java implementations (as opposed to just assembler expressed in Java), do you mean to extend/copy/modify something like FdLibm.java and ensure the compiler produces optimal code for it?

[christhalinger]

Just in case you guys don't know about this but Joe Darcy is working on porting all the fdlibm methods to Java for a while now:

https://bugs.openjdk.java.net/browse/JDK-8134780
https://bugs.openjdk.java.net/browse/JDK-8171407

Now make some compiler magic happen :-)

[dougxc]

@mur47x111 before porting the assembler stubs to Java, please investigate the code produced by Graal for FdLibm.java and try establish what it would take to make it match the manually written assembler.