Lookup.findStatic() triggers verification of nestmates attribute too early ?
john.r.rose at oracle.com
Sat Apr 18 19:23:13 UTC 2020
On Apr 18, 2020, at 4:47 AM, forax at univ-mlv.fr wrote:
> 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 <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.
OK, that’s a relief. Well, we made a teaching moment about
“Linking Exception” vs. “Run-time Exception”, and its interaction
with MH design, which we talked about in the JSR 292 EG, but
probably wasn’t documented anywhere.
More information about the valhalla-dev