8262096: Vector API fails to work due to VectorShape initialization exception #2722
Conversation
|
/issue add JDK-8262096 |
|
|
|
@DamonFool This issue is referenced in the PR title - it will now be updated. |
|
@DamonFool |
|
@DamonFool The label
|
|
@DamonFool The |
|
@DamonFool The label
|
Webrevs
|
|
/label add core-libs |
|
@DamonFool |
|
@DamonFool The |
| oop mirror = JNIHandles::resolve_non_null(clazz); | ||
| if (java_lang_Class::is_primitive(mirror)) { | ||
| BasicType bt = java_lang_Class::primitive_type(mirror); | ||
| return Matcher::max_vector_size(bt); | ||
| } | ||
| int min_lane_count = 64 / type2aelembytes(bt); |
There was a problem hiding this comment.
I am uncertain of the units here. Is the numerator in bits and the denominator in bytes?
There was a problem hiding this comment.
Thanks Paul for your review.
Oops, the numerator should be 8 (bytes).
Updated.
Testing of jdk/incubator/vector (MaxVector=default/8/4 or without C2) is still fine.
Thanks.
There was a problem hiding this comment.
Thanks, was the test VectorShapeInitTest passing prior to the fix of the numerator?
Perhaps we should be testing more directly on VectorShape.S_Max_BIT.vectorBitSize() and VectorShape.preferredShape ?
Also, perhaps we can run with C2 disabled, with -XX:TieredStopAtLevel=3 ?
There was a problem hiding this comment.
Thanks, was the test
VectorShapeInitTestpassing prior to the fix of the numerator?
Yes. It also passed with min_lane_count = 64 / type2aelembytes(bt).
Perhaps we should be testing more directly on
VectorShape.S_Max_BIT.vectorBitSize()andVectorShape.preferredShape?
Ok.
But it that case, I'd like to just re-use jdk/incubator/vector/PreferredSpeciesTest.java.
Also, perhaps we can run with C2 disabled, with
-XX:TieredStopAtLevel=3?
Fine.
Although this bug wouldn't be triggered with -XX:TieredStopAtLevel=x, it can help test with C1.
Patch had been updated.
Any comments?
Thanks.
There was a problem hiding this comment.
Reusing PreferredSpeciesTest is a good idea.
I now realize that C2 needs to be compiled out to trigger some other cases. In that case I think we can remove the execution with -XX:TieredStopAtLevel=x. The test will get executed with various HotSpot configurations by the test infrastructure, eventually...
Looks good.
There was a problem hiding this comment.
In that case I think we can remove the execution with
-XX:TieredStopAtLevel=x.
Fixed. Thanks.
|
/test |
|
@DamonFool you need to get approval to run the tests in tier1 for commits up until 724b36d |
|
@DamonFool This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 29 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
IMO the fix should be in src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java.
JVM does the right job when it signals vector support is absent (by returning -1).
jdk.incubator.vector implementation should take that into account and choose a preferred shape for pure Java execution mode.
Hi @iwanowww , Thanks for your review. From the view of C2 compiler, you are right. But the Java programmer may be confused if we got something like DoubleVector.SPECIES_PREFERRED.length() > VectorSupport.getMaxLaneCount(double.class). What do you think? |
It doesn't make much sense to me. |
Okay, I'm fine to fix it in jdk/incubator/vector/VectorShape.java if we don't keep something like that. For the updated fix, the {max/preferred} shape will be initialized as shape-64-bit if hotspot doesn't support vectorization. Testing:
Any comments? |
|
/test |
|
@DamonFool you need to get approval to run the tests in tier1 for commits up until b67b232 |
For the updated fix, the {max/preferred} shape will be initialized as shape-64-bit if hotspot doesn't support vectorization.
Sounds reasonable.
| * @summary Test the initialization of vector shapes | ||
| * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector | ||
| * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest | ||
| * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest |
There was a problem hiding this comment.
-XX:MaxVectorSize is C2-specific. It's better to specify either -XX:-IgnoreUnrecognizedVMOptions or @requires vm.compiler2.enabled.
There was a problem hiding this comment.
@requires vm.compiler2.enabled had been added.
Thanks.
There was a problem hiding this comment.
@PaulSandoz , are you also OK with the latest version?
Thanks.
There was a problem hiding this comment.
@DamonFool I think Vladimir is correct in the layering, in this respect i think we can make things a littler clearer. This seems like a small thing but i think its worth making very explicit as there is some hidden complexity.
What if we add the following method to VectorShape:
/**
* Returns the maximum vector bit size for a given element type.
*
* @param etype the element type.
* @return the maximum vector bit.
*/
/*package-private*/
static int getMaxVectorBitSize(Class<?> etype) {
// May return -1 if C2 is not enabled,
// or a value smaller than the S_64_BIT.vectorBitSize / elementSizeInBits, on say 32-bit platforms
// If so default to S_64_BIT
int maxLaneCount = VectorSupport.getMaxLaneCount(etype);
int elementSizeInBits = LaneType.of(etype).elementSize;
return Math.max(maxLaneCount * elementSizeInBits, S_64_BIT.vectorBitSize);
}It is package private so it can be tested explicitly if need be.
Then we can reuse that method:
S_Max_BIT(getMaxVectorBitSize(byte.class));
static VectorShape largestShapeFor(Class<?> etype) {
return VectorShape.forBitSize(getMaxVectorBitSize(etype));
}
I think that's correct, but i have not tested. WDYT?
There was a problem hiding this comment.
@DamonFool I think Vladimir is correct in the layering, in this respect i think we can make things a littler clearer. This seems like a small thing but i think its worth making very explicit as there is some hidden complexity.
What if we add the following method to
VectorShape:/** * Returns the maximum vector bit size for a given element type. * * @param etype the element type. * @return the maximum vector bit. */ /*package-private*/ static int getMaxVectorBitSize(Class<?> etype) { // May return -1 if C2 is not enabled, // or a value smaller than the S_64_BIT.vectorBitSize / elementSizeInBits, on say 32-bit platforms // If so default to S_64_BIT int maxLaneCount = VectorSupport.getMaxLaneCount(etype); int elementSizeInBits = LaneType.of(etype).elementSize; return Math.max(maxLaneCount * elementSizeInBits, S_64_BIT.vectorBitSize); }It is package private so it can be tested explicitly if need be.
Then we can reuse that method:
S_Max_BIT(getMaxVectorBitSize(byte.class));static VectorShape largestShapeFor(Class<?> etype) { return VectorShape.forBitSize(getMaxVectorBitSize(etype)); }I think that's correct, but i have not tested. WDYT?
Good suggestion.
Updated.
Testing:
- jdk/incubator/vector with MaxVectorSize=default/8/4 on Linux/x64
- jdk/incubator/vector without C2 on Linux/x64
Thanks.
|
@DamonFool that worked out better than i expected :-) One last thing i missed last time. The |
Yes, we already have this one [1]. |
|
/integrate |
openjdk
bot
added
integrated
|
@DamonFool Since your change was applied there have been 35 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 40bdf52. |
Hi all,
Vector API fails to work when:
The reason is that {max/preferred} VectorShape initialization fails in both cases.
And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
Vector API should not depend on C2 to run.
It should work even there is no JIT compiler since it's a Java-level api.
So let's fix it.
Testing:
Thanks.
Best regards,
Jie
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722$ git checkout pull/2722