We have reduced the unnecessary alignment "cushions" for metaspace, so we are now sometimes using the very last bit of a VirtualSpace (in Metaspace).
This will cause a long bug tail, starting withJDK-8027252 and including many more at lower and lower frequencies. There is a recurring chance that compilers (or hand-written assembly code or other generated code) will prefetch, either intentionally or unintentionally, near active metadata structures and accidentally cross a page (and cache line) boundary into unallocated memory.
So it's usually a mistake to use every last byte up to the end of a memory region, unless you are looking for trouble (electric fence, etc.).
As systems make more use of wider registers the amount of prefetch may grow up to about 512 bits. The natural limit to that trend is a cache line.
Please put *back* a cache line or two worth of explicit padding at the end of every region that precedes unmapped memory. Include a comment saying "don't try to optimize this". Please do this for as many regions as possible that the JVM manages (native memory, metadata, managed heap).
The footprint overhead will be negligible, since memory regions are on the megabyte to gigabyte scale. The time freed up from kitchen-sink bugs can be used more profitably on other matters.
Ref: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011416.html
I=H (VM crash)
L=L (unlikely situation)
W=H (no known workaround)
=>P2
This will cause a long bug tail, starting with
So it's usually a mistake to use every last byte up to the end of a memory region, unless you are looking for trouble (electric fence, etc.).
As systems make more use of wider registers the amount of prefetch may grow up to about 512 bits. The natural limit to that trend is a cache line.
Please put *back* a cache line or two worth of explicit padding at the end of every region that precedes unmapped memory. Include a comment saying "don't try to optimize this". Please do this for as many regions as possible that the JVM manages (native memory, metadata, managed heap).
The footprint overhead will be negligible, since memory regions are on the megabyte to gigabyte scale. The time freed up from kitchen-sink bugs can be used more profitably on other matters.
Ref: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011416.html
I=H (VM crash)
L=L (unlikely situation)
W=H (no known workaround)
=>P2
- relates to
-
JDK-8027252 Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes
-
- Closed
-