-
Bug
-
Resolution: Fixed
-
P4
-
13
-
b15
After a JavaThread have been in a safepoint/(handshake) safe state it can start executing updated code.
E.g. an oop in the instruction stream can have been updated.
Most hardware's require a barrier or that the code cross modified is far away to guarantee that the thread executing the update instruction stream sees the modification.
What far away is and how far an update instruction stream is from a safepoint safe state is not clear.
To be compliant with those architectures an instruction stream barrier must be added when leaving the safepoint safe state.
In this issue we added the basic blocks and follow the x86 recommendations:
AMD64 Architecture Programmer's Manual Volume 2: System Programming, section 7.6.1
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, section 8.1.3
E.g. an oop in the instruction stream can have been updated.
Most hardware's require a barrier or that the code cross modified is far away to guarantee that the thread executing the update instruction stream sees the modification.
What far away is and how far an update instruction stream is from a safepoint safe state is not clear.
To be compliant with those architectures an instruction stream barrier must be added when leaving the safepoint safe state.
In this issue we added the basic blocks and follow the x86 recommendations:
AMD64 Architecture Programmer's Manual Volume 2: System Programming, section 7.6.1
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, section 8.1.3
- relates to
-
JDK-8226525 HotSpot compile-time error for x86-32
- Resolved
-
JDK-8213961 RIP values like 0xffffffff94bf7f80 due to patched NMethod
- Closed
-
JDK-8221555 SPARC cross-modifying code
- Open
-
JDK-8221556 arm32 cross-modifying code
- Open
-
JDK-8221554 aarch64 cross-modifying code
- Resolved
-
JDK-8254264 Remove redundant cross_modify_fence()
- Resolved
(1 relates to)