On Fri, 28 Aug 2026 20:15:03 GMT, Matias Saavedra Silva <[email protected]>
wrote:
>> 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.
The spec rule states:
> The referenced field is removed, if present, from the outgoing UnsetFields.
and is expressed in prolog as:
> ``` delete(UnsetFields, CP, NextUnsetFields),```
There's nothing that tries to validate the field is in the set of strict fields
(because if it's a strict instance field, it must be).
Verification is worried about type safety, not linkage; members may be absent
or inaccessible at runtime and that's OK. Linkage related checks validate that
the field exists and is accessible. The verifier says if it is there, the code
is safe.
I think we need to remove this check - it's trying to do linkage's job
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32459#discussion_r3883815861
