Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8236853

Memory access API refinements



    • CSR
    • Status: Closed
    • P2
    • Resolution: Approved
    • 14
    • core-libs
    • None
    • source
    • low
    • There are two method name changes - which will require client code adjustments. All remaining methods are additions, so they should cause no issues.
    • Java API



      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.


      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.


      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


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



        Issue Links



              mcimadamore Maurizio Cimadamore
              mcimadamore Maurizio Cimadamore
              Chris Hegarty, Paul Sandoz
              0 Vote for this issue
              3 Start watching this issue