JDK-8324296 : Reconsider the need for math StubRoutines after fdlibm ports
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-01-22
  • Updated: 2024-01-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Description
A few places in Hotspot call to StubRoutines for math functions, see e.g. `LibraryCallKit::inline_math_native`:

```
bool LibraryCallKit::inline_math_native(vmIntrinsics::ID id) {
  switch (id) {
  case vmIntrinsics::_dsin:
    return StubRoutines::dsin() != nullptr ?
      runtime_math(OptoRuntime::Math_D_D_Type(), StubRoutines::dsin(), "dsin") :
      runtime_math(OptoRuntime::Math_D_D_Type(), CAST_FROM_FN_PTR(address, SharedRuntime::dsin),   "SIN");
```

This might have been driven by the desire to avoid the expensive native calls to fdlibm. After fdlibm ports to Java (JDK-8134780, JDK-8171407), this might be unnecessary, and we could just stay in Java for these computations. This would likely eliminate the need for lots of platform-specific assembler coding for these math methods.
Comments
I benchmarked intrinsics vs. pure java in https://github.com/openjdk/jdk/pull/13606 (already includes some discussion on removing intrinsics) in May 2023 Intrinsics gave between 5%-40% speedup. Perhaps we should re-run that benchmark and analyze the results further.. I guess 5% would not justify the maintenance overhead of intrinsics. But 40%?
22-01-2024