[jdk21u-dev] RFR: 8321120: Shenandoah: Remove ShenandoahElasticTLAB flag

[Aleksey Shipilev]

On Wed, 17 Jan 2024 08:04:57 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> Hi @shipilev shouldn't we keep the definition of the option to assure the flag is still accepted in case some installation uses it? I think we should not silently remove product flags in released versions, even for DIAGNOSTIC ones.

TBH, there is substantial freedom in dealing with experimental/diagnostic flags. This freedom allows easily adding unstable flags for field use _without_ associated maintenance headache. Once the flag outlives it usefulness, it could (and should) be removed. Once removed, backporting the removal to actively maintained releases simplifies backports.

>From the user interface perspective, there are no stability guarantees attached to these flags. Their management does not even require CSR. Leaving the definition in while removing the implementation actually gets is in more awkward situation when diagnostic/experimental flag silently _does not work_. Yes, one can issue a warning, but I don't think we should care.

This is why there is a long history of doing these cleanups. Just from the top history of `shenandoah_globals.hpp`:
https://bugs.openjdk.org/browse/JDK-8259849
https://bugs.openjdk.org/browse/JDK-8254075
https://bugs.openjdk.org/browse/JDK-8241007
https://bugs.openjdk.org/browse/JDK-8245754
https://bugs.openjdk.org/browse/JDK-8245825

-------------

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/177#issuecomment-1895584528