Question about hack in templateTable_x86.cpp
sergey.kuksenko at oracle.com
Fri Nov 6 01:34:45 UTC 2020
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:
In that case prefix mask/bits will be zeros.
More information about the valhalla-dev