<div dir="ltr"><div dir="ltr">Hi Mark,<br><br>Thanks for posting this document.  It provides a clear starting point for us to move forward to start to address Leyden.<br><br>A few questions based on my read through:<br><br>> As long as a condenser preserves program meaning and does not impose constraints<br>> other than those accepted by the developer, an implementation has wide latitude to<br>> optimize the result.<br><br>Does “an implementation” refer only to the JDK or are other parts of the ecosystem - frameworks, libraries, etc - able to add their own condensers as well?<br><br>> If a developer chooses condensers that shift sufficient computation from run time to<br>> earlier phases — which may require accepting many constraints — then a conforming<br>> Java implementation could even produce a fully-static platform-specific executable.<br><br>Great to read this!  Especially in light of the recent announcement around GraalCE moving under the OpenJDK umbrella, this provides wide latitude to use something like Graal’s native image as a final condenser.<br><br>> In Project Leyden we’ll explore additional techniques for shifting computation, and<br>> where necessary we’ll evolve the Platform Specification to accommodate them so<br>> that shifting computation preserves a program’s meaning. <br><br>+1 to preserving meaning!  The developer indicating what they want - ie: when something should be initialized - is key as only the developer knows the intent behind their code.<br><br>> Some of these techniques might not require any specification changes, e.g.,<br>> expanding dynamic-proxy call sites into ordinary bytecode prior to run time. <br><br>My experiments in this area have shown that the specification doesn’t need to change, but that there are user-visible changes when doing this (ie: Class:getNestMembers and others).  Is there an intention to document the user visible aspects of changes from Condensers?<br><br>> Others will definitely require specification changes, e.g., resolving classes prior to run<br>>  time. Yet others will take the form of new platform features that allow developers to<br>> express temporal shifting directly in source code, e.g., lazy static final fields.<br><br>Glad to hear that language changes are in the scope of this proposal.  Helping developers say what they mean makes it easier to reason about what needs to change versus trying to impose new semantics on top of the soup that is <clinit>.<br><br>> So let’s generalize, and allow an arbitrary number of phases in which time-shifting<br>> transformations and related optimizations can be applied.<br><br>To confirm: this is saying that a “condensed” Java application may act as an input to a later phase of “condensation”?  <br><br>> Condensation is meaning preserving.<br><br>Have you given thought to precisely specifying and then validating this property?  It’s definitely something we want but it may be challenging to enforce….<br><br>> To ensure that condensers run code correctly, and transform and constrain code<br>> only in ways that preserve meaning, we must add the concept of condensers to<br>> the Java Platform Specification.<br><br>I’m unclear reading this if the set of Condensers will be limited to what an implementation chooses to provide or if others (frameworks) can provide their own Condensers as well?<br><br>Currently, implementing a jlink plugin from outside the platform is a pain (though possible with enough –add-opens and reflective hacks) but I’d prefer to see Condensers have a more supported api so the ecosystem can extend the concept.<br><br>> We can, however, enable other Java implementations (e.g., some future version<br>> of the GraalVM native-image tool) to do so.<br><br>This is prescient given the recent announcement that Graal CE is moving to OpenJDK =)<br><br>> Eliminate apparently-unused classes and class members (i.e., stripping, which<br>> requires the constraint that selected classes and members cannot be reflected upon)<br><br>Being slightly pedantic, it means the removed members can’t be reflected on, correct?  A class that’s been stripped of unused methods / fields can still have its remaining members reflectively looked up is my assumption.<br><br>> jlink<br><br>Using jlink is the natural starting point for this work.  It would be unfortunate if condensers were limited to only work on modules given the (unfortunately) slow update of them.  Is the intention to extend jlink to work with classpath entities (ie: non-modular code) as well?  We foresee the need for condensers to be able to “condense” non-modules as well.<br><br>We’re excited to start working with you on this approach.  When do you think we’d be ready to create a Leyden repo and start developing the code for this approach?<br><br>Thanks,<br>–Dan<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 13, 2022 at 1:56 PM Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@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">For a few months now I’ve been pondering, and brainstorming with a few<br>
of you, how best to frame the work of Project Leyden conceptually.<br>
Here’s my proposal:<br>
<br>
  <a href="https://openjdk.org/projects/leyden/notes/02-shift-and-constrain" rel="noreferrer" target="_blank">https://openjdk.org/projects/leyden/notes/02-shift-and-constrain</a><br>
<br>
Short summary:<br>
<br>
  The goal of Project Leyden is to improve the startup time, time to<br>
  peak performance, and footprint of Java programs.  In this note we<br>
  propose to work toward that goal by extending the Java programming<br>
  model with features for _selectively shifting and constraining<br>
  computation_ by means of _condensing code_.  We also propose an<br>
  initial research and development roadmap.<br>
<br>
Comments, questions, and suggestions welcome!<br>
<br>
- Mark</blockquote></div>