implicit null checks with compressed oops may cause crash

Roland Westrelin rwestrel at redhat.com
Fri Oct 7 10:02:26 UTC 2016


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-nullcheck/webrev.01/

The fix that I sent previously:

http://cr.openjdk.java.net/~roland/shenandoah/compressedoops-nullcheck/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