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