Bug ID: JDK-8138588 VerifyMergedCPBytecodes option cleanup needed

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 16
16 b24Fixed

Dmitry noticed the following issue:

On 9/29/15 7:26 AM, Dmitry Dmitriev wrote:
> Hello all,
>
> During the work on a review of "8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing" I noticed that VerifyMergedCPBytecodes flag have following comment(hotspot/src/share/vm/runtime/globals.hpp):
>   /* change to false by default sometime after Mustang */                        \
>   product(bool, VerifyMergedCPBytecodes, true,                                         \
>           "Verify bytecodes after RedefineClasses constant pool merging")   \
>
> Mustang is a Java 6. Just interesting: Does anyone know, is it make sense to switch this flag to "false" by default?
>
> Thank you,
> Dmitry

Our options are:

0) remove the comment and leave VerifyMergedCPBytecodes as a
    'product' flag with its current default

1) remove the comment, leave VerifyMergedCPBytecodes as a
    'product' flag and change the default from 'true' to 'false'

2) remove the comment and change VerifyMergedCPBytecodes from
    a 'product' flag into a 'diagnostic' flag with its current default

3) remove the comment, change VerifyMergedCPBytecodes from
    a 'product' flag into a 'diagnostic' flag and change the default
    from 'true' to 'false'

4) remove the comment, leave VerifyMergedCPBytecodes as a
    product flag, make the 'release/product' build default 'false',
    and the 'non-release/non-product' build default 'true'

5) remove the comment, change VerifyMergedCPBytecodes from
    a 'product' flag into a 'diagnostic' flag, make the 'release/product'
    build default 'false', and the 'non-release/non-product' build
    default 'true'

6) remove the comment, remove the flag and always do the
    extra verification step.

7) remove the comment, remove the flag and only do the extra
    verification step when built as 'non-release/non-product'.

I think this covers all the options that we discussed in an
internal e-mail thread.

Changeset: 7d4e86be Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2020-11-10 20:38:25 +0000 URL: https://github.com/openjdk/jdk/commit/7d4e86be
10-11-2020
I pick #7. This flag isn't something that would help us diagnose any problem in the field, it's just to verify that the JVM code is correct. The new classfile for the redefinition has already been verified. I'll add the deprecation and change the default to false with a CSR. Actually there's no way in the world any external customer even knows this flag would exist. I think we should make it go straight to obsolete.
05-11-2020
We really should have changed this to a develop flag a long time ago.
04-11-2020
Retargeted to 17.
04-11-2020
Retargeted to 16.
20-05-2020
Should be looked at in 11 if we are going to allocate resources for RedefineClasses(); definitely don't need this for 10.
05-04-2017
Won't need this flag without constant pool merging.
02-06-2016

CSR :	JDK-8255957 - Make VerifyMergedCPBytecodes option obsolete
Duplicate :	JDK-8222141 - Re-examine VerifyMergedCPBytecodes
Relates :	JDK-8155673 - Remove constant pool merging for class redefinition