Preload attribute

[Frederic Parain]

Hi Dan,

I've looked at your exploration of the Preload attribute. The LoaderTest 
test loads class A but it doesn't link it. HotSpot looks at the PreLoad 
attribute at class link time, not class load time (yes, the name is 
misleading), this is why class B is not loaded.

Replacing the call to loadClass() with a call to Class.forName() to 
force the linking of the class will trigger the processing of the 
PreLoad attribute.


public static void main(String[] args) throws Throwable {
     ARGS = args;

     ClassLoader cl = new LoaderTest2();
     Class<?> c = Class.forName(args[0], true, cl);
     System.out.println(""+c+"::loader="+c.getClassLoader());

}


Fred


On 6/8/23 12:01 PM, Dan Heidinga wrote:
> Thanks Dan and Fred for the clarification on the current spec and 
> Hotspot behaviour and John for suggesting we remove the attribute.
>
> I think the problem with the current status quo for the preload 
> attribute is that we're trying to treat it like an optimization - a 
> "we can have our cake" (know which classes to load at some 
> indeterminate point) and "eat it too" (not promise users anything 
> about when or if those classes will be loaded).
>
> As it stands, based just on the spec, it's hard for users to know what 
> the preload attribute will do for them.  There's nothing they can 
> depend on in the spec and are at the mercy of whatever behaviour VM 
> implementers pick on a given day.  Which means they will depend on the 
> current Hotspot behaviour (defacto standardization - yuck!) or expect 
> the behaviour to change all the time.
>
> If we decouple the list of preloadable classes from the classfile, how 
> would non-jdk classes be handled?  Many applications are a mix of 
> multiple jar files from different maintenance domains which would make 
> having a combined list difficult.  We'd also need to think through the 
> classloader implications vs today's approach which attempts to load on 
> the same loader as the class with the preload attribute.
>
> What if instead of ditching the attribute, or treating it like an 
> optimization, we firmed up the contract and treated it as a guarantee 
> similar to those of superclasses and superinterfaces as in the first 
> line in section 5.4 "Linking"?  The new text would read something like:
>    > Linking a class or interface involves verifying and preparing 
> that class or interface, its direct superclass, its direct 
> superinterfaces, and its element type (if it is an array type), if 
> necessary. Any classes listed in the preload attribute will be loaded 
> at this point.
>
> We don't need to say in the JVMS why the classes are in the attribute, 
> but we should be explicit about where the attempt to load them occurs 
> and that errors are ignored.  This provides stability to the users and 
> allows for independent implementation while avoiding de 
> facto standardization of today's behaviour.
>
> Before responding, I built the latest lworld branch of the Valhalla 
> repo and played with the preload attribute to try and force a 
> classloader-related deadlock.  I was surprised to find that the 
> attribute doesn't seem to have an effect on user-defined loaders and 
> with the current spec, I can't even say if that's a bug or not.  
> Example classfiles for this exploration are in 
> https://github.com/DanHeidinga/valhalla-preload-example
>
> --Dan
>
> On Mon, Jun 5, 2023 at 9:52 PM John Rose <john.r.rose at oracle.com> wrote:
>
>     Overall, as we look at Preload, it is looking more and more like a
>     no-op, as far as the JLS and JVMS is concerned. Perhaps that is a
>     signal that it should be placed somewhere outside of the JVMS,
>     such as in a Leyden-specific mechanism (a preload list) produced
>     in a way decoupled from any transactions between the JLS and JVMS.
>
>     On 1 Jun 2023, at 11:24, Dan Smith wrote:
>
>             On Jun 1, 2023, at 10:53 AM, Dan Heidinga
>             <heidinga at redhat.com> wrote:
>
>             A couple of questions about the spec for the Preload
>             attribute[0]. The current spec says it indicates "certain
>             classes contain information that may be of interest during
>             linkage."
>
>             The Preload attribute removes one need for Q modifiers
>             while allowing calling convention optimizations and layout
>             decisions to be made early.
>
>             The current spec is quite vague on what classes should be
>             included in the attribute and on when / what the VM will
>             do with those classes (or even if it does anything).
>
>         FWIW, the JEP has more detail about when javac is expected to
>         include classes in Preload.
>
>             I think it's time to tighten up the spec for Preload
>             attribute and specify:
>             * what the VM will do with classes listed in the attribute
>
>         It is intentional that the VM may choose to do nothing. So
>         anything it does is purely an optimization.
>
>     Looks like a nop…
>
>     (In particular, it should not /reject/ any inputs, because that
>     would destabilize separate compilability in unpredictable ways.)
>
>             * when those classes will be loaded (ie: somewhere in JVMS
>             5.3)
>
>         If the VM chooses to load Preload classes, then our thinking
>         was that JVMS 5.4 already describes the details of timing:
>
>         https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-5.html#jvms-5.4
>
>         So, for example, "Alternatively, an implementation may choose
>         an "eager" linkage strategy, where all symbolic references are
>         resolved at once when the class or interface is being
>         verified." That is, the Preload classes could all be loaded
>         during verification, or at some other stage of linking.
>
>         My expectation is that the natural point for processing
>         Preload is during preparation as vtables are set up, but
>         sometimes I get these things wrong. :-)
>
>     Sometimes you want them early (for instance layout) and sometimes
>     you need to wait (vtable layout or even just before <clinit>).
>
>             * how invalid cases are handled, including circularities
>             (Class A's Preload mentions B <: A)
>
>     Silent supression of errors, if any. Again, like a nop…
>
>         "Errors detected during linkage are thrown at a point in the
>         program where some action is taken by the program that might,
>         directly or indirectly, require linkage to the class or
>         interface involved in the error."
>
>         I've always found this rule super vague, but I think "require"
>         is the key word, and implies that errors caused by Preload
>         resolution should just be ignored. (Because Preload isn't
>         "required" to be processed at all.)
>
>             * what types of classes can be listed (any? only values?)
>
>         Definitely intend to support any classes of interest. Say a
>         future optimization wants to know about a sealed
>         superinterface, for example—it would be fine to tweak javac to
>         add that interface to Preload, and then use the information to
>         facilitate the optimization.
>
>         There's a lot of nondeterminism here—can a compliant system
>         trigger changes to class loading timing, but just on my
>         birthday?—but I think it's within the scope of JVMS 5.4, which
>         provides a lot of latitude for loading classes whenever it's
>         convenient.
>
>             It probably makes sense to start from the current Hotspot
>             handling of the attribute and fine tune that into the spec?
>
>         So I've outlined our hands-off stake in the ground above. The
>         spec would definitely benefit, at least, from a non-normative
>         cross-reference to 5.4 and short explanation. Beyond that, I
>         think we'd be open to specifying more if we can agree
>         something more is needed...
>
>     I think we could get the benefits in Fred’s prototype (as he
>     describes) with a list that is decoupled from any particular class
>     file, and Leyden could deliver this list.
>
>     As you see, I’m kind of sour on a Preload attribute these days.
>