JDK-8224182 : [Performance] sun.misc.Unsafe.[put|get]* suffer from redundant memory barriers
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2019-05-18
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
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.
JDK 13
13Resolved
Related Reports
Duplicate :  
JDK-8226396 - C2: Redundant address computations for array accesses
Duplicate :  
JDK-8226411 - C2: Avoid memory barriers around off-heap unsafe accesses
Duplicate :  
JDK-8226409 - Enable argument profiling for sun.misc.Unsafe.put*/get*
Relates :  
JDK-8226396 - C2: Redundant address computations for array accesses
Relates :  
JDK-8181211 - C2: Use profiling data to optimize on/off heap unsafe accesses
Relates :  
JDK-8176506 - C2: loop unswitching and unsafe accesses cause crash
Description
A DESCRIPTION OF THE PROBLEM :
jdk.internal.misc.Unsafe implements methods to read/write native memory in following fashion:
@ForceInline
public byte getByte(long address) {
     return getByte(null, address);
}
As can be seen, a null value is passed on the stack without a reason.
To resolve this, the method should be defined as:
@HotSpotIntrinsicCandidate
 public native byte getByte(long offset);

The reason to resolve this is because the current implementation is slower than the older one in eg. Java 8.
Comments
Filed JDK-8226409 (#a), JDK-8226411 (#b), and JDK-8226396 (testArray) to track independent aspects fo the fix.
19-06-2019
With (a) and (b) fixed, I see the following numbers: TestArrayPerf 8u201 12+33 jdk/jdk fixed testArray 87.304 ±2.496 77.202 ±2.807 76.957 ±2.826 ops/s testDirect 88.910 ±3.677 32.485 ±3.296 93.144 ±2.087 ops/s testHeap 89.888 ±3.691 32.863 ±2.705 91.493 ±2.258 ops/s testHeapAndDirect 88.731 ±4.980 33.341 ±0.850 90.535 ±3.710 ops/s testMixed 44.703 ±1.118 16.446 ±0.920 15.209 ±0.498 ops/s (testMixed is a new benchmark to test polluted profile case.) (Also, there's a ~10-15% regression on testArray I don't have an explanation for right now.)
17-06-2019
Bug description is misleading: there are no issues with new shape of absolute (off-heap) unsafe accesses.
17-06-2019
The benchmarks suffer from memory barriers around unsafe accesses. I see 3 cases: (a) base address profiling (JDK-8181211) covers only jdk.internal.misc.Unsafe, but not sun.misc.Unsafe; so, benchmark hits the case of polluted profile (b) off-heap accesses (base == NULL) have membars around them (c) mixed accesses have membars around them While (a) and (b) can (and should) be fixed, barriers around mixed accesses are required for correctness.
17-06-2019
Thanks Vladimir...
14-06-2019
Provided test case has dependencies with "org.openjdk.jmh" and sub classes. I tried to compile with different versions of jmh-core-xxx.jar but could not succeed. Requested submitter for exact version of jmh-core jar file
14-06-2019
I'm able to reproduce the issue.
14-06-2019
Test case attached...
30-05-2019
Additional information from submitter == Additional Information: Thank you for the information, I am providing additional information, including test case and results. According to the following test results, Java 8 performs the following test case 2x faster then Java 11,12,13. I haven't tested version 9,10. # VM version: JDK 1.8.0_191, OpenJDK 64-Bit Server VM, 25.191-b12 Benchmark Mode Cnt Score Error Units TestArrayPerf.testArray ss 100 25.393 ± 0.343 ms/op TestArrayPerf.testDirect ss 100 26.697 ± 0.554 ms/op TestArrayPerf.testHeap ss 100 25.404 ± 0.319 ms/op TestArrayPerf.testHeapAndDirect ss 100 26.007 ± 0.359 ms/op # VM version: JDK 11.0.1, OpenJDK 64-Bit Server VM, 11.0.1+13 TestArrayPerf.testArray ss 100 26.738 ± 0.348 ms/op TestArrayPerf.testDirect ss 100 46.041 ± 0.436 ms/op TestArrayPerf.testHeap ss 100 46.384 ± 0.438 ms/op TestArrayPerf.testHeapAndDirect ss 100 45.472 ± 0.472 ms/op # VM version: JDK 12.0.1, OpenJDK 64-Bit Server VM, 12.0.1+12 TestArrayPerf.testArray ss 100 26.832 ± 0.375 ms/op TestArrayPerf.testDirect ss 100 46.891 ± 0.551 ms/op TestArrayPerf.testHeap ss 100 47.552 ± 0.630 ms/op TestArrayPerf.testHeapAndDirect ss 100 45.513 ± 0.435 ms/op # VM version: JDK 13-ea, OpenJDK 64-Bit Server VM, 13-ea+22 Benchmark Mode Cnt Score Error Units TestArrayPerf.testArray ss 100 27.686 ± 0.345 ms/op TestArrayPerf.testDirect ss 100 45.698 ± 0.512 ms/op TestArrayPerf.testHeap ss 100 46.809 ± 0.765 ms/op TestArrayPerf.testHeapAndDirect ss 100 47.214 ± 0.499 ms/op ==
30-05-2019
Since all these methods are inlined when compiled by the JIT, there is no "stack" on which a null is put and the additional null argument does not affect performance. If there still is a performance difference to Java 8, it's for a different reason and we would need a reproducer to investigate. Closing this as Incomplete. Please re-open once there is additional information from the reporter available.
20-05-2019