Lookup.findStatic() triggers verification of nestmates attribute too early ?
forax at univ-mlv.fr
forax at univ-mlv.fr
Sat Apr 18 11:47:13 UTC 2020
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Samedi 18 Avril 2020 10:04:38
> Objet: Re: Lookup.findStatic() triggers verification of nestmates attribute too
> early ?
> On Apr 15, 2020, at 5:41 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:
>> i've discovered that using Lookup.findStatic() triggers the verification that
>> the attributes NestHost and the NestMembers are compatible.
>> I believe it's a bug, the equivalent code using bytecodes will no trigger this
>> early verification, the verification is done lazily when a private member of a
>> class of the nest is accessed the first time.
> I don’t think it’s a bug, if the JVMS fine print says what I think it says.
> Nestmate checking is done when a nominal bytecode is resolved, not as
> part of its post-resolution semantics. The rules that say a class is initialized
> lazily on first static access (call or variable access or instance creation)
> are not organized as part of the resolution semantics of those instructions,
> but as part of their run-time semantics. Meanwhile, all relevant resolution
> work is done in Lookup::findX calls, before those calls return. It’s not right
> for the invocation of a method handle *ever* to throw a resolution error;
> all those checks must be done before the MH is created. But nest mate
> checking is done for resolution (as part of JVMS 5.4) not initialization
> (JVMS 5.5).
> As a matter of design, any error which is documented as a “Linking
> Exception” in the JVMS (chapter 6) must be completed before the Lookup
> API call returns a MH. Any error documented as a “Run-time Exception”
> must be performed after the MH is invoked. Those run-time exceptions
> include any which arise from lazy initialization of classes that are targeted
> by Xstatic bytecodes.
> So, yes the Lookup.findStatic call needs to explore nestmate relations.
> And no it cannot defer those until the first call of the resulting MH,
> analogously to lazy <clinit> execution. Was that what you were expecting,
> or did I misread your report?
no, you're fully right,
I was me trying to find an escape hatch instead of seeing the reality in face, my runtime creates some method handle adapters too early and i've to change that.
> — John
More information about the valhalla-dev