-
Notifications
You must be signed in to change notification settings - Fork 5.9k
8326616: tools/javac/patterns/Exhaustiveness.java intermittently Timeout signalled after 480 seconds #20836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back jlahoda! A progress list of the required criteria for merging this PR into |
@lahodaj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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 140 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. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
Outdated
Show resolved
Hide resolved
!(rpOne.nested[i] instanceof BindingPattern bpOne) || | ||
!(rpOther.nested[i] instanceof BindingPattern bpOther) || | ||
!types.isSubtype(types.erasure(bpOne.type), types.erasure(bpOther.type))) { | ||
continue NEXT_PATTERN; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No tests in the patterns
folder executes this block (continue NEXT_PATTERN;
). I am sure it works, can you include a small test that leads to this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -1054,7 +1064,7 @@ private Set<PatternDescription> reduceNestedPatterns(Set<PatternDescription> pat | |||
.stream() | |||
//error recovery, ignore patterns with incorrect number of nested patterns: | |||
.filter(pd -> pd.nested.length == nestedPatternsCount) | |||
.collect(groupingBy(pd -> pd.hashCode(mismatchingCandidateFin))); | |||
.collect(groupingBy(pd -> useHashes ? pd.hashCode(mismatchingCandidateFin) : 0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
groupByHashes
can be renamed into groupByOnlyMismatchingCandidateDifference
or something else. The ByHashes
is not applicable any more in the general case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've used groupEquivalenceCandidates
- please let me know if that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Jan. Nice work!
/integrate |
Going to push as commit a18d9d8.
Your commit was automatically rebased without conflicts. |
This patch revisits the fix for JDK-8325215 (PR: #17949). The problem in that bug was along the following lines.
Consider this code:
The
switch
is exhaustive, but before the fix for JDK-8325215, javac considered it not exhaustive. Ifcase R(S1 _, B _)
is preplaced withcase R(S1 _, S2 _)
, javac will consider theswitch
to be exhaustive.This problem is because to prove that the
switch
is exhaustive, it is necessary to mergeR(S1 _, B _)
andR(S2 _, S2 _)
intoR(B _, S2 _)
, which then can be merged withR(B _, S1 _)
to formR(B _, B_)
, and then justR _
, which means theswitch
is exhaustive.But, before JDK-8325215, javac could merge
R(S1 _, B _)
andR(S2 _, S2 _)
intoR(B _, S2 _)
, because it was looking at the two patterns, set the mismatching component to0
, and was looking at the patterns in all other components, if they are precisely the same - but they are not, so javac failed to merge the patterns. Note that it is permitted to replace a type pattern with a more specific type pattern (i.e. replaceB _
withS2 _
).The solution in JDK-8325215 was to expand all type patterns in all the patterns in the set into their possible permitted subtypes. I.e. in the above case
R(S1 _, B _)
was expanded toR(S1 _, B _)
,R(S1 _, S1 _)
andR(S1 _, S2 _)
. As a consequence, the merging could proceed, and javac would consider theswitch
to be exhaustive.The problem with this solution is that it sometimes leads to a very big pattern set, which the javac then processes very slowly/too slowly.
The proposal alternate fix for the original problem proposed herein is to avoid the creation of the very big pattern set, and rather permit javac to merge
R(S1 _, B _)
andR(S2 _, S2 _)
, becauseB
is a supertype of (more general pattern than)S2
. This is a bit tricky, as the code that searches for merge candidates is using hashes for the patterns, and the hashes speed up the search very significantly (and the use of the hashes is not compatible with the use of the subtyping relation). So, the proposal is to use hashing when possible, and use the subtyping relation when no more patterns can be merged.I ran the
Exhaustiveness
test many times with this change, without a timeout so far.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20836/head:pull/20836
$ git checkout pull/20836
Update a local copy of the PR:
$ git checkout pull/20836
$ git pull https://git.openjdk.org/jdk.git pull/20836/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 20836
View PR using the GUI difftool:
$ git pr show -t 20836
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20836.diff
Webrev
Link to Webrev Comment