<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 14, 2023 at 2:56 AM <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</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"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><hr id="m_1930287104446017268zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Dan Heidinga" <<a href="mailto:heidinga@redhat.com" target="_blank">heidinga@redhat.com</a>><br><b>To: </b>"Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>><br><b>Cc: </b>"Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>, "John Rose" <<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>>, "daniel smith" <<a href="mailto:daniel.smith@oracle.com" target="_blank">daniel.smith@oracle.com</a>>, "valhalla-spec-experts" <<a href="mailto:valhalla-spec-experts@openjdk.java.net" target="_blank">valhalla-spec-experts@openjdk.java.net</a>><br><b>Sent: </b>Tuesday, June 13, 2023 5:10:07 PM<br><b>Subject: </b>Re: Preload attribute<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 13, 2023 at 10:13 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</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"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br><br><hr id="m_1930287104446017268m_-9104759314930602961zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Dan Heidinga" <<a href="mailto:heidinga@redhat.com" target="_blank">heidinga@redhat.com</a>><br><b>To: </b>"Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>><br><b>Cc: </b>"John Rose" <<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>>, "daniel smith" <<a href="mailto:daniel.smith@oracle.com" target="_blank">daniel.smith@oracle.com</a>>, "valhalla-spec-experts" <<a href="mailto:valhalla-spec-experts@openjdk.java.net" target="_blank">valhalla-spec-experts@openjdk.java.net</a>><br><b>Sent: </b>Tuesday, June 13, 2023 3:31:24 PM<br><b>Subject: </b>Re: Preload attribute<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023 at 10:44 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@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">
<div>
<font size="4"><font face="monospace">As a reminder, Leyden will
give us a more general tool for "moving stuff around" at build
time than CDS does, and that the current CDS behavior may well
be folded into a set of condensers. <br><br>
We are trying to find the "perfect" place to put preload
information, but we have (as usual) an overconstrained notion of
perfection; what makes perfect sense for semantics or
non-duplication may not make perfect sense for runtime behavior.<br><br>
Leyden will let us cut this knot by letting us put the
information in the classfile in the semantically sensible place,
and let tooling boil it down later at pre-deployment time to a
representation that is more efficient for runtime. <br><br>
So what I suggest is focusing on capturing the source data,
which IMO seems to still be some flavor of "class/method X needs
to know more about value class V before making certain
decisions". Preloading is the mechanism of how we find out that
"more", and aggregated representations such as per-module / CDS
archives are a rearranging of the source data to achieve a more
runtime friendly representation _for a particular configuration
of classes_. <br><br>
tl;dr: Let's design what captures the semantics we need, and
treat computing e.g. optimal load order as a downstream
transformation. </font></font></div></blockquote><br><div>That sounds reasonable. </div><br><div>I think my original question about how the JVMS treats preload still needs to be addressed though. What guarantees / requirements should we impose on the JVM's handling of preload? The current spec is not clear enough for users to understand what they get from it and is too clever in handing off loading rules to JVMS 5.4's flexibility.</div><br><div>My current position is we need to specify the behaviour and the point in the loading process where the preload attempts will occur so users can depend on the behaviour. From John's emails, I think he would prefer to see preload become strictly an optimization and be outside the spec (John correct me if I've misstated).</div></div></div></blockquote><br><div>I'm on John side, if the VM never report if an error occurs when the Preload attribute is read, the user has no side effect to see when the attribute is read, so there is no need to specify the exact point where this attribute is read.<br></div></div></div></div></blockquote><br><div>Preload attempts to load the class which does cause user visible side effects - ClassLoader::loadClass is called for one which users can observe in a number of ways. JVMTI can expose this info as can j.l.instrument.Instrumentation::getInitiatedClasses(ClassLoader) & :getAllLoadedClasses(). I'm sure there are other ways as well.</div><br><div>My point being it is observable so we should specify it clearly.</div></div></div></blockquote><div><br></div><div>Observability of classloading is an issue that Leyden has to handle, the Preload attribute is just an instance of that issue.<br></div></div></div></div></blockquote><div><br></div><div><div>Remi, we (the Valhalla EG) don't get to design Leyden's solutions. We need to work within the JVMS or extend it in ways that are appropriate for supporting our efforts. Let's let the Leyden folks solve Leyden problems =)</div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><div></div><div>For me, until a class must be initialized, the VM is free to initiate a class loading before that point, if the exception is delayed to only appear at that point.<br></div></div></div></div></blockquote><div><br></div><div>The spec gives us a lot of leeway on when classes are loaded provided errors are reported at the correct time. One of the major strengths of Java is the specifications and the guarantees they provide to our users. Those guarantees constrain what we JVM implementers can do but they also provide guide rails for framework authors and app developers to know what behaviour they can rely on from the JVM. When we get too "cute" or clever in our application of the freedoms in the spec, we undermine those guarantees our users need. And we undermine the value of what we're providing.</div><div><br></div><div>Preload as an optimization has been a great model for us to get to where we are today - Q's removed while still getting the calling convention optimizations for values. Who would have thought we'd get here given where we started? But it's a model that we need to thank for its service and wish it well Marie Kondo-style.</div><div><br></div><div>Now we need to spec the behaviour so users can rely on it or they will try to reverse engineer rules from today's behaviour that constrains us in the future. Better to author the rules we want than to be constrained by past's that's-how-it-happened-to-work behaviour.</div><div><br></div><div>--Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><div></div><div><br></div><div>Rémi<br></div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><br><div>--Dan</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><br><div>--Dan</div></div></div></blockquote><br><div>Rémi<br></div><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="4"><font face="monospace"><br></font></font><br>
<div>On 6/12/2023 9:26 AM, Dan Heidinga
wrote:<br>
</div>
<blockquote>
<div dir="ltr">
<div dir="ltr">
<div>The top-line goal for the preload efforts is to trigger
the necessary "go and look" behaviour to support calling
convention flattening for values. We want the broadest,
most reliable mechanism to ensure that we routinely get
flattening in the calling convention for value types so that
the flattening horizon can extend beyond a single compiled
body (ie: a method and its inlines).</div>
<div><br>
</div>
Summarizing the options presented so far:
<div><br>
</div>
<div>A) Value classes should be put into the CDS archive to
ensure they are loaded early enough, in a group, and in a
form that the VM can quickly discover whether calling
convention optimizations apply to them. This involves
either a class list to create a static archive (allows jdk
classes) or using a dynamic archive with AppCDS. Both cases
require a "cold run" to generate the data needed for CDS and
only capture classes that have been loaded during that run
(I think that's correct?).</div>
<div><br>
</div>
<div>B) Use a "Watch List" to list class names that should be
looked for. When the name appears, trigger loading early
enough to allow calling convention optimizations to apply.
Name conflicts are "safe" as the worst case is a class is
loaded early in multiple loaders but is only a value in one
loader. The watch list can be: global or per-module. It's
possible a tool like jlink or jmod could be used to generate
the watch list by scanning all the classes included in the
jimage/jmod file.</div>
<div><br>
</div>
<div>C) The per-class preload attribute. Each class lists the
value classes it may reference to ensure they are loaded
early enough. Potentially a lot of duplication as each
class in an application would list many of the same value
classes.</div>
<div><br>
</div>
<div>Did I miss any?</div>
<div><br>
</div>
<div>There's also another dimension we've touched on: how
eager is eager loading. Current preload behaviour is to
batch load all the listed classes. Alternatively, loading
could wait until one of the classes was observed in method
signature / field signature and load on an as-needed basis.</div>
<div><br>
</div>
<div>We've mostly concentrated on preload as an optimization
for calling conventions but there may be other uses of the
mechanism as well. A user may want to ensure that classes
are loaded early to prevent optimizations that need to be
walked back later based on their knowledge of application
behaviour. For example, ensuring there is always more than
a single implementor of an interface loaded to prevent CHA
optimizations on some critical path where the second
implementation is normally loaded late. Or to ensure an
entire sealed hierarchy is loaded together. I haven't put
much thought into this yet but expect users will find
interesting ways to use "preload" if it's reliable enough
for them. (And of course, some will abuse it in ways that
hurt their performance as well).</div>
<div><br>
</div>
<div>Which of these options meets the goal ("reliable, routine
calling convention optimization for values") best?</div>
<div><br>
</div>
<div>--Dan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jun 9, 2023 at
9:38 PM John Rose <<a href="mailto:john.r.rose@oracle.com" target="_blank">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">
<div>
<div style="font-family:sans-serif">
<div style="white-space:normal">
<p dir="auto">On 9 Jun 2023, at 12:41, Dan Heidinga
wrote:</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">On Thu, Jun 8, 2023 at 4:51 PM John
Rose <<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>>
wrote:</p>
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">On 8 Jun 2023, at 9:52, Dan Heidinga
wrote:</p>
<p dir="auto">On Thu, Jun 8, 2023 at 12:44 PM John
Rose <<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>>
wrote:</p>
<p dir="auto">On 8 Jun 2023, at 9:01, Dan Heidinga
wrote:</p>
<p dir="auto">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</p>
<p dir="auto">attribute, or treating it like an</p>
<p dir="auto">optimization, we firmed up the
contract and treated it as a guarantee…</p>
<p dir="auto">If we go down this route, let’s
consider putting the control information
<br>
into a module file (only) for starters. (Maybe
class file later if
<br>
needed.) There would be fewer states to document
and test, since (by
<br>
definition) class files could not get out of
sync.</p>
<p dir="auto">A module would document, in one
mplace, which types it would “prefer” to
<br>
preload in order to optimize its APIs (internal
or external).</p>
<p dir="auto">This might lead to more class
loading than intended. The current approach
<br>
has each classfile register the list of classes
it wants preloaded to get
<br>
the best linkage which means we only have to
load those classes if we link
<br>
the original class. There's a natural trigger
for the preload and a
<br>
limited set of classes to load.</p>
<p dir="auto">There’s a spectrum of tradeoffs
here: We could put preload attributes on
<br>
every method and field, to get the maximum
amount of fine-grained lazy
<br>
(pre-)loading, or put them in a global file per
JVM instance. The more
<br>
fine-grained, the harder it will be to write
compliance testing, I think.</p>
</blockquote>
<p dir="auto">Agreed. There's a sweet spot between
expressiveness and overheads
<br>
(testing, metadata, etc). Classfiles have
historically been the place
<br>
where the JVM tracks this kind of information as
that fits well with
<br>
separate compilation and avoids the "external
metadata" problems of ie:
<br>
GraalVM's extra-linguistic configuration files.</p>
<p dir="auto">When compiling the current class,
javac already requires directly
<br>
referenced classes to be findable and thus has the
info required to write a
<br>
preload attribute. Does javac necessarily have the
same info when
<br>
compiling the module-info classfile? Maybe when
finding the non-exported
<br>
packages for the module javac (or jlink? or jmod?)
could also find the
<br>
value classes that need preloading?</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">That is what I am assuming. The module
file would be edited by those guys. Or (maybe
better) a plain flat textual list is put somewhere
the JVM can find it.</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">Moving it into a separate pass like
this doesn't feel like quite the right
<br>
fit though as it excludes the classpath and
complicates the other tools
<br>
processing of the modules.</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">I think it’s better than that. When we
are assembling a program (jlink or a Leyden
condenser), the responsibility of publicizing value
classes (for Preload) surely belongs to the
declaration, not collectively on all the uses.</p>
<p dir="auto">So every module (jmod or whatever) that
declares 1 or more value classes (if they are
exported, at least) should list them on a publicized
watch list.</p>
<p dir="auto">There is no need to replicate these
watch lists across all potential API clients of a
value class. There are reasons <em>not</em> to do
this, since the clients have only partial,
provisional information about the values.</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">Moving to a single per-module list
loses the natural trigger and may
<br>
pre-load more classes than the application will
use. If Module A has
<br>
classes {A, B, C} and each one preloads 5
separate classes, with a
<br>
per-module list that's forcing the loading of 15
additional classes (plus
<br>
supers, etc). With a per-class list, we only
preload the classes on a
<br>
per-use basis. More of a pay for what you use
model.</p>
<p dir="auto">Is there a natural trigger or way to
limit the preloads to what I might
<br>
use
<br>
with the per-module file?</p>
<p dir="auto">That’s a very good question. I think
what Preload *really is* is a list
<br>
of “names that may require special handling
before using in APIs”. They
<br>
don’t need to be loaded when the preload
attribute is parsed; they are
<br>
simply put in a “watch list” to trigger
additional loading *when
<br>
necessary*. (This is already true.) So I think
if we move the preload
<br>
list to (say) the module level (if not a global
file), then the JVM will
<br>
have its watch list. (And, in fewer chunks than
if we put all the stuff all
<br>
the time redundantly in all class files that
might need them: That requires
<br>
frequent repetition.) The JVM can use its watch
list as it does today, with
<br>
watch lists populated separately for each class
file.</p>
</blockquote>
<p dir="auto">I initially thought a global list
would lead to issues if two different
<br>
classloaders defined classes of the same name but
since this is a "go and
<br>
look" signal, early loading based on name should
be fine even in that case
<br>
as each loader that mentions the name would be
asked to be asked to load
<br>
their version of the named class. So I think a
per-JVM list would be OK
<br>
from that perspective (though I still don't like
it).</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">Agreed.</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">To emphasize: A watch list does not
require loading. It means, “if you see
<br>
this name at a point where you could use extra
class info, then I encourage
<br>
you to load sooner rather than later”. The only
reason it is “a thing” at
<br>
all is that the default behavior (of loading
either as late as possible, or
<br>
as part of a CDS-like thingy) should be changed
only on an explicit signal.</p>
</blockquote>
<p dir="auto">While true for what the JVM needs,
this is hard behaviour to explain to
<br>
users and challenging for compliance test writers
(or maybe not if we
<br>
continue to treat preload as an optimization).</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">I’m trying to reduce this to a pure
optimization. In that case, “watch lists” are just
helpers, which are allowed to fail, and allowed to
be garbage.</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">Is this where we want to
<br>
spend our complexity budget?</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">(No, hence it should be an
optimization.)</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">Part of why I'm circling back to
treating
<br>
preload as a per-classfile attribute that forms a
requirement on the VM
<br>
rather than as an optimization is that the model
becomes clearer for users,
<br>
developers and testers.</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">I think it’s still going to be murky.
Why is putting the watch list on the API clients
better than putting it on (or near) the value class
definitions?</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">And, hey, maybe CDS is all the
primitive we need here: Just run -Xdump
<br>
with all of your class path loaded. Et voila, no
Preload at all.</p>
</blockquote>
<p dir="auto"> Users may find this behaviour
surprising - I ran with a CDS archive and my
<br>
JVM loaded classes earlier than it would have
otherwise?</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">CDS has the effect of making class
loading in a more timely fashion, and (under Leyden)
will almost certainly trigger reordering of loading
as well. So promulgating a “watch list” has goals
which align with CDS.</p>
<p dir="auto">I’m starting to think that the right
“level” to pull for optimizing value-based APIs is
to put the value classes in a CDS archive. That is a
defacto watch list. The jlink guy should just make a
table of all value classes. That’s the best form of
Preload I can imagine, frankly.</p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div></blockquote></div></div></div></blockquote></div></div><br></blockquote></div></div></div></blockquote></div></div>