RFR: 8277216: Examine InstanceKlass::_misc_flags for concurrency issues [v3]

[Coleen Phillimore]

On Wed, 15 Dec 2021 20:06:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Recent bug in misc_flags showed that they are not set concurrently and could cause bugs.  Most of the misc_flags are set at classfile parsing time or at a safepoint and never reset.  This change adds an assert that the flag is set once.  See CR for more details.
>> Tested with tier1-3.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into misc
>  - Fix typo.
>  - Move has_resolved_methods to access flags so can be set and tested concurretly.
>  - Move has_resolved_methods to access flags so can be set and tested concurretly.
>  - 8277216: Examine InstanceKlass::_misc_flags for concurrency issues

Setting misc_flags to false repeatedly isn't going to break anything wrt. concurrency.
If you look at the CR, there are misc_flags that are not set during parsing.  We could separate them to parsing ones and not parsing ones (two u1 flags) maybe.  Seemed not worth the effort.
I looked at making the setting functions for misc_flags not take a bool but then I'd have to do this in ClassFileParser, which seemed more verbose:
      ik->set_has_nonstatic_fields(_field_info->_has_nonstatic_fields);
 change to:
      if (_field_info->_has_nonstatic_fields) {
         set_has_nonstatic_fields();
      }

So worse, for not a very compelling reason.

I'm actually not that happy with moving misc_flags (set has_resolved_methods) to access_flags in order to get atomic semantics.  I want access flags to be things in the class file not control information (control information should be in the metadata instead).  If I redid this change, that's what I'd do but it affects more than Klass access_flags.

This change helps us not fall into the trap that caused the bug that I recently fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/6851