8355792: Remove expired flags in JDK 26
Reviewed-by: coleenp, kvn
This commit is contained in:
parent
d186dacdb7
commit
bcf860703d
@ -528,9 +528,6 @@ static SpecialFlag const special_jvm_flags[] = {
|
|||||||
{ "DynamicDumpSharedSpaces", JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
|
{ "DynamicDumpSharedSpaces", JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
|
||||||
{ "RequireSharedSpaces", JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
|
{ "RequireSharedSpaces", JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
|
||||||
{ "UseSharedSpaces", JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
|
{ "UseSharedSpaces", JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
|
||||||
#ifdef LINUX
|
|
||||||
{ "UseLinuxPosixThreadCPUClocks", JDK_Version::jdk(24), JDK_Version::jdk(25), JDK_Version::jdk(26) },
|
|
||||||
#endif
|
|
||||||
{ "LockingMode", JDK_Version::jdk(24), JDK_Version::jdk(26), JDK_Version::jdk(27) },
|
{ "LockingMode", JDK_Version::jdk(24), JDK_Version::jdk(26), JDK_Version::jdk(27) },
|
||||||
#ifdef _LP64
|
#ifdef _LP64
|
||||||
{ "UseCompressedClassPointers", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::undefined() },
|
{ "UseCompressedClassPointers", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::undefined() },
|
||||||
@ -540,7 +537,6 @@ static SpecialFlag const special_jvm_flags[] = {
|
|||||||
|
|
||||||
// -------------- Obsolete Flags - sorted by expired_in --------------
|
// -------------- Obsolete Flags - sorted by expired_in --------------
|
||||||
|
|
||||||
{ "PerfDataSamplingInterval", JDK_Version::undefined(), JDK_Version::jdk(25), JDK_Version::jdk(26) },
|
|
||||||
#ifdef LINUX
|
#ifdef LINUX
|
||||||
{ "UseOprofile", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) },
|
{ "UseOprofile", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) },
|
||||||
#endif
|
#endif
|
||||||
|
@ -2917,71 +2917,12 @@ when they're used.
|
|||||||
|
|
||||||
## Removed Java Options
|
## Removed Java Options
|
||||||
|
|
||||||
These `java` options have been removed in JDK @@VERSION_SPECIFICATION@@ and using them results in an error of:
|
No documented java options have been removed in JDK @@VERSION_SPECIFICATION@@.
|
||||||
|
|
||||||
> `Unrecognized VM option` *option-name*
|
|
||||||
|
|
||||||
`-XX:RTMAbortRatio=`*abort\_ratio*
|
|
||||||
: 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 `-XX:+UseRTMDeopt` 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.
|
|
||||||
|
|
||||||
`-XX:RTMRetryCount=`*number\_of\_retries*
|
|
||||||
: 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 `-XX:UseRTMLocking` option must
|
|
||||||
be enabled.
|
|
||||||
|
|
||||||
`-XX:+UseRTMDeopt`
|
|
||||||
: Autotunes RTM locking depending on the abort ratio. This ratio is specified
|
|
||||||
by the `-XX:RTMAbortRatio` 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 `-XX:+UseRTMLocking` option must be enabled.
|
|
||||||
|
|
||||||
`-XX:+UseRTMLocking`
|
|
||||||
: 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).
|
|
||||||
|
|
||||||
RTM is part of Intel's TSX, which is an x86 instruction set extension and
|
|
||||||
facilitates the creation of multithreaded applications. RTM introduces the
|
|
||||||
new instructions `XBEGIN`, `XABORT`, `XEND`, and `XTEST`. The `XBEGIN` and
|
|
||||||
`XEND` 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 `XEND` instruction.
|
|
||||||
The `XABORT` instruction can be used to explicitly abort a transaction and
|
|
||||||
the `XTEST` instruction checks if a set of instructions is being run in a
|
|
||||||
transaction.
|
|
||||||
|
|
||||||
A lock on a transaction is inflated when another thread tries to access the
|
|
||||||
same transaction, thereby blocking the thread that didn'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's system.
|
|
||||||
|
|
||||||
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'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.
|
|
||||||
|
|
||||||
For the lists and descriptions of options removed in previous releases see the *Removed Java Options* section in:
|
For the lists and descriptions of options removed in previous releases see the *Removed Java Options* section in:
|
||||||
|
|
||||||
|
- [The `java` Command, Release 25](https://docs.oracle.com/en/java/javase/25/docs/specs/man/java.html)
|
||||||
|
|
||||||
- [The `java` Command, Release 24](https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html)
|
- [The `java` Command, Release 24](https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html)
|
||||||
|
|
||||||
- [The `java` Command, Release 23](https://docs.oracle.com/en/java/javase/23/docs/specs/man/java.html)
|
- [The `java` Command, Release 23](https://docs.oracle.com/en/java/javase/23/docs/specs/man/java.html)
|
||||||
|
Loading…
x
Reference in New Issue
Block a user