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