<div dir="ltr"><div dir="ltr">On Mon, Jan 23, 2023 at 3:22 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><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">Do you have any data on the
relative distribution of the three buckets? </font></font></div></blockquote><div><br></div><div>That's a great question but one I don't have a clear answer for. Here's what I can provide though.</div><div><br></div><div>Our investigations have primarily focused on shifting class initialization to occur at build time with a goal of shifting all of it there. With the qbicc efforts, it's still early but we've only had to add ~15 classes to the "reinitialize" bucket so far when bringing up a "hello world" style Quarkus application. Many of the cases that need to be adapted are fairly straightforward capturing things like the Runtime::availableProcessors, environment variables, file descriptors for std{out/err/in}, page sizes, etc. Others are more complicated but of a similar build time vs runtime env capture in classes like sun.security.provider.SeedGenerator.</div><div><br></div><div>That implies a fairly small number of classes in the reinitialize bucket compared to the large number in the build time bucket. We don't really have a runtime bucket in qbicc by design.</div><div><br></div><div>Graal's JDKInitializationFeature [0] is a great place to look for the divide between build / runtime / reinit in JDK classes as a baseline with the Substitutions providing fixups / workarounds. Most JDK classes are build time as set by the package, a smaller number of classes (a handfull?) are runtime, and 20ish classes are set to be reinitialized in the Feature. The caveat being that there is a large set of Substitutions, each created for various reasons. Finding the reasons for most substitutions is a time consuming effort given the little detail in the github history. Some are essential, others are performance or footprint optimizations, others adapt to the class loading model in Graal. Again not a perfect proxy for Leyden.<br></div><div><br></div><div>My impression is most classes have very simple static initializers that are either empty or define some primitive (or String) constants. They can be freely shifted around. It's the smaller set that create Threads, cache environment variables / system defines, or allocate Objects that depend on a class that does one of these things that become problematic. </div><div><br></div><div>--Dan</div><div><br></div><div>[0] <a href="https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/jdk/JDKInitializationFeature.java">https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/jdk/JDKInitializationFeature.java</a></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><font size="4"><font face="monospace"> </font></font><br>
<br>
<div>On 1/23/2023 1:50 PM, Dan Heidinga
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Picking up on the Class Init discussion from before
the holidays, here's the next piece looking at how static fields
can be characterized:
<div><br>
</div>
<div>The next major step in our investigation was to try to
replace the GraalVM Substitutions with the IODH pattern. Our
assumption at the time was that we could group class
initializations into two buckets - one for build time init and
one for runtime init.</div>
<div><br>
</div>
<div>Unfortunately, as we worked on adapting the Substitutions,
we found that a third bucket needed to be introduced. This is
the "reinitialize bucket" for classes that needed to be
initialized at build time and then reinitialized at runtime as
they hold values that are specific to the current system.</div>
<div><br>
</div>
<div>Classes also unfortunately don't neatly stay in one
bucket. Many of the classes in the "runtime init" bucket can
be dragged into the "reinitialize" bucket if their
initialization is triggered by a use in the "build time init"
bucket. </div>
<div><br>
</div>
<div>The characterization of a given class is often
application-specific - in *this* app, class Foo can be runtime
initialized but in *that* app Foo needs to be reinitialized.</div>
<div><br>
</div>
<div>Here's an example that shows how the runtime bucket can
easily be moved to the reinitialization bucket:</div>
<div><br>
</div>
<div>java.nio.Bits has fields, like PAGE_SIZE, which can be
converted to use the IODH pattern provided the IODH helper
class is only initialized at runtime. If it is initialized
earlier (ie: build time), then it must be in the
reinitialization bucket. Any value that is calculated from
PAGE_SIZE may also need to be reinitialized. </div>
<div><br>
</div>
<div>Alternatively, some kind of constraint that prevents the
app from running could be registered that ensures the page
size is consistent between build and runtime envs.</div>
<div><br>
</div>
<div>Bits also has fields like COUNT which represents the number
of reserved direct memory allocations. This field (and
related fields) could be grouped into an IODH helper class but
has the same characteristics as PAGE_SIZE in that it belongs
in the "runtime" bucket but may be dragged into the
"reinitialization" bucket by build time use. (ie: a library
used at build time that temporarily creates a DirectByteBuffer
to speed up processing of some json file and then discards the
DBB. Initialization of Bits' IODH helper will still have
occurred).</div>
<div><br>
</div>
<div>Similarly we may need constraints (or raise errors?) if
COUNT is non-zero when transitioning from between phases
(build -> runtime).</div>
<div><br>
</div>
<div>See appendix B [0] for more examples.</div>
<div><br>
</div>
<div>The use of the IODH pattern to group static fields provides
two benefits:</div>
<div>1) it group fields having similar lifetimes together and
allows them to benefit from delayed initialization (ie: init
groups rather than all fields)</div>
<div><br>
</div>
<div>2) It makes it easier to reset the fields as smaller
groupings are being reset (smaller blast radius).</div>
<div><br>
</div>
<div>The IODH pattern doesn't help to define the constraints
under which a class may be reused as we still need developer
intent to be expressed to know what are the constraints. </div>
<div><br>
</div>
<div>It also doesn't help to track the uses of the fields in the
IODH helper class as once they've been read and used, the
dependency information is lost.</div>
<div><br>
</div>
<div>It's still a useful tool, but doesn't solve all use cases.</div>
<div><br>
</div>
<div>--Dan</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a href="http://cr.openjdk.java.net/~heidinga/leyden/ClassInitPlan.pdf" target="_blank">http://cr.openjdk.java.net/~heidinga/leyden/ClassInitPlan.pdf</a></div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>