archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-08-28 15:24:43 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

8328986: Deprecate UseRTM* flags for removal

Browse source 
Co-authored-by: Roman Kennke <rkennke@openjdk.org>
Reviewed-by: vlivanov, sviswanathan, dholmes
This commit is contained in:
Vladimir Kozlov 2024-03-27 21:56:53 +00:00
parent 0cb0b5db2a
commit 3eb1d05d85
4 changed files with 96 additions and 81 deletions
Download patch file Download diff file Expand all files Collapse all files

154
src/java.base/share/man/java.1
View file

@ -2477,24 +2477,6 @@ This option has a limit of 2 GB; otherwise, an error is generated.
The maximum code cache size shouldn\[aq]t be less than the initial code
cache size; see the option \f[V]-XX:InitialCodeCacheSize\f[R].
.TP
\f[V]-XX:RTMAbortRatio=\f[R]\f[I]abort_ratio\f[R]
Specifies the RTM abort ratio is specified as a percentage (%) of all
executed RTM transactions.
If a number of aborted transactions becomes greater than this ratio,
then the compiled code is deoptimized.
This ratio is used when the \f[V]-XX:+UseRTMDeopt\f[R] option is
enabled.
The default value of this option is 50.
This means that the compiled code is deoptimized if 50% of all
transactions are aborted.
.TP
\f[V]-XX:RTMRetryCount=\f[R]\f[I]number_of_retries\f[R]
Specifies the number of times that the RTM locking code is retried, when
it is aborted or busy, before falling back to the normal locking
mechanism.
The default value for this option is 5.
The \f[V]-XX:UseRTMLocking\f[R] option must be enabled.
.TP
\f[V]-XX:+SegmentedCodeCache\f[R]
Enables segmentation of the code cache, without which the code cache
consists of one large segment.
@ -2728,65 +2710,6 @@ FMA intrinsics are generated for the
value of \f[V](\f[R] \f[I]a\f[R] \f[V]*\f[R] \f[I]b\f[R] \f[V]+\f[R]
\f[I]c\f[R] \f[V])\f[R] expressions.
.TP
\f[V]-XX:+UseRTMDeopt\f[R]
Autotunes RTM locking depending on the abort ratio.
This ratio is specified by the \f[V]-XX:RTMAbortRatio\f[R] option.
If the number of aborted transactions exceeds the abort ratio, then the
method containing the lock is deoptimized and recompiled with all locks
as normal locks.
This option is disabled by default.
The \f[V]-XX:+UseRTMLocking\f[R] option must be enabled.
.TP
\f[V]-XX:+UseRTMLocking\f[R]
Generates Restricted Transactional Memory (RTM) locking code for all
inflated locks, with the normal locking mechanism as the fallback
handler.
This option is disabled by default.
Options related to RTM are available only on x86 CPUs that support
Transactional Synchronization Extensions (TSX).
.RS
.PP
RTM is part of Intel\[aq]s TSX, which is an x86 instruction set
extension and facilitates the creation of multithreaded applications.
RTM introduces the new instructions \f[V]XBEGIN\f[R], \f[V]XABORT\f[R],
\f[V]XEND\f[R], and \f[V]XTEST\f[R].
The \f[V]XBEGIN\f[R] and \f[V]XEND\f[R] instructions enclose a set of
instructions to run as a transaction.
If no conflict is found when running the transaction, then the memory
and register modifications are committed together at the \f[V]XEND\f[R]
instruction.
The \f[V]XABORT\f[R] instruction can be used to explicitly abort a
transaction and the \f[V]XTEST\f[R] instruction checks if a set of
instructions is being run in a transaction.
.PP
A lock on a transaction is inflated when another thread tries to access
the same transaction, thereby blocking the thread that didn\[aq]t
originally request access to the transaction.
RTM requires that a fallback set of operations be specified in case a
transaction aborts or fails.
An RTM lock is a lock that has been delegated to the TSX\[aq]s system.
.PP
RTM improves performance for highly contended locks with low conflict in
a critical region (which is code that must not be accessed by more than
one thread concurrently).
RTM also improves the performance of coarse-grain locking, which
typically doesn\[aq]t perform well in multithreaded applications.
(Coarse-grain locking is the strategy of holding locks for long periods
to minimize the overhead of taking and releasing locks, while
fine-grained locking is the strategy of trying to achieve maximum
parallelism by locking only when necessary and unlocking as soon as
possible.)
Also, for lightly contended locks that are used by different threads,
RTM can reduce false cache line sharing, also known as cache line
ping-pong.
This occurs when multiple threads from different processors are
accessing different resources, but the resources share the same cache
line.
As a result, the processors repeatedly invalidate the cache lines of
other processors, which forces them to read from main memory instead of
their cache.
.RE
.TP
\f[V]-XX:+UseSuperWord\f[R]
Enables the transformation of scalar operations into superword
operations.
@ -3825,6 +3748,83 @@ The default value is 2.
.PP
Use the option \f[V]-XX:MinRAMPercentage\f[R] instead.
.RE
.TP
\f[V]-XX:RTMAbortRatio=\f[R]\f[I]abort_ratio\f[R]
Specifies the RTM abort ratio is specified as a percentage (%) of all
executed RTM transactions.
If a number of aborted transactions becomes greater than this ratio,
then the compiled code is deoptimized.
This ratio is used when the \f[V]-XX:+UseRTMDeopt\f[R] option is
enabled.
The default value of this option is 50.
This means that the compiled code is deoptimized if 50% of all
transactions are aborted.
.TP
\f[V]-XX:RTMRetryCount=\f[R]\f[I]number_of_retries\f[R]
Specifies the number of times that the RTM locking code is retried, when
it is aborted or busy, before falling back to the normal locking
mechanism.
The default value for this option is 5.
The \f[V]-XX:UseRTMLocking\f[R] option must be enabled.
.TP
\f[V]-XX:+UseRTMDeopt\f[R]
Autotunes RTM locking depending on the abort ratio.
This ratio is specified by the \f[V]-XX:RTMAbortRatio\f[R] option.
If the number of aborted transactions exceeds the abort ratio, then the
method containing the lock is deoptimized and recompiled with all locks
as normal locks.
This option is disabled by default.
The \f[V]-XX:+UseRTMLocking\f[R] option must be enabled.
.TP
\f[V]-XX:+UseRTMLocking\f[R]
Generates Restricted Transactional Memory (RTM) locking code for all
inflated locks, with the normal locking mechanism as the fallback
handler.
This option is disabled by default.
Options related to RTM are available only on x86 CPUs that support
Transactional Synchronization Extensions (TSX).
.RS
.PP
RTM is part of Intel\[aq]s TSX, which is an x86 instruction set
extension and facilitates the creation of multithreaded applications.
RTM introduces the new instructions \f[V]XBEGIN\f[R], \f[V]XABORT\f[R],
\f[V]XEND\f[R], and \f[V]XTEST\f[R].
The \f[V]XBEGIN\f[R] and \f[V]XEND\f[R] instructions enclose a set of
instructions to run as a transaction.
If no conflict is found when running the transaction, then the memory
and register modifications are committed together at the \f[V]XEND\f[R]
instruction.
The \f[V]XABORT\f[R] instruction can be used to explicitly abort a
transaction and the \f[V]XTEST\f[R] instruction checks if a set of
instructions is being run in a transaction.
.PP
A lock on a transaction is inflated when another thread tries to access
the same transaction, thereby blocking the thread that didn\[aq]t
originally request access to the transaction.
RTM requires that a fallback set of operations be specified in case a
transaction aborts or fails.
An RTM lock is a lock that has been delegated to the TSX\[aq]s system.
.PP
RTM improves performance for highly contended locks with low conflict in
a critical region (which is code that must not be accessed by more than
one thread concurrently).
RTM also improves the performance of coarse-grain locking, which
typically doesn\[aq]t perform well in multithreaded applications.
(Coarse-grain locking is the strategy of holding locks for long periods
to minimize the overhead of taking and releasing locks, while
fine-grained locking is the strategy of trying to achieve maximum
parallelism by locking only when necessary and unlocking as soon as
possible.)
Also, for lightly contended locks that are used by different threads,
RTM can reduce false cache line sharing, also known as cache line
ping-pong.
This occurs when multiple threads from different processors are
accessing different resources, but the resources share the same cache
line.
As a result, the processors repeatedly invalidate the cache lines of
other processors, which forces them to read from main memory instead of
their cache.
.RE
.SH OBSOLETE JAVA OPTIONS
.PP
These \f[V]java\f[R] options are still accepted but ignored, and a