implicit null checks with compressed oops may cause crash
Roman Kennke
rkennke at redhat.com
Fri Oct 7 10:05:17 UTC 2016
Ok.
Roman
Am Freitag, den 07.10.2016, 12:02 +0200 schrieb Roland Westrelin:
> It's the issue with null checks that Zhengyu encountered. Here is a
> new
> webrev with a test case:
>
> http://cr.openjdk.java.net/~roland/shenandoah/compressedoops-nullchec
> k/webrev.01/
>
> The fix that I sent previously:
>
> http://cr.openjdk.java.net/~roland/shenandoah/compressedoops-nullchec
> k/webrev.00/
>
> wasn't correct.
>
> With compressed oops enabled there are 2 code shapes for a read
> barrier:
>
> mov -0x8(%rsi),%r10
>
> or
>
> mov -0x8(%r12,%r11,8),%r10
>
> When an implicit null checks fires at a barrier, the offset observed
> by
> the signal handler can then be -8 or base - 8. The
>
> if ((uintptr_t)offset >= base) {
>
> check in MacroAssembler::needs_explicit_null_check() is broken for 2
> reasons:
>
> - cast of offset to unsigned causes the test to always success if
> offset is -8
>
> - if offset is base - 8, the test never succeeds.
>
> In both case, the implicit null check is not recognized and the VM
> crashes.
>
> Roland.
>
More information about the shenandoah-dev
mailing list