On Fri, 28 Aug 2026 18:57:23 GMT, Dan Heidinga <[email protected]> wrote:
>> Matias Saavedra Silva has updated the pull request with a new target base >> due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Removed satisfy_unset_field error >> - Merge branch 'master' of github.com:openjdk/jdk into >> early_larval_verifier_8390256 >> - Removed unused flag, moved AssertUnsetFields definition, aligned change >> to spec >> - Test fix and cleanup >> - Dan offline comments >> - Added tests and fixes for oddly ordered frames >> - Fixed crash >> - Cleanup >> - Added test and fix for unusual frame ordering >> - Updated test >> - ... and 1 more: https://git.openjdk.org/jdk/compare/f8c6117c...f7c0a206 > > src/hotspot/share/classfile/verifier.cpp line 2423: > >> 2421: >> 2422: if (fd.access_flags().is_strict()) { >> 2423: if (!current_frame->satisfy_unset_field(fd.name(), >> fd.signature(), initial_strict_fields)) { > > Why are we checking this here? > > The initial set of strict fields is built from iterating the class's fields > so, by construction, any `fd.access_flags().is_strict()` must be in that > initial set. > > We have to check for non-strict fields being named in the early_larval frames > when parsing the StackMapTable, but shouldn't need to check that here during > the verification stage There is one test case that does check for this error. `StrictFieldNotSubset.jasm` attempts to call a putfield on a strict static field which triggers this VerifyError. I think we can keep this error by checking for `fs.access_flags().is_static()` since that seems to be the only way to "cheat" the system here. The other option is to let this happen and allow the verifier to fail differently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32459#discussion_r3883750225
