Skip to content
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

8258422: Cleanup unnecessary null comparison before instanceof check in java.base #20

Conversation

turbanoff
Copy link
Member

@turbanoff turbanoff commented Sep 5, 2020


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20
$ git checkout pull/20

@bridgekeeper bridgekeeper bot added the oca Needs verification of OCA signatory status label Sep 5, 2020
@bridgekeeper
Copy link

bridgekeeper bot commented Sep 5, 2020

Hi @turbanoff, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user turbanoff" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

@openjdk
Copy link

openjdk bot commented Sep 5, 2020

@turbanoff The following labels will be automatically applied to this pull request: core-libs`, `net`, `nio. When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label (add|remove) "label" command.

@openjdk openjdk bot added nio nio-dev@openjdk.org core-libs core-libs-dev@openjdk.org net net-dev@openjdk.org labels Sep 5, 2020
@turbanoff
Copy link
Member Author

/signed

@bridgekeeper bridgekeeper bot added the oca-verify Needs verification of OCA signatory status label Sep 5, 2020
@bridgekeeper
Copy link

bridgekeeper bot commented Sep 5, 2020

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

@turbanoff turbanoff force-pushed the cleanup_null_checks_before_instanceof_in_java.base branch from 71fa52f to f09bbd2 Compare Sep 6, 2020
@bridgekeeper bridgekeeper bot removed oca Needs verification of OCA signatory status oca-verify Needs verification of OCA signatory status labels Sep 8, 2020
@bridgekeeper
Copy link

bridgekeeper bot commented Oct 4, 2020

@turbanoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@turbanoff
Copy link
Member Author

turbanoff commented Oct 4, 2020

I believe this changes is useful and still actual:

  1. improve code to make it easier to read.
  2. performance should be improved a bit too

@stuart-marks
Copy link
Member

I’ll see if I can get somebody to take a look at this.

@ChrisHegarty
Copy link
Member

This seems like a reasonable change, which improves readability.

My preference is to wait a little longer (hopefully no more than a couple of weeks), until JEP 394 - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:

+++ b/src/java.base/share/classes/java/io/File.java
@@ -2191,8 +2191,8 @@ public class File
      *          {@code false} otherwise
      */
     public boolean equals(Object obj) {
-        if ((obj != null) && (obj instanceof File)) {
-            return compareTo((File)obj) == 0;
+        if (obj instanceof File file) {
+            return compareTo(file) == 0;
         }
         return false;
     }

@turbanoff
Copy link
Member Author

Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448

@AlekseiEfimov
Copy link
Member

Hi @turbanoff,

I've logged a JBS issue for tracking this change:
https://bugs.openjdk.java.net/browse/JDK-8258422

JEP 394 is finalized now, so I guess you could follow-up Chris suggestion to remove the explicit casts.

After the fix is properly reviewed and marked as ready for the integration (you'll need to issue /integrate command), once it is done I would happily /sponsor the change.

With Best Regards,
Aleksei

@AlekseiEfimov
Copy link
Member

/issue JDK-8258422

@openjdk
Copy link

openjdk bot commented Dec 15, 2020

@AlekseiEfimov Only the author (@turbanoff) is allowed to issue the /issue command.

@turbanoff
Copy link
Member Author

/issue JDK-8258422

@openjdk openjdk bot changed the title [PATCH] Cleanup unnecessary null comparison before instanceof check 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Dec 15, 2020
@openjdk
Copy link

openjdk bot commented Dec 15, 2020

@turbanoff The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

@openjdk openjdk bot added the rfr Pull request is ready for review label Dec 15, 2020
@mlbridge
Copy link

mlbridge bot commented Dec 15, 2020

Webrevs

@turbanoff turbanoff force-pushed the cleanup_null_checks_before_instanceof_in_java.base branch from f09bbd2 to 603cd36 Compare Dec 15, 2020
…in java.base

use instanceof pattern matching in UnixPath too
@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

26 similar comments
@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

@openjdk
Copy link

openjdk bot commented Jan 11, 2021

@AlekseiEfimov The command sponsor can only be used in open pull requests.

cushon pushed a commit to cushon/jdk that referenced this pull request Apr 2, 2021
@turbanoff turbanoff deleted the cleanup_null_checks_before_instanceof_in_java.base branch Sep 15, 2021
fg1417 pushed a commit to fg1417/jdk that referenced this pull request Aug 17, 2022
After JDK-8283091, the loop below can be vectorized partially.
Statement 1 can be vectorized but statement 2 can't.
```
// int[] iArr; long[] lArrFld; int i1,i2;
for (i1 = 6; i1 < 227; i1++) {
  iArr[i1] += lArrFld[i1]++; // statement 1
  iArr[i1 + 1] -= (i2++); // statement 2
}
```

But we got incorrect results because the vector packs of iArr are
scheduled incorrectly like:
```
...
load_vector XMM1,[R8 + openjdk#16 + R11 << openjdk#2]
movl    RDI, [R8 + openjdk#20 + R11 << openjdk#2] # int
load_vector XMM2,[R9 + openjdk#8 + R11 << openjdk#3]
subl    RDI, R11    # int
vpaddq  XMM3,XMM2,XMM0  ! add packedL
store_vector [R9 + openjdk#8 + R11 << openjdk#3],XMM3
vector_cast_l2x  XMM2,XMM2  !
vpaddd  XMM1,XMM2,XMM1  ! add packedI
addl    RDI, openjdk#228   # int
movl    [R8 + openjdk#20 + R11 << openjdk#2], RDI # int
movl    RBX, [R8 + openjdk#24 + R11 << openjdk#2] # int
subl    RBX, R11    # int
addl    RBX, openjdk#227   # int
movl    [R8 + openjdk#24 + R11 << openjdk#2], RBX # int
...
movl    RBX, [R8 + openjdk#40 + R11 << openjdk#2] # int
subl    RBX, R11    # int
addl    RBX, openjdk#223   # int
movl    [R8 + openjdk#40 + R11 << openjdk#2], RBX # int
movl    RDI, [R8 + openjdk#44 + R11 << openjdk#2] # int
subl    RDI, R11    # int
addl    RDI, openjdk#222   # int
movl    [R8 + openjdk#44 + R11 << openjdk#2], RDI # int
store_vector [R8 + openjdk#16 + R11 << openjdk#2],XMM1
...
```
simplified as:
```
load_vector iArr in statement 1
unvectorized loads/stores in statement 2
store_vector iArr in statement 1
```
We cannot pick the memory state from the first load for LoadI pack
here, as the LoadI vector operation must load the new values in memory
after iArr writes 'iArr[i1 + 1] - (i2++)' to 'iArr[i1 + 1]'(statement 2).
We must take the memory state of the last load where we have assigned
new values ('iArr[i1 + 1] - (i2++)') to the iArr array.

In JDK-8240281, we picked the memory state of the first load. Different
from the scenario in JDK-8240281, the store, which is dependent on an
earlier load here, is in a pack to be scheduled and the LoadI pack
depends on the last_mem. As designed[2], to schedule the StoreI pack,
all memory operations in another single pack should be moved in the same
direction. We know that the store in the pack depends on one of loads in
the LoadI pack, so the LoadI pack should be scheduled before the StoreI
pack. And the LoadI pack depends on the last_mem, so the last_mem must
be scheduled before the LoadI pack and also before the store pack.
Therefore, we need to take the memory state of the last load for the
LoadI pack here.

To fix it, the pack adds additional checks while picking the memory state
of the first load. When the store locates in a pack and the load pack
relies on the last_mem, we shouldn't choose the memory state of the
first load but choose the memory state of the last load.

[1]https://github.com/openjdk/jdk/blob/0ae834105740f7cf73fe96be22e0f564ad29b18d/src/hotspot/share/opto/superword.cpp#L2380
[2]https://github.com/openjdk/jdk/blob/0ae834105740f7cf73fe96be22e0f564ad29b18d/src/hotspot/share/opto/superword.cpp#L2232

Jira: ENTLLT-5482
Change-Id: I341d10b91957b60a1b4aff8116723e54083a5fb8
CustomizedGitHooks: yes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated net net-dev@openjdk.org nio nio-dev@openjdk.org
6 participants