RFR[XS]: 8238272: Eliminate cast_from_oop to narrowOop*

Kim Barrett kim.barrett at oracle.com
Fri Jan 31 07:35:45 UTC 2020


> On Jan 31, 2020, at 2:07 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 1/31/20 7:51 AM, Kim Barrett wrote:
>> Webrev:
>> https://cr.openjdk.java.net/~kbarrett/8238272/open.00/
> 
> Hm, I am puzzled a bit.
> 
> a->obj_at_addr_raw(0) seems to point to the first array element (objArrayOopDesc::base_raw + 0 =
> arrayOopDesc::base_raw(T_OBJECT) = cast_from_oop<intptr_t>(as_oop()) + base_offset_in_bytes(type) =
> header_size(type) * HeapWordSize). Whereas cast_from_oop<T*>(a) points to the object header.
> 
> So start == 0 is really a special case here, do we know why?

I realized there’s a problem shortly after sending out the RFR, and was starting to write
this when I saw your reply.

I should have realized this after looking at the end computation in the line after the change.
obj_at_addr_raw asserts the index is in range, which is exclusive on the length.  That’s
why the end computation hand-inlines the same address calculation as done by
obj_at_addr_raw, rather than using that function.  With my change we’ll get an assert
if the array length is also 0, even if start is also 0.

The fix is to use the same hand-inlined address calculation for start as for end, perhaps
packaging that up in a new function.  I’ll get back to this next week.  Sorry for the noise.




More information about the hotspot-dev mailing list