RFR: 8235966: Process obsolete flags less aggressively
David Holmes
david.holmes at oracle.com
Mon Dec 16 05:16:09 UTC 2019
Bug: https://bugs.openjdk.java.net/browse/JDK-8235966
webrev: http://cr.openjdk.java.net/~dholmes/8235966/webrev/
When a flag is marked as obsolete in the special-flags table we will
ignore it and issue a warning that it is being ignored, as soon as we
bump the version of the JDK. That means that any tests still using the
obsolete flag may start to fail, leading to a surge of test failures at
the start of a release cycle. For example for JDK 15 we have a whole
bunch of JFR tests that fail because they still try to work with
UseParallelOldGC. In another case
runtime/cds/appcds/FieldLayoutFlags.java passes only be accident.
When a flag is marked as obsolete for a release, all code involving that
flag (including tests that use it) must be updated within that release
and the flag itself removed. Whilst this is typically scheduled early in
a release cycle it isn't reasonable to expect it to all occur within the
first couple of days of the release cycle, nor do we want to have to
ProblemList a bunch of tests when they start failing.
What I propose is to instead allow an obsolete flag to continue to be
processed as long as that code removal has not actually occurred - with
an adjusted warning. The change I propose:
- only treats an obsolete flag as obsolete if the flag cannot be found
- added a new flag verification rule that disallows obsoletion in an
undefined version, but expiration in a specific version i.e. we must
always explicitly obsolete a flag before we expire it.
The only downside here is that if we actually forget to file an issue
for the actual obsoletion work we may not notice via testing. Of course
whenever a change is made to the flags table to add an entry then the
issue to do the obsoletion should be filed at the same time.
Thanks,
David
-----
More information about the hotspot-dev
mailing list