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

[Kim Barrett]

> On Jan 31, 2020, at 2:35 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> 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.

Here's a new webrev:

https://cr.openjdk.java.net/~kbarrett/8238272/open.01/

I didn't bother with an incremental webrev, since the new version is just
a one-line change replacing the previous one-line change.

Testing: tier1