8059847: complement JDK-8055286 and JDK-8056964 changes

[ktakakuri]

Hi all,

This is a backport of JDK-8059847: complement JDK-8055286 and JDK-8056964 changes

JDK-8055286 and JDK-8056964 are already backported to JDK8, but this patch is not. For this reason, CompileCommand=option does not support flags of type double, as reported. So this patch should be applied.

The original patch is applied cleanly.

Testing: hotspot_tier1 including the test which come with this patch.

Thank you.

---

Progress

• Change must not contain extraneous whitespace
• JDK-8059847 needs maintainer approval
• Commit message must refer to an issue

Issue

• JDK-8059847: complement JDK-8055286 and JDK-8056964 changes (Enhancement - P5)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/396/head:pull/396
$ git checkout pull/396

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 396

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/396.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ktakakuri! 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.

[openjdk]

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

[openjdk]

⚠️ @ktakakuri This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[mlbridge]

Webrevs

• 00: Full (021d07be)

[jerboaa]

Please explain why this backport is needed? It's a P5 enhancement and it's unclear why it's needed now in the current stage of the lifecycle of OpenJDK 8.

[ktakakuri]

Thank you for your comment.
When submitting this PR, I thought that the -XX:CompileCommand=option could handle all available flag types except double and that this follow-up enhancement should be backported for completeness.
However the uint64_t type is used as a flag type but is not handled by CompileCommand.
Now that I know this, I don't think there's much need to backport this fix, so I close this request.