[LWorld] Value type array support for C2 (and lots of bug fixes)

Tobias Hartmann tobias.hartmann at oracle.com
Wed May 16 12:27:37 UTC 2018


I've implemented value type array support for C2:

All compiler and runtime tests now pass!

Here are the gory details:
- Interpreter should only test for flattened arrays if ValueArrayFlatten is enabled (see
- Method handle inlining was broken with "signatures mismatch" because
ciMethod::is_consistent_info() returned false for value type arguments (see ciMethod.cpp)
- Type flow analysis needs to support meeting value type arrays with other arrays (see ciTypeFlow.cpp)
- Disabled C2 intrinsics that don't support value types as Ls yet (vmSymbols.cpp)
- Alias analysis should retrieve field information when accessing flattened value type array element
(see compile.cpp)
- Method handle calls with value arguments are broken (didn't show up before because inlining was
broken as well, see doCall.cpp)
- Escape analysis should use flattened array offset to retrieve correct field type information for
flattened value type array accesses (escape.cpp)
- Implemented runtime checks for (flattened) value type array variants (graphKit.cpp)
- Fixed returning null value type (parse1.cpp)
- Added support for aaload/aastore on object or interface array with value type element. Added
corresponding runtime tests. (parse2.cpp, parseHelper.cpp)
- Changed type system to support (flattened) value type meet with other types (type.cpp)
- Fixed removal of default value type allocations that may cause stray initializing stores to remain
in the final code and re-initialize the default allocation (valuetypenode.cpp)
- Disable ValueArrayFlatten if EnableValhalla is false (arguments.cpp)
- Added lots of tests and re-enabled -Xcomp in ValueTypeArray.java
- Some minor refactoring and comment fixes

Open issues:
- The uncommented part of ValueTypeArray.java needs to be fixed (I've filed JDK-8203291)
- The currently disabled C2 intrinsics need to be implemented to support lworld
- Avoid deoptimization if Object[] turns out to be value type array (use runtime calls) and improve
runtime checks
- Fix asymmetric type system [1] and check if we can get rid of TypeValueTypePtr (use TypeInstPtr)

If there are no objections, I would like to push this large change and address the open issues in
smaller follow-up patches.


[1] Meeting TypeValueType with other types is currently not symmetric:

=== Meet Not Symmetric ===
t   =                   valuetype[3]:{int, byte, compiler/valhalla/valuetypes/MyValue2Inline}
this=                   valuetype[8]:{long, int, int, short, java/lang/Integer, [I,
compiler/valhalla/valuetypes/MyValue2, compiler/valhalla/valuetypes/MyValue2}
mt=(t meet this)=       java/lang/Object:NotNull *
t_dual=                 valuetype[3]:{int, byte, compiler/valhalla/valuetypes/MyValue2Inline}
this_dual=              valuetype[8]:{long, int, int, short, java/lang/Integer, [I,
compiler/valhalla/valuetypes/MyValue2, compiler/valhalla/valuetypes/MyValue2}
mt_dual=                java/lang/Object:AnyNull *,iid=top (inline_depth=InlineDepthTop)
mt_dual meet t_dual=    java/lang/Object:AnyNull *
mt_dual meet this_dual= java/lang/Object:AnyNull *

V  [libjvm.so+0x18eb1a1]  Type::meet_helper(Type const*, bool) const+0x2b1
V  [libjvm.so+0x18ed113]  TypeAry::xmeet(Type const*) const+0xf3
V  [libjvm.so+0x18eaf34]  Type::meet_helper(Type const*, bool) const+0x44
V  [libjvm.so+0x18f53d0]  TypeAryPtr::xmeet_helper(Type const*) const+0xf0
V  [libjvm.so+0x18e1a96]  TypePtr::xmeet(Type const*) const+0x16
V  [libjvm.so+0x18eaf34]  Type::meet_helper(Type const*, bool) const+0x44
V  [libjvm.so+0x911fc4]  ConstraintCastNode::dominating_cast(PhaseGVN*, PhaseTransform*) const+0x364
V  [libjvm.so+0x912a28]  CheckCastPPNode::Identity(PhaseGVN*)+0x38
V  [libjvm.so+0x16754b9]  PhaseGVN::transform_no_reclaim(Node*)+0x189
V  [libjvm.so+0xea0bea]  GraphKit::gen_checkcast(Node*, Node*, Node**)+0x2ea

More information about the valhalla-dev mailing list