Preload attribute

[John Rose]

On 8 Jun 2023, at 9:52, Dan Heidinga wrote:

> On Thu, Jun 8, 2023 at 12:44 PM John Rose <john.r.rose at oracle.com> 
> wrote:
>
>> On 8 Jun 2023, at 9:01, Dan Heidinga wrote:
>>
>>> If we decouple the list of preloadable classes from the classfile, 
>>> how
>>> would non-jdk classes be handled?> What if instead of ditching the
>> attribute, or treating it like an
>>> optimization, we firmed up the contract and treated it as a 
>>> guarantee…
>>
>> If we go down this route, let’s consider putting the control 
>> information
>> into a module file (only) for starters.  (Maybe class file later if
>> needed.)  There would be fewer states to document and test, since (by
>> definition) class files could not get out of sync.
>>
>> A module would document, in one mplace, which types it would 
>> “prefer” to
>> preload in order to optimize its APIs (internal or external).
>>
>
> This might lead to more class loading than intended.  The current 
> approach
> has each classfile register the list of classes it wants preloaded to 
> get
> the best linkage which means we only have to load those classes if we 
> link
> the original class.  There's a natural trigger for the preload and a
> limited set of classes to load.

There’s a spectrum of tradeoffs here:  We could put preload attributes 
on every method and field, to get the maximum amount of fine-grained 
lazy (pre-)loading, or put them in a global file per JVM instance.  The 
more fine-grained, the harder it will be to write compliance testing, I 
think.

> Moving to a single per-module list loses the natural trigger and may
> pre-load more classes than the application will use.  If Module A has
> classes {A, B, C} and each one preloads 5 separate classes, with a
> per-module list that's forcing the loading of 15 additional classes 
> (plus
> supers, etc).  With a per-class list, we only preload the classes on a
> per-use basis.  More of a pay for what you use model.
>
> Is there a natural trigger or way to limit the preloads to what I 
> might use
> with the per-module file?

That’s a very good question.  I think what Preload *really is* is a 
list of “names that may require special handling before using in 
APIs”.  They don’t need to be loaded when the preload attribute is 
parsed; they are simply put in a “watch list” to trigger additional 
loading *when necessary*.  (This is already true.)  So I think if we 
move the preload list to (say) the module level (if not a global file), 
then the JVM will have its watch list.  (And, in fewer chunks than if we 
put all the stuff all the time redundantly in all class files that might 
need them:  That requires frequent repetition.)  The JVM can use its 
watch list as it does today, with watch lists populated separately for 
each class file.

To emphasize:  A watch list does not require loading.  It means, “if 
you see this name at a point where you could use extra class info, then 
I encourage you to load sooner rather than later”.  The only reason it 
is “a thing” at all is that the default behavior (of loading either 
as late as possible, or as part of a CDS-like thingy) should be changed 
only on an explicit signal.

And, hey, maybe CDS is all the primitive we need here:  Just run -Xdump 
with all of your class path loaded.  Et voila, no Preload at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230608/dc98de66/attachment.htm>