Preload attribute

[Dan Heidinga]

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.

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?

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230608/48acc497/attachment.htm>