[lworld] RFR: lworld aaload/aastore

David Simms david.simms at oracle.com
Wed Mar 21 13:28:26 UTC 2018


Updated version of aaload/aastore and copy_array for the interpreter...

http://cr.openjdk.java.net/~dsimms/valhalla/lworld_value_aaloadstore/webrev3/

Assumes the current thinking that all value type arrays are flat, but 
are covariant with Object array and interface arrays:

  * aaload/aastore: works with both objArrayOop and valueArrayOop (flat)
      o currently assumes always flat semantics for value type element
        class even for objArrayOop (if value deemed unsuitable as flat),
        i.e. no null-ability
      o objArrayOop with values works as vanilla array, i.e. has
        null-ability, for non-value type classes
  * aaload JVMS changes:
      o If source array element type is value class (flat array
        semantics), the result is never null, but equivalent to the
        "defaultvalue" bytecode.
  * aastore JVMS changes:
      o May NPE if the target array element type is value class (flat
        array semantics)
      o May OOM if the source value is "buffered" and target array is
        element type is not value class (ref array semantics)
  * covariance
      o V[] <: I[]: Object[] <: Object where V = value type class, and I
        = any one of V's interface super types.
          + E.g. "__ByValue Point implements Comparable", therefore:
            Point[] <: Comparable[]
          + instanceof/checkcast, functions as described above
          + System.arraycopy() (interpreter implementation) now accepts
            as described above
              # May NPE when attempting to store null into an array with
                element type of value class (flat array semantics)



There are number of tests added to "ValueTypeArray.java", including some 
sanity test of some "java.util" array related classes. Collections are a 
larger topic which the test does not try to address fully. But the 
sanity tests do raise a few interesting observations when fitting value 
arrays into current JDK collections:

  * ArrayList and ArrayDeque specifically use "Object[] elementData",
    and accepts no subtype (see "ArrayList(Collection<? extends E> c)",
    will even copy the source array if not Object[])
      o So given System.arraycopy from value array to object array now
        works, as does aaload/store of a value to and from Object array,
        it all works (in so far as the sanity check tests). Even
        ArrayList.remove(), since the backing store is always a
        reference array.
  * Arrays.toList() produces its own ArrayList with a backing array of
    the sharp type, so potentially a value type array without
    null-ability characteristics
      o ...this is fine, doesn't implement "remove()".

Given what I said about ArrayList backing being Object[] 
("Collection.toArray()" must return component type Object), and the API 
allowing nulls, our current javac behavior is a little weird. Check this 
code out:

     ArrayList<MyInt> aList = new 
ArrayList<MyInt>(Arrays.asList(copyMyInts));

     aList.add((MyInt)getNull()); // <<< Some issues here, should this 
be legal ? With "ArrayList<>", yes but maybe not with 
"ArrayList<Value-Type>"

Currently javac is inserting "java/util/Objects.requireNonNull". At 
first I wanted to argue that check-cast should handle null with value 
class automatically. But wait, generic erasure means I see 
"ArrayList.add(LObject;)" in the VM, so null is perfectly fine...but the 
intention is "ArrayList<MyInt>.add(LMyInt;)...so my bad ?


/D




More information about the valhalla-dev mailing list