Summary

This CSR proposes few changes to the memory access API, which are aimed at addressing some comments received during the review process, as well as to improve the usability of the API.

Problem

During the review process, we kept track of some API issues (in the issue form which this CSR is derived). Some of the issues have to do with API naming inconsistencies (for instance, the fact that MemroryAddress::offset() and MemoryAddress::offset(long) have very similar names, yet perform radically different operations). Other issues cover some usability problems when working with the API, especially in conjunction with unbound sequence layouts, as there's no way in the API to tell as to whether a memory layout has a defined size.

Solution

To address the aforementioned issues, first we propose the following two cosmetic changes:

• rename MemoryAddress::offset(long) to MemoryAddress::addOffset(long)
• replace the MemorySegment::isAccessible predicate with the MemorySegment::ownerThread accessor

And, to address the usability issues when working with layout with unspecified size, we propose to add the following methods:

• add a predicate MemoryLayout::hasSize, which allows client to tell whether MemoryLayout::bitSize will throw or not.
• add the method SequenceLayout::withElementCount(long), to allow clients to obtain new sequence layouts with given new size (which is useful to turn an unbounded sequence layout into a bounded sequence layout)
• add a method MemoryLayout::map(UnaryOperator<MemoryLayout>, PathElement...) which allow clients to create a copy of the current layout where the element selected by the layout path passed as argument is replaced by a new layout
• add a method MemoryLayout::select(PathElement...) which allow clients to select a (possibly nested) layout at a given path in the current layout

Specification

A specdiff of the proposed changes is attached in this CSR request. A javadoc including the changes is also available here:

http://cr.openjdk.java.net/~mcimadamore/8235837_v3_javadoc