[PATCH] 8202414: Unsafe crash in C2

[dean.long at oracle.com]

Hi Andy.  Did you notice the difference between these two intrinsics:

   *case*  vmIntrinsics 
<https://java.se.oracle.com/source/s?defs=vmIntrinsics&project=jdk-jdk>::_putInt <https://java.se.oracle.com/source/s?defs=_putInt&project=jdk-jdk>:*return*  inline_unsafe_access 
<https://java.se.oracle.com/source/xref/jdk-jdk/open/src/hotspot/share/opto/library_call.cpp#inline_unsafe_access>(is_store <https://java.se.oracle.com/source/s?defs=is_store&project=jdk-jdk>,T_INT <https://java.se.oracle.com/source/s?defs=T_INT&project=jdk-jdk>,Relaxed 
<https://java.se.oracle.com/source/xref/jdk-jdk/open/src/hotspot/share/opto/library_call.cpp#Relaxed>,*false*);
[...]
   *case*  vmIntrinsics 
<https://java.se.oracle.com/source/s?defs=vmIntrinsics&project=jdk-jdk>::_putIntUnaligned 
<https://java.se.oracle.com/source/s?defs=_putIntUnaligned&project=jdk-jdk>:*return*  inline_unsafe_access 
<https://java.se.oracle.com/source/xref/jdk-jdk/open/src/hotspot/share/opto/library_call.cpp#inline_unsafe_access>(is_store <https://java.se.oracle.com/source/s?defs=is_store&project=jdk-jdk>,T_INT <https://java.se.oracle.com/source/s?defs=T_INT&project=jdk-jdk>,Relaxed 
<https://java.se.oracle.com/source/xref/jdk-jdk/open/src/hotspot/share/opto/library_call.cpp#Relaxed>,*true*);


The last argument (bool unaligned) for _putInt is saying that it does 
not support unaligned accesses.
Looking at jdk.internal.misc.Unsafe instead of sun.misc.Unsafe should 
make the difference clearer.

dl

On 9/10/18 5:36 PM, Andy Law wrote:
> Hi Lutz and Andrew,
>
> Thank you for your reply and sorry for my typos :)
>
> TL;DR
> I think it is the optimization of `clear_memory()`which cause this 
> problem, in my understanding it may not be a user fault :)
>
> When running the example on the bug list using 
> `-XX:DisableIntrinsic=_putInt`, or use interpreter/C1 only will make 
> this problem go away, due to the fact that program will go to another 
> branch.
>
> In function `clear_memory()`, it will make an optimization which will 
> clear the context of the memory, in fact
>
>     if (done_offset > start_offset) {  // [1]
>         // it will clear the memory from start_offset to done_offset
>     }
>
>     if (done_offset < end_offset) {  // [2]
>         // it will clear the memory by using a Int (0) to clear the 
> memory of done_offset
>     }
>
> |<--------------- 16-byte header —--——>| <—— 4-byte arr length (new 
> byte[397]) ———>
>           |       0000     0001     1000     1101     |
> If it is aligned, it won’t have any problem but, if it is not aligned 
> as the example, this optimization will mis-clear the `0000 0001` to 
> `0000 0000`, so the array length becomes 141. Then it will crash when 
> gc happens.
>
> It is the optimization which cause this problem, so when it is not 
> aligned, we don’t do this optimization for this unaligned address may 
> solve the problem.
> By the way I didn’t find the unaligned message on the doc:( but I 
> think you’re right and it should be aligned when using Unsafe, though 
> it is an deprecated API :) It won’t be reproduced using the 
> templateInterpreter or C1 compiler, due to the fact that they won’t do 
> this optimization.
>
> Thank you:),
> Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180910/73dfcc39/attachment.html>