Preload attribute

Frederic Parain frederic.parain at oracle.com
Thu Jun 1 18:34:57 UTC 2023


The current support of the PreLoad attribute in HotSpot is very lenient:

   - the VM tries to load all classes listed in the attribute, there's 
no attempt to check if a listed class is used in the declaration of a 
field or as the type of a method argument or return value

   - the VM tries to load those classes at link time (after linking of 
super-interfaces, before verification), but this timing is constrained 
by some HotSpot internal designs, timing could be different on another VM

   - all error/exceptions thrown during an attempt to load one of those 
classes is caught and discarded (silent failure)

   - if the loading is successful, there's no check that the class is a 
value class. It could be an identity class or an interface


AFAICT, this implementation matches Dan Smith's answers to your questions.


Fred


On 6/1/23 1:53 PM, Dan Heidinga 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).  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
> * when those classes will be loaded (ie: somewhere in JVMS 5.3)
> * how invalid cases are handled, including circularities (Class A's 
> Preload mentions B <: A)
> * what types of classes can be listed (any? only values?)
>
> And there's probably other issues to clarify.  Otherwise, the current 
> spec isn't clear enough for users to know when to add a class, how it 
> will be treated, and any potential edge cases to avoid.
>
> It probably makes sense to start from the current Hotspot handling of 
> the attribute and fine tune that into the spec?
>
> --Dan
>
> [0] 
> https://cr.openjdk.org/~dlsmith/jep401/jep401-20230404/specs/value-objects-jvms.html#jvms-4.7.31


More information about the valhalla-spec-observers mailing list