RFR: 8178836: Improve PtrQueue index abstraction

[Kim Barrett]

> On May 5, 2017, at 7:49 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 2017-05-05 07:46, Kim Barrett wrote:
>> Still looking for a second review.
>> 
>>> On Apr 22, 2017, at 1:19 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> 
>>>> On Apr 21, 2017, at 7:00 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>> Minor nits:
>>>>> 
>>>>> *) On first scan, "limit" reads as the loop variable, because it is the only
>>>>> initialization in init block. Move it out?
>>>>> 
>>>>> 161   for (size_t limit = buffer_size(); i < limit; ++i) {
>>>> 
>>>> OK.
>>> 
>>> Updated webrev:
>>> full: http://cr.openjdk.java.net/~kbarrett/8178836/hotspot.01/
>>> incr: http://cr.openjdk.java.net/~kbarrett/8178836/hotspot.01.inc/
>> 
>> 
> 
> Good cleanup. A step in the right direction but I'm still confused by mixing of sizes and offsets in both bytes and elements.
> 
> Just to get this straight:
> PtrQueueSet::buffer_size used to return the byte size of buffers because PtrQueueSet::_sz was set to a byte size but now the byte sizes are more contained in PtrQueue?

The idea is that nearly everything now deals with sizes and offsets as
element indexes rather than byte offsets. The exception is that the
internal representation of _index and the buffer size (was _sz, now
_capacity_in_bytes) is in bytes.

The reason for _index being represented as a byte offset is so the
compiler can generate code using the _index that doesn't need to scale
it from an element index to a byte offset. (The compiler obtains
access to the _index via byte_offset_to_index.)  Whether that matters
is platform-dependent, but using byte offsets always seems preferable
to making the representation depend on the platform.

Even internally to PtrQueue we now mostly index() and capacity() to
get values in elements.

> Consider this Reviewed.

Thanks.

> /Mikael