Question about hack in templateTable_x86.cpp
john.r.rose at oracle.com
Fri Nov 6 01:40:53 UTC 2020
On Nov 5, 2020, at 5:34 PM, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
> On 11/5/20 3:09 PM, John Rose wrote:
>> On Nov 5, 2020, at 10:09 AM, Sergey Kuksenko <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>>> // might be substitutable, test if either rax or rdx is null __ testptr(rdx, rax);
>>> __ jcc(Assembler::zero, (cc ==equal) ? not_taken : taken);
>>> The last "test" does simultaneous check either one of oops is null. I really like that hack, but I am not sure.
>>> What if we've got two non-null pointers which just have different bits? That hack may work only if we know that ANY two pointers have some ones at the same bit position. Do we have such assurance?
>> Not in general. If you look at verify_oop_mask and verify_oop_bits,
>> you might be able to reassure yourself that this works out OK.
>> In particular, we need both values to be non-zero.
>> The macro here should do this, and fall back to reliable code (such
>> as a CC-testing bitwise OR) if the reassurance fails, or at least fail
>> to boot the JVM.
>> See Universe::calculate_verify_data for where these bits come from.
> I don't want to be boring, just want to understand it for myself.
> "calculate_verify_data" finds high bits common prefix for min/max heap addresses. What if that high common prefix is all zeros or even zero length?
> For example, in ZGC we use:
> Universe::calculate_verify_data((HeapWord*)0, (HeapWord*)UINTPTR_MAX);
> In that case prefix mask/bits will be zeros.
Yes, that’s why I said “we need both values to be non-zero”.
So, the code you found is buggy but just happens to work
out sometimes. It should be changed. It clearly wasn’t
written with calculate_verify_data in mind; that’s just
something that I was reminded of when you wrote your
More information about the valhalla-dev