JDK-8073358 : memory fences for fields are present in code even though object has been lifted into registers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • CPU: aarch64
  • Submitted: 2015-02-17
  • Updated: 2022-02-08
  • Resolved: 2022-02-08
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
tbdResolved
Related Reports
Relates :  
JDK-6672848 - Escape Analysis: improve lock elimination with EA
Description
Some memory fences (MemBar nodes) are apparently left behind after a non-escaping object is scalarized.  The report is here (look for "close but not cigar"):

http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017194.html

Perhaps the memory barriers inserted into constructor calls by Parse::do_exits should be gated on whether the object has escaped or not.
Comments
I close this as not an issue. feel free to reopen it.
08-02-2022
hi, [~aph], do you mind reviewing the program I uploaded? Does it reflect your testcase?
02-02-2022
../build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xbatch -XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations -XX:+PrintCompilation Main it generates 2 MemBarRelease nodes in Main::main(OSR). 1. 628 MemBarRelease === 208 1 258 1 1 211 [[ 629 630 ]] !jvms: ByteBuffer::<init> @ bci:-1 (line 288) HeapByteBuffer::<init> @ bci:12 (line 78) ByteBuffer::wrap @ bci:8 (line 408) ByteBuffer::wrap @ bci:4 (line 437) Main::ge tLong @ bci:1 (line 5) Main::main @ bci:61 (line 22 2. 822 MemBarRelease === 808 1 249 1 1 211 [[ 823 824 ]] !jvms: HeapByteBuffer::<init> @ bci:-1 (line 78) ByteBuffer::wrap @ bci:8 (line 408) ByteBuffer::wrap @ bci:4 (line 437) Main::getLong @ bci:1 (line 5) Main::main @ bci :61 (line 22) Both of them has the same precedent 211, which is the result of the eliminated allocation node. They are both eliminated by the GVN after EA. Scalar 211 CheckCastPP === 208 206 [[ 946 946 725 827 827 ]] #java/nio/HeapByteBuffer:NotNull:exact *,iid=194 Oop:java/nio/HeapByteBuffer:NotNull:exact *,iid=194 !jvms: ByteBuffer::wrap @ bci:0 (line 408) ByteBuffer::wrap @ bci:4 (line 437) Main::getLong @ bci:1 (line 5) Main::main @ bci:61 (line 22) ++++ Eliminated: 194 Allocate
02-02-2022
it's worth mentioning that MemBarRelease is null on x86_64 whereas it's 'dmd ish' on aarch64. As @kvn said, the removing of MemBarRelease is architectural independent. I try to reproduce the testcase using Main.java(as attached), I found that 2 MemBarRelease nodes are generated and both of them are optimized out because of Scalar Replacement.
02-02-2022
There is code in MemBarNode::Ideal() which eliminates membars for scalarized object. There may be some exceptions but it general it should work. If it does not - it is bug.
17-02-2015