8292082: Deprecate UseRTM* for removal

[rkennke]

HotSpot supports RTM (restricted transactional memory) to be used for locking and deoptimization. RTM has since been disabled in Intel processors due to security vulnerabilities [0] and IBM removed support for it since its Power 10 line. RTM adds unnecessarily to complexity and maintenance burden.

I would like to propose to deprecate the relevant flags for removal, and actually remove the flags and all related code in a later release, unless somebody comes up with a good reason and performance comparison to show that it's worth keeping.

[0] https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs

Testing:

• [x] runtime/CommandLine/VMDeprecatedOptions.java
• [x] tier1

---

Progress

• [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [ ] Change requires a CSR request to be approved

Issues

• JDK-8292082: Deprecate UseRTM* for removal
• JDK-8292096: Deprecate UseRTM* for removal (CSR)

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9810/head:pull/9810
$ git checkout pull/9810

Update a local copy of the PR:
$ git checkout pull/9810
$ git pull https://git.openjdk.org/jdk pull/9810/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9810

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9810.diff

[bridgekeeper[bot]]

:wave: Welcome back rkennke! 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[bot]]

@rkennke The following label will be automatically applied to this pull request:

• hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[rkennke]

/cc hotspot-compiler

[mlbridge[bot]]

Webrevs

• 00: Full (6328279b)

[openjdk[bot]]

@rkennke The hotspot-compiler label was successfully added.

[openjdk[bot]]

@rkennke This change is no longer ready for integration - check the PR body for details.

[fisk]

Might need a CSR.

[sviswa7]

@vnkozlov @rkennke RTM feature is available on Intel ICX as well as upcoming Xeon platforms.

[rkennke]

@vnkozlov @rkennke RTM feature is available on Intel ICX as well as upcoming Xeon platforms.

Ok, interesting. I did not know that. Is our RTM locking implementation still useful, though? Does it have advantages over locking without RTM, and if so, what are they?

[sviswa7]

@rkennke RTM locking provides benefit of fine grain lock performance with coarse grain lock. It is useful when there is high contention on lock and low conflict in the critical region.

[bridgekeeper[bot]]

@rkennke 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!

[rkennke]

Is there interest in getting rid of RTM locking, or should I close this PR as won't-fix at this point?

[dholmes-ora]

As this still appears to be an active and useful feature there needs to be a strong motivation for removing it.

[vnkozlov]

Is there interest in getting rid of RTM locking, or should I close this PR as won't-fix at this point?

Close PR.

[rkennke]

Closing, will keep RTM locking for the time being.