[lworld] RFR: lworld aaload/aastore
david.simms at oracle.com
Tue Mar 13 16:32:44 UTC 2018
Here's a patch to implement the new lworld semantics for aaload and
aastore with values:
Hotspot implementation currently allows value to be contained in one of
three types of arrays, and the aaload/aastore differs slightly depending
on the array type:
* "Flat value array": valueArrayOop, specifically for holding values
of "element_klass" type (always a "value type") and nothing else
o Loads and stores of null are not permitted
* "Object array": objArrayOop whose "element_klass" is not a "value
type", e.g. "Object", "Comparable" etc
o Maintains the same behavior for both objects and values.
* "Non-flat value array": objArrayOop whose "element_klass" is
specifically a "value type". This is left in the code for handling
special cases like "atomic value class" or "really large value
class" or "many embedded oops value class", where flattening seems
unsuitable. Unclear if this use-case will survive in the long run.
o Maintains the same semantics as "Flat Value Array", i.e.:
Loads and stores of null are not permitted
So semantically, there are two types, "value array" and "object array".
Testing: "runtime/valhalla/valuetypes/ValueTypeArray.java" now passes. I
was a bit concerned for "aaload" performance given it needs to test for
flat array oop (i.e. loads "klass->_layout_helper"). I added a
simulation in a patch in the experiment ("exp") branch, and through it
through our performance "sanity" benchmarks, no regressions. Even small
micro-benchmark had a hard time seeing any difference. So I will avoid
any premature optimization for now, until proven otherwise.
TODO: some further test cases which are better suited to ValueOops and
bytecode API testing, which is a different bug. Also, for the
objArrayOop containers I didn't bother passing by value, so a further
test for ensuring "withfield" is COW op and not affecting the reference
would be a good idea.
More information about the valhalla-dev