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