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
>
More information about the hotspot-dev
mailing list