<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 8, 2023 at 12:44 PM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8 Jun 2023, at 9:01, Dan Heidinga wrote:<br>
<br>
> If we decouple the list of preloadable classes from the classfile, how<br>
> would non-jdk classes be handled?> What if instead of ditching the attribute, or treating it like an<br>
> optimization, we firmed up the contract and treated it as a guarantee…<br>
<br>
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.<br>
<br>
A module would document, in one mplace, which types it would “prefer” to preload in order to optimize its APIs (internal or external).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Is there a natural trigger or way to limit the preloads to what I might use with the per-module file?</div><div><br></div><div>--Dan</div></div></div>