Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]

2024-06-03 Thread Vladimir Ivanov
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote: >> JVM routinely installs loader constraints for unloaded signature classes >> when method resolution takes place. MethodHandle resolution took a different >> route and eagerly resolves signature classes instead (see >>

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]

2024-06-03 Thread Chen Liang
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote: >> JVM routinely installs loader constraints for unloaded signature classes >> when method resolution takes place. MethodHandle resolution took a different >> route and eagerly resolves signature classes instead (see >>

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]

2024-06-03 Thread Jorn Vernee
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote: >> JVM routinely installs loader constraints for unloaded signature classes >> when method resolution takes place. MethodHandle resolution took a different >> route and eagerly resolves signature classes instead (see >>

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]

2024-06-03 Thread Vladimir Ivanov
> JVM routinely installs loader constraints for unloaded signature classes when > method resolution takes place. MethodHandle resolution took a different route > and eagerly resolves signature classes instead (see > `java.lang.invoke.MemberName$Factory::resolve` and >

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles

2024-06-03 Thread Vladimir Ivanov
On Tue, 21 May 2024 20:14:41 GMT, Jorn Vernee wrote: >> Class loading triggered by `Class.forName()` call is at the core of >> `isTypeVisible`. (The rest is fast path checks.) It's what makes >> `isTypeVisible` query idempotent. >> >> I can definitely name it differently (e.g,

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles

2024-05-21 Thread Jorn Vernee
On Tue, 21 May 2024 18:02:45 GMT, Vladimir Ivanov wrote: > I can definitely name it differently (e.g, ensureTypeVisible), but making a > separate class loading pass across signature classes doesn't make much sense. Ok, in that case I suggest also renaming `MemberName::checkForTypeAlias`, maybe

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles

2024-05-21 Thread Vladimir Ivanov
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote: > JVM routinely installs loader constraints for unloaded signature classes when > method resolution takes place. MethodHandle resolution took a different route > and eagerly resolves signature classes instead (see >

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles

2024-05-21 Thread Jorn Vernee
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote: > JVM routinely installs loader constraints for unloaded signature classes when > method resolution takes place. MethodHandle resolution took a different route > and eagerly resolves signature classes instead (see >

Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles

2024-05-20 Thread Chen Liang
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote: > JVM routinely installs loader constraints for unloaded signature classes when > method resolution takes place. MethodHandle resolution took a different route > and eagerly resolves signature classes instead (see >

RFR: 8332547: Unloaded signature classes in DirectMethodHandles

2024-05-20 Thread Vladimir Ivanov
JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and