8072422: Cleanup: Remove some unused flags/code in loop optimizations

[y1yang0]

We encountered this problem in downstream JDK. This is a backport of JDK-8283672, which simply removes several diagnostic flags, build passed. There is a related fix https://bugs.openjdk.java.net/browse/JDK-8159715, I would backport it after the current fix merged.

Original changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a1e41855499b

Please help review it.

Thanks.

---

Progress

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

Issue

• JDK-8072422: Cleanup: Remove some unused flags/code in loop optimizations

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk8u-dev pull/22/head:pull/22
$ git checkout pull/22

Update a local copy of the PR:
$ git checkout pull/22
$ git pull https://git.openjdk.java.net/jdk8u-dev pull/22/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22

View PR using the GUI difftool:
$ git pr show -t 22

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk8u-dev/pull/22.diff

[bridgekeeper]

👋 Welcome back yyang! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 01: Full - Incremental (11338be2)
• 00: Full (4b4adcd6)

[jerboaa]

@kelthuzadx Skara tooling doesn't recognize this as a backport. Please use pull request title Backport <sha-of-original-commit> which should then let the bots do it's thing and figure out it's a backport and change the title back to the right bug description.

With that said, what are you trying to do? Looking at both bugs it sounds like if we don't introduce JDK-8072422, then JDK-8159715 won't be an issue? If you are seeing an issue, without it I strongly encourage you to bring in the fix without the cleanup patch.

[y1yang0]

Please use pull request title Backport <sha-of-original-commit> which should then let the bots do it's thing and figure out it's a backport and change the title back to the right bug description.

Thanks, I will do that.

With that said, what are you trying to do? Looking at both bugs it sounds like if we don't introduce JDK-8072422, then JDK-8159715 won't be an issue? If you are seeing an issue, without it I strongly encourage you to bring in the fix without the cleanup patch.

We do need the cleanup patch, because dragonwell-project/dragonwell8#305 reports a crash due to use of UnrollLoopLimit, this flag is not supposed to be used by end users, it could be removed by cleanup patch. As I understand, the cleanup patch introduces another problem that can be fixed by JDK-8159715, so once cleanup backport is merged, I will backport JDK-8159715 as well.

[openjdk]

This backport pull request has now been updated with issue and summary from the original commit.

[jerboaa]

We do need the cleanup patch, because alibaba/dragonwell8#305 reports a crash due to use of UnrollLoopLimit, this flag is not supposed to be used by end users, it could be removed by cleanup patch. As I understand, the cleanup patch introduces another problem that can be fixed by JDK-8159715, so once cleanup backport is merged, I will backport JDK-8159715 as well.

So we have a work-around: Don't use -XX:+UnlockDiagnosticVMOptions -XX:-UnrollLimitCheck. We shouldn't take backporting non-critical fixes to JDK 8u lightly. This very much sounds like a jdk8u-fix-no candidate to me. Are you aware of this? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html

[y1yang0]

We do need the cleanup patch, because alibaba/dragonwell8#305 reports a crash due to use of UnrollLoopLimit, this flag is not supposed to be used by end users, it could be removed by cleanup patch. As I understand, the cleanup patch introduces another problem that can be fixed by JDK-8159715, so once cleanup backport is merged, I will backport JDK-8159715 as well.

So we have a work-around: Don't use -XX:+UnlockDiagnosticVMOptions -XX:-UnrollLimitCheck. We shouldn't take backporting non-critical fixes to JDK 8u lightly. This very much sounds like a jdk8u-fix-no candidate to me. Are you aware of this? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html

Okay, I've read this guideline, it seems that the upstream mainline is not less willing to accept non-critical backports, I'm considering doing a backport in downstream.