Question about hack in templateTable_x86.cpp

Sergey Kuksenko 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:

Universe::calculate_verify_data((HeapWord*)0, (HeapWord*)UINTPTR_MAX);

In that case prefix mask/bits will be zeros.





More information about the valhalla-dev mailing list