Selectively Shifting and Constraining Computation

[Dan Heidinga]

Hi Mark,

Thanks for posting this document.  It provides a clear starting point for
us to move forward to start to address Leyden.

A few questions based on my read through:

> As long as a condenser preserves program meaning and does not impose
constraints
> other than those accepted by the developer, an implementation has wide
latitude to
> optimize the result.

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?

> If a developer chooses condensers that shift sufficient computation from
run time to
> earlier phases — which may require accepting many constraints — then a
conforming
> Java implementation could even produce a fully-static platform-specific
executable.

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.

> In Project Leyden we’ll explore additional techniques for shifting
computation, and
> where necessary we’ll evolve the Platform Specification to accommodate
them so
> that shifting computation preserves a program’s meaning.

+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.

> Some of these techniques might not require any specification changes,
e.g.,
> expanding dynamic-proxy call sites into ordinary bytecode prior to run
time.

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?

> Others will definitely require specification changes, e.g., resolving
classes prior to run
>  time. Yet others will take the form of new platform features that allow
developers to
> express temporal shifting directly in source code, e.g., lazy static
final fields.

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>.

> So let’s generalize, and allow an arbitrary number of phases in which
time-shifting
> transformations and related optimizations can be applied.

To confirm: this is saying that a “condensed” Java application may act as
an input to a later phase of “condensation”?

> Condensation is meaning preserving.

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….

> To ensure that condensers run code correctly, and transform and constrain
code
> only in ways that preserve meaning, we must add the concept of condensers
to
> the Java Platform Specification.

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?

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.

> We can, however, enable other Java implementations (e.g., some future
version
> of the GraalVM native-image tool) to do so.

This is prescient given the recent announcement that Graal CE is moving to
OpenJDK =)

> Eliminate apparently-unused classes and class members (i.e., stripping,
which
> requires the constraint that selected classes and members cannot be
reflected upon)

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.

> jlink

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.

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?

Thanks,
–Dan



On Thu, Oct 13, 2022 at 1:56 PM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> For a few months now I’ve been pondering, and brainstorming with a few
> of you, how best to frame the work of Project Leyden conceptually.
> Here’s my proposal:
>
>   https://openjdk.org/projects/leyden/notes/02-shift-and-constrain
>
> Short summary:
>
>   The goal of Project Leyden is to improve the startup time, time to
>   peak performance, and footprint of Java programs.  In this note we
>   propose to work toward that goal by extending the Java programming
>   model with features for _selectively shifting and constraining
>   computation_ by means of _condensing code_.  We also propose an
>   initial research and development roadmap.
>
> Comments, questions, and suggestions welcome!
>
> - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221021/b1f3c632/attachment.htm>