RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()

Roman Kennke rkennke at redhat.com
Tue Nov 6 15:48:44 UTC 2018


> Except it's not that easy. Also, with Shenandoah there is a new wrinkle.
> It is possible for an object to be allocated at the first non-guarded
> address in the heap area i.e. heap_base + os::vm_page_size. I that case
> a dereference of its Brooks pointer will lie in the protected page.

No, that is not possible. We always allocate the first object at
heap_start + 8, and place the first fwdptr at heap_start. Doing what you
described would be a gross error, if I understood you correctly.

Roman

> 
>> Thoughts?
> 
> I am agnostic as to whether this is done using one or two functions.
> However, besides the above issue I believe there is a small error in
> your rewrite of os_linux_aarch64.cpp. At line 259 you correct si_addr to
> or back in the top byte if bit 55 is non-zero.
> 
> 359     address addr = (address) info->si_addr;
> 360
> 361     // Make sure the high order byte is sign extended, as it may be
> masked away by the hardware.
> 362     if ((uintptr_t(addr) & (uintptr_t(1) << 55)) != 0) {
> 363       addr = address(uintptr_t(addr) | (uintptr_t(0xFF) << 56));
> 364     }
> 365
> 
> However, at line 463 you fail to pass the corrected address to
> uses_implicit_null_check
> 
> 462       } else if (sig == SIGSEGV &&
> 463
> MacroAssembler::uses_implicit_null_check(info->si_addr)) {
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181106/6ead6869/signature.asc>


More information about the hotspot-gc-dev mailing list