optimizing acmp in L-World

[David Simms]

Just a note that the "Universe::oop_metadata_odd_mask()" is the "encoded 
klass ptr form", therefore dependent on "UseCompressedClassPointers" 
feature, which when enabled I assume there is no space within the 
compressed ptr space (I could be wrong that). That is:

     "assert(Universe::oop_metadata_odd_mask() == 1, "should be");" ? 
"should be" == "if (UseCompressedClassPointers)"

/D


On 8/02/2018 8:03 a.m., John Rose wrote:
> On Feb 7, 2018, at 5:27 PM, Tobias Hartmann <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>> Knowing that ObjectAlignmentInBytes is guaranteed to be >= 2, we can do even better:
>>
>>   __ testptr(rdx, rdx);
>>   __ jcc(Assembler::zero, is_null);
>>   __ movl(rbx, Address(rdx, oopDesc::klass_offset_in_bytes()));
>>   __ andptr(rbx, Universe::oop_metadata_odd_mask());
>>   __ orptr(rdx, rbx);
> Yep.  And if metadata_odd_mask is some higher number like
> 0x10 or 0x20 (which I think it should be, in the long run*) then you
> just need to add a right-shift to pull it down into to the mask 0x07.
>
> In future systems if we use a color bit to mark the buffer pointer
> of the value type, we can just clear that single bit, in one of the
> operands, to force x != x.
>
> — John
>
> * P.S. So metadata_odd_mask is 0x01.  I missed that detail the
> first time around.  If we align klass metadata pointers a little
> more strongly we can make it a larger number like 0x10 or 0x20,
> with the effect that we don't need an extra instruction to remove
> that bit when using the klass pointer.  We could just align value
> and object klasses a little differently, by allocating them (say)
> even mod 0x20 and then (say) bump each value klass upward
> by 0x10.  The fragmentation overhead would be small relative
> to the (probable) speed improvement of omitting the detag
> operation.
>