[PATCH] 8202414: Unsafe crash in C2

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Sep 10 19:34:55 UTC 2018


Thank you, Andy

Unfortunately your change may leave uninitialized (not zeroed) bytes in object.
Instead unaligned stores should be treated as subword stores:

diff -r b9f6a4427da9 src/hotspot/share/opto/memnode.cpp
--- a/src/hotspot/share/opto/memnode.cpp
+++ b/src/hotspot/share/opto/memnode.cpp
@@ -4095,10 +4095,11 @@
        // See if this store needs a zero before it or under it.
        intptr_t zeroes_needed = st_off;

-      if (st_size < BytesPerInt) {
+      if (st_size < BytesPerInt || (zeroes_needed % BytesPerInt) != 0) {
          // Look for subword stores which only partially initialize words.
          // If we find some, we must lay down some word-level zeroes first,
          // underneath the subword stores.
+        // Do the same for unaligned stores.
          //
          // Examples:
          //   byte[] a = { p,q,r,s }  =>  a[0]=p,a[1]=q,a[2]=r,a[3]=s

Rahul, the bug is assigned to you. Please, test this solution.

Thanks,
Vladimir

On 9/10/18 4:10 AM, Andy Law wrote:
> This change is only about:
> Disabling the un-aligned C2 `clean_memory()` optimization when using Unsafe to write to an unaligned address.
> 
> ```
> java -version
> openjdk version "1.8.0-internal-debug"
> OpenJDK Runtime Environment (build 1.8.0-internal-debug-***_2018_09_03_19_31-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode)
> ```
> 
> This issue 8202414 is about:
> ArrayObjects of -XX:+UseCompressedOops on 64-bit has a 12 bits header and a 4 bits length. So the length address is from 12th to 16th bytes.
> If we use Unsafe.putInt() to write at the 17th bit, the C2 `clean_memory()` will mistakenly do `done_offset -= BytesPerInt;`, then `done_offset` will become 13.  And then it will clear the address from the 13th bit, make the array length changes to a different value. When a GC happens, it will crash.
> 
> I didn’t find the unaligned memory support of `clear_memory()`, so I only do a small fix to make the affect be the least:
> When Unsafe.put*() writes to an aligned memory as above, it will cause the assert fail. So when it fails, we don’t do any optimizations instead, and the problem solves.
> 
> I don’t know if it is a good solution? It is only 3 lines of code, so please have a look:) Thank you!
> 
> 
> Andy
> 


More information about the hotspot-compiler-dev mailing list