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

Memory access API refinements

    XMLWordPrintable

Details

    • CSR
    • Resolution: Approved
    • P2
    • 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

    Description

      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

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: