From sgehwolf at redhat.com  Fri Jul  7 11:40:02 2023
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 07 Jul 2023 13:40:02 +0200
Subject: jmods-less jlinking prototype
In-Reply-To: <54b562f602e428e6b2fd8f3025f863df031a986d.camel@redhat.com>
References: <5a81ad40b9b20d92a73ddedf437187c7f141f9ce.camel@redhat.com>
 <7c67f4f2-a794-8852-5aca-8bb4055803b5@oracle.com>
 <4a2cb94a868dac427e2e33997f406f599b9018f3.camel@redhat.com>
 <98802f4a-82e0-1331-cb1e-543b0b22650b@oracle.com>
 <145f250bd9b2584e27191db6939910126af6b1ff.camel@redhat.com>
 <5c157608-d4bb-9de7-a492-dc85b8b9dc9e@oracle.com>
 <54b562f602e428e6b2fd8f3025f863df031a986d.camel@redhat.com>
Message-ID: <cdfd2c31186ed24c2c659389da0c7f3db478b489.camel@redhat.com>

On Tue, 2023-06-20 at 14:16 +0200, Severin Gehwolf wrote:
> On Sat, 2023-06-17 at 17:05 +0100, Alan Bateman wrote:
> > > On 16/06/2023 13:48, Severin Gehwolf wrote:
> > > > > :
> > > > > OK. Looking at java.se I get this (the jimage ends up different, but
> > > > > that's it):
> > > > > 
> > > > > $ ./build/linux-x86_64-server-release/images/jdk/bin/jlink --add-modules java.se --output build/jmod-full-jlink-java.se --verbose
> > > > > $ ./build/linux-x86_64-server-release/images/jdk/bin/jlink --add-modules java.se,jdk.jlink --output build/jmod-less-jlink1 --verbose
> > > > > $ ./build/jmod-less-jlink1/bin/jlink --add-modules java.se --output build/jmod-less-jlink-java.se --verbose
> > > > > $ diff -r -u ./build/jmod-less-jlink-java.se/? jmod-full-jlink-java.se/
> > > > > Binary files ./build/jmod-less-jlink-java.se/lib/modules and build/jmod-full-jlink-java.se/lib/modules differ
> > > > > $ ./build/linux-x86_64-server-release/images/jdk/bin/jimage extract --dir build/jimage-java.se-jmodfull ./build/jmod-full-jlink-java.se/lib/modules
> > > > > $ ./build/linux-x86_64-server-release/images/jdk/bin/jimage extract --dir build/jimage-java.se-jmodless ./build/jmod-less-jlink-java.se/lib/modules
> > > > > $ diff -r -u build/jimage-java.se-jmodfull build/jimage-java.se-jmodless
> > > > > <nothing>
> > > > > 
> > > > > $ diff -u <(./build/linux-x86_64-server-release/images/jdk//bin/jimage info build/jmod-less-jlink-java.se/lib/modules) <(./build/linux-x86_64-server-release/images/jdk//bin/jimage info build/jmod-full-jlink-java.se/lib/modules)
> > > > > --- /dev/fd/63??2023-06-16 14:45:48.800145724 +0200
> > > > > +++ /dev/fd/62??2023-06-16 14:45:48.801145733 +0200
> > > > > @@ -5,6 +5,6 @@
> > > > > ?? Table Length:?? 19474
> > > > > ?? Offsets Size:?? 77896
> > > > > ?? Redirects Size: 77896
> > > > > - Locations Size: 391737
> > > > > + Locations Size: 391733
> > > > > ?? Strings Size:?? 446073
> > > > > - Index Size:???? 993630
> > > > > + Index Size:???? 993626
> > > > > 
> > > > > 
> > > > > So this might be a side-effect of how the jimage is serialized to disk.
> > > > > I'll keep looking but it seems the patch is already fairly close?
> > > Reproducible builds have been a bit of whack-a-mole that has included
> > > the image writer. I'm not aware of any remaining issues so what you are 
> > > seeing may be the ordering that strings are hashed or it may be be 
> > > contents (use `jimage extract --dir <dir> lib/modules` and compare).
> > > 
> 
> I've done the 'jimage extract' compare already (see above commands) and
> they're identical. So it's probably strings ordering.
> 
> > > 
> > > > > :
> > > > > I'm not sure what you mean by reconstitute the original resources?
> > > > > Could you clarify, please?
> > > > > 
> > > > > Given an unmodified JDK image, a jmod-less jlink will preserve the
> > > > > resources (doesn't change them).
> > > > > 
> > > > > Is the idea that if somebody, say changed 'conf/net.properties' a
> > > > > subsequent jmod-less jlink should fail? Something like:
> > > > > 
> > > > > T_1: jlink --add-modules ALL-MODULE-PATH --output build/jmod-less-jlink-all-mods
> > > > > T_2: Edit build/jmod-less-jlink-all-mods/conf/net.properties
> > > > > T_3: ./build/jmod-less-all-mods/bin/jlink --add-modules java.se --output build/jmod-less-modified-net
> > > > > 
> > > > > Make the jlink at time T_3 fail? Is that the idea? Something else?
> > > The SystemModulesPlugin is one of complicated plugins as it replaces 
> > > SystemModulesMap and generates classes that are specific to the set of 
> > > modules that go into the target runtime. If the linking is "as if" the 
> > > packaged modules are present then the resources that go through the 
> > > pipeline shouldn't include the generated/modified classes. If T_3 is 
> > > changed to generate a run-image with a subset of the modules then you'll 
> > > see what I mean.
> 
> OK, thanks. Noted.
> 
> > > In T_1, the target run-time image will include the jdk.jlink module. I 
> > > think that is your signal to identify the resources that have been 
> > > added, removed or modified in the plugin pipeline. There are many ways 
> > > that the diffs can be expressed and saved so that the resources in the 
> > > modules that go through the pipeline in T_3 are "as if" they came from 
> > > the packaged modules used in T_1.
> > > 
> > > A motivating example for user editable configuration is where 
> > > conf/security/java.security at T_2 is changed to allow weak crypto. 
> > > That's not something to silently propagate. It could be that T_3 fails 
> > > because the hashes don't match or it has saved the original conf resource.
> 
> OK, got it.
> 
> > > For the native libs then I think the ModuleFinder can detect that the
> > > hashes have changed. There's a choice here on whether it just warns or 
> > > fails. As you know, the only plugin that modifies native libs right now 
> > > is the debug symbol stripping. There is also the VM selection plugin but 
> > > that just works as a filter.
> 
> Sounds good. I'll go for producing warnings first.

FYI: I've moved this to:
https://bugs.openjdk.org/browse/JDK-8311302

Thanks,
Severin


From Alan.Bateman at oracle.com  Mon Jul 17 16:58:57 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jul 2023 17:58:57 +0100
Subject: jmods-less jlinking prototype
In-Reply-To: <cdfd2c31186ed24c2c659389da0c7f3db478b489.camel@redhat.com>
References: <5a81ad40b9b20d92a73ddedf437187c7f141f9ce.camel@redhat.com>
 <7c67f4f2-a794-8852-5aca-8bb4055803b5@oracle.com>
 <4a2cb94a868dac427e2e33997f406f599b9018f3.camel@redhat.com>
 <98802f4a-82e0-1331-cb1e-543b0b22650b@oracle.com>
 <145f250bd9b2584e27191db6939910126af6b1ff.camel@redhat.com>
 <5c157608-d4bb-9de7-a492-dc85b8b9dc9e@oracle.com>
 <54b562f602e428e6b2fd8f3025f863df031a986d.camel@redhat.com>
 <cdfd2c31186ed24c2c659389da0c7f3db478b489.camel@redhat.com>
Message-ID: <d984ecf1-f1e0-e097-6e61-26bf4d4dcb31@oracle.com>

On 07/07/2023 12:40, Severin Gehwolf wrote:
> :
>>>> For the native libs then I think the ModuleFinder can detect that the
>>>> hashes have changed. There's a choice here on whether it just warns or
>>>> fails. As you know, the only plugin that modifies native libs right now
>>>> is the debug symbol stripping. There is also the VM selection plugin but
>>>> that just works as a filter.
>> Sounds good. I'll go for producing warnings first.
> FYI: I've moved this to:
> https://bugs.openjdk.org/browse/JDK-8311302
>

Okay, I think we can continue the discussion there.? There are few 
aspects to this that will require discussion. For example, it might be 
better to limit this to a single hop to avoid divergence from the 
contents of the original modules, which will happen when plugins strip 
resources, e.g. --include-locales and specify a subset of the locales to 
include. Limiting it to a single hop isn't too different that not 
including the jdk.jlink module or not specifying the 
--keep-package-module to copy the packaged modules into the target 
image. I've looked at dozens of scripts that use jlink and I don't think 
I've seen usages of --keep-packages-modules so all these usages are 
already single hop. There is also the question on whether to warn or 
fail when user editable configuration has been modified. When its 
security or crypto config then it might be better to fail, so maybe that 
would be the default policy with an option to do what you have and emit 
a warning.

In passing, I think drop the phrase "jmod-less". In its place, I think 
the mental model should be that the current run-image is the last 
element in the module path, the jmods directory is the second last 
element, if that makes sense. I think you are close to that already with 
the --verbose output where a jrt URI will be printed when the module 
comes from the current run-time image.

-Alan

From mark.reinhold at oracle.com  Tue Jul 25 16:14:54 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Tue, 25 Jul 2023 16:14:54 +0000
Subject: CFV and Result: Project Leyden Committers
Message-ID: <20230725161452.CC3B664359A@eggemoggin.niobe.net>

I hereby nominate the following individuals to the Leyden Committer role:

  Alan Bateman                Dan Heidinga         John Rose
  Alex Buckley                Tobias Holenstein    Paul Sandoz
  Eric Caspole                Vladimir Ivanov      Doug Simon
  Roberto Casta?eda Lozano    Vojin Jovanovic      Dalibor Topic
  Mandy Chung                 Viktor Klang         Igor Veresov
  Maurizio Cimadamore         Vladimir Kozlov      Jorn Vernee
  Andrew Dinn                 Ioi Lam              Mikael Vidstedt
  Erik Duveblad               Jim Laskey           Roland Westrelin
  Damon Fenacci               Dean Long            Christian Wimmer
  Severin Gehwolf             Ashutosh Mehra       Thomas Wuerthinger
  Brian Goetz                 Per Minborg          Kangcheng Xu
  Ian Graves                  Erik ?sterlund       Sonia Zaldana Calles
  Christian Hagedorn          Emanuel Peter        Jiangli Zhou
  Andrew Haley                Ron Pressler
  Tobias Hartmann             Claes Redestad

Only current Leyden Committers [1] are eligible to vote on these
nominations.

I am the only Leyden Committer at present, and I hereby vote ?yes.?

Yes: 1
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [2], this is
sufficient to approve the nomination.

The Leyden development repository will be available shortly.

- Mark


[1] https://openjdk.org/census#leyden
[2] https://openjdk.org/bylaws#lazy-consensus

From mark.reinhold at oracle.com  Thu Jul 27 14:12:44 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Thu, 27 Jul 2023 14:12:44 +0000
Subject: Leyden repository open
Message-ID: <20230727141243.8DF4764398A@eggemoggin.niobe.net>

The Leyden repository (https://github.com/openjdk/leyden) is now open.

The master branch in this repository is a clone of the JDK main line
(https://github.com/openjdk/jdk).  A Skara bot regularly propagates
main-line commits to the Leyden master branch.

All Leyden Committers [1] can create new branches and push to such
branches.  Commit messages for all non-master branches will be sent
to this list.

(Please do not, under any circumstances, push to the master branch!)

If you?d like to create a new branch for collaborative prototyping work,
please send a short note to this list describing its name and intended
content.

- Mark


[1] https://openjdk.org/census#leyden

From heidinga at redhat.com  Thu Jul 27 14:34:23 2023
From: heidinga at redhat.com (Dan Heidinga)
Date: Thu, 27 Jul 2023 10:34:23 -0400
Subject: jlink: pre-generate lambda classes
In-Reply-To: <CAJq4Gi6n2i5-qK7JR2-hsBUcTtjAWK4L6rQDTpBNy9kAuZ5Gew@mail.gmail.com>
References: <CAJq4Gi6n2i5-qK7JR2-hsBUcTtjAWK4L6rQDTpBNy9kAuZ5Gew@mail.gmail.com>
Message-ID: <CAJq4Gi5Z_Yy7p88dNxZb6jWQWhCoisQdHcAMFfVOy3Q_qYzHWw@mail.gmail.com>

With Mark's announcement that the leyden repo is now open, I'd like to
refresh this request to push the experimental jlink plugin to pregenerate
lambda classes to the the repo.

> If you?d like to create a new branch for collaborative prototyping work,
> please send a short note to this list describing its name and intended
> content.

Suggested branch name: pregenerate-lambdas
Purpose: Share the jlink plugin and jdk changes required to pregenerate
lambda classes during jlink.  This branch would be an initial example of
how to address some of the issues (like nestmates) when timeshifting code
generation from runtime to jlink time.  It's also a good starting point for
further collaboration on how to best address Serializable lambdas and any
other areas (Stacktrace differences,....) that may be exposed related to
timeshifting code generation.

--Dan

On Mon, Jun 26, 2023 at 11:18?AM Dan Heidinga <heidinga at redhat.com> wrote:

> I've updated my jlink patch to pregenerate lambda classes [0] so it works
> with the current Leyden repo and the updated classfile api (which is
> awesome - check it out if you haven't yet!).  Previously discussed in the
> "Bytecode transformation investigation" thread [1].
>
> I'd like to push it to an experimental branch here on the leyden repo so
> that others can freely pick up and experiment with the code.  Would that be
> possible?
>
> My local branch is called "pregenerate-lambdas" but any name would work
> for me.
>
> The patch pre-generates during jlink time classes for non-Serializable
> lambda expressions and uses NestMates to handle access to the private
> implementation method.  It's a good example of the kinds of changes needed
> to shift runtime-generated classes to jlink time.
>
> Still lots to update but worth getting into Leyden repo so the code is
> shareable.
>
> Mark / Brian - is it possible to get an experimental branch on the leyden
> repo for this patch?
>
> --Dan
>
> [0]
> https://github.com/openjdk/leyden/compare/master...DanHeidinga:leyden:pregenerate-lambdas?expand=1
>
> [1] https://mail.openjdk.org/pipermail/leyden-dev/2022-August/000055.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/527eeb40/attachment.htm>

From mark.reinhold at oracle.com  Thu Jul 27 14:39:13 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Thu, 27 Jul 2023 14:39:13 +0000
Subject: jlink: pre-generate lambda classes
In-Reply-To: <CAJq4Gi5Z_Yy7p88dNxZb6jWQWhCoisQdHcAMFfVOy3Q_qYzHWw@mail.gmail.com>
References: <CAJq4Gi6n2i5-qK7JR2-hsBUcTtjAWK4L6rQDTpBNy9kAuZ5Gew@mail.gmail.com>
 <CAJq4Gi5Z_Yy7p88dNxZb6jWQWhCoisQdHcAMFfVOy3Q_qYzHWw@mail.gmail.com>
Message-ID: <20230727103912.73033372@eggemoggin.niobe.net>

2023/7/27 10:34:23 -0400, heidinga at redhat.com:
> With Mark's announcement that the leyden repo is now open, I'd like to
> refresh this request to push the experimental jlink plugin to pregenerate
> lambda classes to the the repo.
> 
>> If you?d like to create a new branch for collaborative prototyping work,
>> please send a short note to this list describing its name and intended
>> content.
> 
> Suggested branch name: pregenerate-lambdas
> Purpose: Share the jlink plugin and jdk changes required to pregenerate
> lambda classes during jlink.  This branch would be an initial example of
> how to address some of the issues (like nestmates) when timeshifting code
> generation from runtime to jlink time.  It's also a good starting point for
> further collaboration on how to best address Serializable lambdas and any
> other areas (Stacktrace differences,....) that may be exposed related to
> timeshifting code generation.

Dan -- thanks for your patience.

No approval is needed to create a new branch, just a clear statement of
name and intent.  Please proceed.

- Mark

From per-ake.minborg at oracle.com  Thu Jul 27 15:52:46 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Thu, 27 Jul 2023 15:52:46 +0000
Subject: Draft JEP Announcement: "Computed Constants"
Message-ID: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>

Hi all,

  Maurizio and I have drafted a JEP for computed constants, which are
  immutable value holders that are initialized at most once.  They offer
  the performance and safety benefits of final fields while offering
  greater flexibility as to the timing of initialization.  In the
  context of Leyden, they could be one basis for shifting computation
  both forward and backward in time.

  The draft is here: https://openjdk.org/jeps/8312611

  Now that the Leyden repo is open, I?ll publish the prototype code to a
  new branch there shortly.

  Comments are welcome!

  Best, Per

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/d2aad882/attachment.htm>

From forax at univ-mlv.fr  Thu Jul 27 16:09:07 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 Jul 2023 18:09:07 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>

Hello, 
Are you aware of the lazy static final fields proposal ? 
[ https://bugs.openjdk.org/browse/JDK-8209964 | https://bugs.openjdk.org/browse/JDK-8209964 ] 

In think both proposals should be merged. 

R?mi 

> From: "Per-Ake Minborg" <per-ake.minborg at oracle.com>
> To: "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Thursday, July 27, 2023 5:52:46 PM
> Subject: Draft JEP Announcement: "Computed Constants"

> Hi all,

> Maurizio and I have drafted a JEP for computed constants, which are
> immutable value holders that are initialized at most once. They offer
> the performance and safety benefits of final fields while offering
> greater flexibility as to the timing of initialization. In the
> context of Leyden, they could be one basis for shifting computation
> both forward and backward in time.

> The draft is here: [ https://openjdk.org/jeps/8312611 |
> https://openjdk.org/jeps/8312611 ]

> Now that the Leyden repo is open, I?ll publish the prototype code to a
> new branch there shortly.

> Comments are welcome!

> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/7a9cab34/attachment.htm>

From maurizio.cimadamore at oracle.com  Thu Jul 27 16:14:48 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 27 Jul 2023 17:14:48 +0100
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>

Hi Remi
Yes, of course we were aware of that.

Think of this proposal as an API-driven approach (in the style of 
ThreadLocal, ClassValue, ScopedValue, ...) which delivers more or less 
the same feature, but w/o changing the language.


One thing that's attractive about the API approach is that it is not 
limited to just static fields, but it can also work for instance fields 
as well.


(that said, I agree the two jeps should somehow be related/link to each 
other)


Maurizio


On 27/07/2023 17:09, Remi Forax wrote:
> Hello,
> Are you aware of the lazy static final fields proposal ?
> https://bugs.openjdk.org/browse/JDK-8209964
>
> In think both proposals should be merged.
>
> R?mi
>
> ------------------------------------------------------------------------
>
>     *From: *"Per-Ake Minborg" <per-ake.minborg at oracle.com>
>     *To: *"leyden-dev" <leyden-dev at openjdk.org>
>     *Sent: *Thursday, July 27, 2023 5:52:46 PM
>     *Subject: *Draft JEP Announcement: "Computed Constants"
>
>     Hi all,
>
>     ? Maurizio and I have drafted a JEP for computed constants, which are
>     ? immutable value holders that are initialized at most once.? They
>     offer
>     ? the performance and safety benefits of final fields while offering
>     ? greater flexibility as to the timing of initialization.? In the
>     ? context of Leyden, they could be one basis for shifting computation
>     ? both forward and backward in time.
>
>     ? The draft is here:https://openjdk.org/jeps/8312611
>     <https://openjdk.org/jeps/8312611>
>
>     ? Now that the Leyden repo is open, I?ll publish the prototype
>     code to a
>     ? new branch there shortly.
>
>     ? Comments are welcome!
>
>     ? Best, Per
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/65f02f0f/attachment.htm>

From brian.goetz at oracle.com  Thu Jul 27 16:23:01 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 27 Jul 2023 12:23:01 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <d8c5bd77-2a1c-a11d-cebe-53e9187c0cd7@oracle.com>

As Maurizio said, this JEP is a refinement of ideas that were initially 
explored in the "lazy statics" JEP.? In a way, this JEP reveals the 
"lazy statics" JEP as skipping a step, jumping to a language and VM when 
much of the benefit can be achieved by a libraries approach.? It is 
possible that at some point, after suitable progress and validation, we 
may decide to take the step of pushing it further into the language/VM, 
but we've made the deliberate choice to push such steps into the future.

In the meantime, there is no reason we cannot have multiple 
"inconsistent" draft or candidate JEPs, so there is no need to "merge" 
anything right now.



On 7/27/2023 12:09 PM, Remi Forax wrote:
> Hello,
> Are you aware of the lazy static final fields proposal ?
> https://bugs.openjdk.org/browse/JDK-8209964
>
> In think both proposals should be merged.
>
> R?mi
>
> ------------------------------------------------------------------------
>
>     *From: *"Per-Ake Minborg" <per-ake.minborg at oracle.com>
>     *To: *"leyden-dev" <leyden-dev at openjdk.org>
>     *Sent: *Thursday, July 27, 2023 5:52:46 PM
>     *Subject: *Draft JEP Announcement: "Computed Constants"
>
>     Hi all,
>
>     ? Maurizio and I have drafted a JEP for computed constants, which are
>     ? immutable value holders that are initialized at most once.? They
>     offer
>     ? the performance and safety benefits of final fields while offering
>     ? greater flexibility as to the timing of initialization.? In the
>     ? context of Leyden, they could be one basis for shifting computation
>     ? both forward and backward in time.
>
>     ? The draft is here:https://openjdk.org/jeps/8312611
>     <https://openjdk.org/jeps/8312611>
>
>     ? Now that the Leyden repo is open, I?ll publish the prototype
>     code to a
>     ? new branch there shortly.
>
>     ? Comments are welcome!
>
>     ? Best, Per
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/66a0e8c9/attachment.htm>

From forax at univ-mlv.fr  Thu Jul 27 16:36:00 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 27 Jul 2023 18:36:00 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
Message-ID: <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>

> From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg"
> <per-ake.minborg at oracle.com>
> Cc: "leyden-dev" <leyden-dev at openjdk.org>, "John Rose" <john.r.rose at oracle.com>
> Sent: Thursday, July 27, 2023 6:14:48 PM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

> Hi Remi
> Yes, of course we were aware of that.

> Think of this proposal as an API-driven approach (in the style of ThreadLocal,
> ClassValue, ScopedValue, ...) which delivers more or less the same feature, but
> w/o changing the language.

> One thing that's attractive about the API approach is that it is not limited to
> just static fields, but it can also work for instance fields as well.

> (that said, I agree the two jeps should somehow be related/link to each other)
I see two problems with your suggested approach: 
- this proposal is on top of lambdas, which means that it can be used for applications but not for the VM startup because it can only be used after method handles sub-system have been initialized. 
- this is not a backward compatible change, if you add a new keyword to static final fields, you can rewrite any public static final fields to a public lazy static final field, 
by example, String.CASE_INSENSITIVE_ORDER which is rarely used but can not be changed with your proposal. 

> Maurizio
R?mi 

> On 27/07/2023 17:09, Remi Forax wrote:

>> Hello,
>> Are you aware of the lazy static final fields proposal ?
>> [ https://bugs.openjdk.org/browse/JDK-8209964 |
>> https://bugs.openjdk.org/browse/JDK-8209964 ]

>> In think both proposals should be merged.

>> R?mi

>>> From: "Per-Ake Minborg" [ mailto:per-ake.minborg at oracle.com |
>>> <per-ake.minborg at oracle.com> ]
>>> To: "leyden-dev" [ mailto:leyden-dev at openjdk.org | <leyden-dev at openjdk.org> ]
>>> Sent: Thursday, July 27, 2023 5:52:46 PM
>>> Subject: Draft JEP Announcement: "Computed Constants"

>>> Hi all,

>>> Maurizio and I have drafted a JEP for computed constants, which are
>>> immutable value holders that are initialized at most once. They offer
>>> the performance and safety benefits of final fields while offering
>>> greater flexibility as to the timing of initialization. In the
>>> context of Leyden, they could be one basis for shifting computation
>>> both forward and backward in time.

>>> The draft is here: [ https://openjdk.org/jeps/8312611 |
>>> https://openjdk.org/jeps/8312611 ]

>>> Now that the Leyden repo is open, I?ll publish the prototype code to a
>>> new branch there shortly.

>>> Comments are welcome!

>>> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/13771612/attachment.htm>

From duke at openjdk.org  Thu Jul 27 16:45:53 2023
From: duke at openjdk.org (duke)
Date: Thu, 27 Jul 2023 16:45:53 GMT
Subject: git: openjdk/leyden: created branch pregenerate-lambdas based on the
 branch master containing 7 unique commits
Message-ID: <0accd469-421c-4f39-a756-b25b2bf4bc00@openjdk.org>

The following commits are unique to the pregenerate-lambdas branch:
========================================================
598d79ba: Support primitive wrapper look up with ClassDesc
72047d4b: Support type conversion on ClassDescs
d26df27d: Add BytecodeDescriptr::unparse of ClassDesc
a0623014: Convert Lambdas to non-lambda code
614ff790: Remove extraneous "Info" and use descriptorString
79047e66: Extend classfile APi for better ClassEntry lists
493d81ad: initial lambda pre-generator jlink plugin

From forax at univ-mlv.fr  Thu Jul 27 17:03:33 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 27 Jul 2023 19:03:33 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <d8c5bd77-2a1c-a11d-cebe-53e9187c0cd7@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <d8c5bd77-2a1c-a11d-cebe-53e9187c0cd7@oracle.com>
Message-ID: <2085881755.4354553.1690477413009.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg"
> <per-ake.minborg at oracle.com>
> Cc: "leyden-dev" <leyden-dev at openjdk.org>, "John Rose" <john.r.rose at oracle.com>
> Sent: Thursday, July 27, 2023 6:23:01 PM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

> As Maurizio said, this JEP is a refinement of ideas that were initially explored
> in the "lazy statics" JEP. In a way, this JEP reveals the "lazy statics" JEP as
> skipping a step, jumping to a language and VM when much of the benefit can be
> achieved by a libraries approach. It is possible that at some point, after
> suitable progress and validation, we may decide to take the step of pushing it
> further into the language/VM, but we've made the deliberate choice to push such
> steps into the future.

> In the meantime, there is no reason we cannot have multiple "inconsistent" draft
> or candidate JEPs, so there is no need to "merge" anything right now.
Here is my counter-proposal, use a @Lazy annotation to mark the static final field and requires the static final fields to be initialized by a static method. 

With the Logger example, it becomes 

class Bar { 
// 1. Declare a computed constant value, it has to be initialized by a static method 
private static final @Lazy Logger LOGGER = initLogger(); 

// 2. Initialize the value 
private static Logger initLogger() { 
return Logger.getLogger("com.foo.Bar"); 
} 
} 

You have exactly the same information, it's easier for a class rewriter than the computed constant proposal and a compiler guy and then a VM guy can also work on it. 
And obvisouly, it's a backward compatible change. 

R?mi 

> On 7/27/2023 12:09 PM, Remi Forax wrote:

>> Hello,
>> Are you aware of the lazy static final fields proposal ?
>> [ https://bugs.openjdk.org/browse/JDK-8209964 |
>> https://bugs.openjdk.org/browse/JDK-8209964 ]

>> In think both proposals should be merged.

>> R?mi

>>> From: "Per-Ake Minborg" [ mailto:per-ake.minborg at oracle.com |
>>> <per-ake.minborg at oracle.com> ]
>>> To: "leyden-dev" [ mailto:leyden-dev at openjdk.org | <leyden-dev at openjdk.org> ]
>>> Sent: Thursday, July 27, 2023 5:52:46 PM
>>> Subject: Draft JEP Announcement: "Computed Constants"

>>> Hi all,

>>> Maurizio and I have drafted a JEP for computed constants, which are
>>> immutable value holders that are initialized at most once. They offer
>>> the performance and safety benefits of final fields while offering
>>> greater flexibility as to the timing of initialization. In the
>>> context of Leyden, they could be one basis for shifting computation
>>> both forward and backward in time.

>>> The draft is here: [ https://openjdk.org/jeps/8312611 |
>>> https://openjdk.org/jeps/8312611 ]

>>> Now that the Leyden repo is open, I?ll publish the prototype code to a
>>> new branch there shortly.

>>> Comments are welcome!

>>> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/37d75afa/attachment.htm>

From maurizio.cimadamore at oracle.com  Thu Jul 27 17:18:24 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 27 Jul 2023 18:18:24 +0100
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <2085881755.4354553.1690477413009.JavaMail.zimbra@univ-eiffel.fr>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <d8c5bd77-2a1c-a11d-cebe-53e9187c0cd7@oracle.com>
 <2085881755.4354553.1690477413009.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <21913adf-87ee-1883-e25b-ba100e2c3abe@oracle.com>

Hi Remi,
I understand that the theme of static variables implemented via condy is 
dear to you.


That said, this attitude of immediately shooting out a counter-proposal 
5 minutes after seeing a JEP which originated after giving the very same 
topics you mention a considerable amount of thought, is (a) unfair and 
(b) has the net effect of sucking all the oxygen out this discussion.


Your comments are noted, now let's also make sure we hear what other 
people have to say.


Cheers
Maurizio


On 27/07/2023 18:03, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg"
>     <per-ake.minborg at oracle.com>
>     *Cc: *"leyden-dev" <leyden-dev at openjdk.org>, "John Rose"
>     <john.r.rose at oracle.com>
>     *Sent: *Thursday, July 27, 2023 6:23:01 PM
>     *Subject: *Re: Draft JEP Announcement: "Computed Constants"
>
>     As Maurizio said, this JEP is a refinement of ideas that were
>     initially explored in the "lazy statics" JEP.? In a way, this JEP
>     reveals the "lazy statics" JEP as skipping a step, jumping to a
>     language and VM when much of the benefit can be achieved by a
>     libraries approach.? It is possible that at some point, after
>     suitable progress and validation, we may decide to take the step
>     of pushing it further into the language/VM, but we've made the
>     deliberate choice to push such steps into the future.
>
>     In the meantime, there is no reason we cannot have multiple
>     "inconsistent" draft or candidate JEPs, so there is no need to
>     "merge" anything right now. 
>
>
> Here is my counter-proposal, use a @Lazy annotation to mark the static 
> final field and requires the static final fields to be initialized by 
> a static method.
>
> With the Logger example, it becomes
>
> class Bar {
> ??? // 1. Declare a computed constant value, it has to be initialized 
> by a static method
> ??? private static final @Lazy Logger LOGGER = initLogger();
>
> ??? // 2. Initialize the value
> ??? private static Logger initLogger() {
> ?????? return Logger.getLogger("com.foo.Bar");
> ??? }
> }
>
> You have exactly the same information, it's easier for a class 
> rewriter than the computed constant proposal and a compiler guy and 
> then a VM guy can also work on it.
> And obvisouly, it's a backward compatible change.
>
> R?mi
>
>
>
>
>     On 7/27/2023 12:09 PM, Remi Forax wrote:
>
>         Hello,
>         Are you aware of the lazy static final fields proposal ?
>         https://bugs.openjdk.org/browse/JDK-8209964
>
>         In think both proposals should be merged.
>
>         R?mi
>
>         ------------------------------------------------------------------------
>
>             *From: *"Per-Ake Minborg" <per-ake.minborg at oracle.com>
>             *To: *"leyden-dev" <leyden-dev at openjdk.org>
>             *Sent: *Thursday, July 27, 2023 5:52:46 PM
>             *Subject: *Draft JEP Announcement: "Computed Constants"
>
>             Hi all,
>
>             Maurizio and I have drafted a JEP for computed constants,
>             which are
>             immutable value holders that are initialized at most
>             once.? They offer
>             the performance and safety benefits of final fields while
>             offering
>             greater flexibility as to the timing of initialization.?
>             In the
>             context of Leyden, they could be one basis for shifting
>             computation
>             both forward and backward in time.
>
>             ? The draft is here:https://openjdk.org/jeps/8312611
>             <https://openjdk.org/jeps/8312611>
>
>             Now that the Leyden repo is open, I?ll publish the
>             prototype code to a
>             new branch there shortly.
>
>             ? Comments are welcome!
>
>             Best, Per
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/5be840fc/attachment.htm>

From davidalayachew at gmail.com  Thu Jul 27 17:27:58 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 27 Jul 2023 13:27:58 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_OF=HVv0utmB9JV68p3fHCy=Nw+TcD7=7yL71kc2844Tg@mail.gmail.com>

Hello Per,

Thank you for posting this JEP!

It looks great. The solution is concise, clear, and simple, and any
complaints I have about verbosity can be mostly addressed with var. And
that list suggestion was especially nice. That's very neat.

I'd like to ask about the safety point. I certainly understand the reason
why it exists -- some developers will inadvertently create a circular
reference and end up causing problems.

However, I see a lot of utility for circular references too. Any chance
that we could allow devs to opt-in to circular references?

Earlier this month, I started 2 threads that were broaching the subject of
a very similar pain point to this one. Here they both are.

https://mail.openjdk.org/pipermail/amber-dev/2023-July/008129.html

https://mail.openjdk.org/pipermail/amber-dev/2023-July/008154.html

I'm curious how this Computed Constant solution would work out for the
problem I have. But in order for it to work, it would need to enable
circular references, hence my question.

But even without it, I see a lot of utility for this tool. I'm excited to
get to work prototyping with it.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/4136bb0c/attachment.htm>

From davidalayachew at gmail.com  Thu Jul 27 17:31:09 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 27 Jul 2023 13:31:09 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_MFG_E6e-x8FJ+AJ2E6C2hM8cWeg0jD0bhYxdHovQ7+1Q@mail.gmail.com>

Also, please notify when a build has been made with this implementation
included. I have a few projects I want to try this out on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/41340fcf/attachment.htm>

From brian.goetz at oracle.com  Thu Jul 27 17:50:09 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 27 Jul 2023 13:50:09 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>

One thing that may not be obvious about this work is that what it 
effectively does is provide a supported, public, specified means to 
expose the functionality that is now restricted to internal JDK use via 
`@Stable`.? (So computed constants is-to @Stable as VarHandles are to 
Unsafe::{get,put}Xxx.)

On 7/27/2023 11:52 AM, Per-Ake Minborg wrote:
> Hi all,
>
> ? Maurizio and I have drafted a JEP for computed constants, which are
> ? immutable value holders that are initialized at most once.? They offer
> ? the performance and safety benefits of final fields while offering
> ? greater flexibility as to the timing of initialization.? In the
> ? context of Leyden, they could be one basis for shifting computation
> ? both forward and backward in time.
>
> ? The draft is here:https://openjdk.org/jeps/8312611 
> <https://openjdk.org/jeps/8312611>
>
> ? Now that the Leyden repo is open, I?ll publish the prototype code to a
> ? new branch there shortly.
>
> ? Comments are welcome!
>
> ? Best, Per
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/f98e1c22/attachment.htm>

From davidalayachew at gmail.com  Thu Jul 27 17:55:56 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 27 Jul 2023 13:55:56 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>
Message-ID: <CAA9v-_OEwNw5q8FRcB0yTSe37z8HP0_7QXh2f=3keD9-xfj7Cw@mail.gmail.com>

That's really cool! It would probably be nice to put that into the JEP, as
it would highlight another avenue of utility, specifically for people
working on the JDK.


On Thu, Jul 27, 2023 at 1:50?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> One thing that may not be obvious about this work is that what it
> effectively does is provide a supported, public, specified means to expose
> the functionality that is now restricted to internal JDK use via
> `@Stable`.  (So computed constants is-to @Stable as VarHandles are to
> Unsafe::{get,put}Xxx.)
>
> On 7/27/2023 11:52 AM, Per-Ake Minborg wrote:
>
> Hi all,
>
>   Maurizio and I have drafted a JEP for computed constants, which are
>   immutable value holders that are initialized at most once.  They offer
>   the performance and safety benefits of final fields while offering
>   greater flexibility as to the timing of initialization.  In the
>   context of Leyden, they could be one basis for shifting computation
>   both forward and backward in time.
>
>   The draft is here: https://openjdk.org/jeps/8312611
>
>   Now that the Leyden repo is open, I?ll publish the prototype code to a
>   new branch there shortly.
>
>   Comments are welcome!
>
>   Best, Per
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/76163195/attachment.htm>

From brian.goetz at oracle.com  Thu Jul 27 17:58:01 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 27 Jul 2023 13:58:01 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAA9v-_OEwNw5q8FRcB0yTSe37z8HP0_7QXh2f=3keD9-xfj7Cw@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>
 <CAA9v-_OEwNw5q8FRcB0yTSe37z8HP0_7QXh2f=3keD9-xfj7Cw@mail.gmail.com>
Message-ID: <b7090f7f-3b59-cc43-ffdc-387f883e808d@oracle.com>


> That's really cool! It would probably be nice to put that into the 
> JEP, as it would highlight another avenue of utility, specifically for 
> people working on the JDK.

There's a method to the madness.? JEPs reach a very broad audience, and 
99.999% of Java developers don't know what @Stable is (and can't use it 
if they did.)? So putting it in the JEP at this point is likely to be 
more confusing than helpful.? The audience for this mailing list, 
though, has a much higher density of JDK developers and bleeding-edge 
adopters, and so are more likely to see the connection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/af0d7d5c/attachment.htm>

From davidalayachew at gmail.com  Thu Jul 27 18:45:27 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 27 Jul 2023 14:45:27 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <b7090f7f-3b59-cc43-ffdc-387f883e808d@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>
 <CAA9v-_OEwNw5q8FRcB0yTSe37z8HP0_7QXh2f=3keD9-xfj7Cw@mail.gmail.com>
 <b7090f7f-3b59-cc43-ffdc-387f883e808d@oracle.com>
Message-ID: <CAA9v-_OZatUzy4aEtUEWkFkB=SKRgCSwJE8icec88kpY5c_czQ@mail.gmail.com>

Makes sense, ty.


On Thu, Jul 27, 2023 at 1:58?PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> That's really cool! It would probably be nice to put that into the JEP, as
> it would highlight another avenue of utility, specifically for people
> working on the JDK.
>
>
> There's a method to the madness.  JEPs reach a very broad audience, and
> 99.999% of Java developers don't know what @Stable is (and can't use it if
> they did.)  So putting it in the JEP at this point is likely to be more
> confusing than helpful.  The audience for this mailing list, though, has a
> much higher density of JDK developers and bleeding-edge adopters, and so
> are more likely to see the connection.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/6136b5d9/attachment.htm>

From forax at univ-mlv.fr  Thu Jul 27 19:39:04 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 Jul 2023 21:39:04 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <6aad32c9-c07a-a5db-0ded-0e9896b80c98@oracle.com>
Message-ID: <1851487133.4381890.1690486744073.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Per-Ake Minborg" <per-ake.minborg at oracle.com>, "leyden-dev"
> <leyden-dev at openjdk.org>
> Sent: Thursday, July 27, 2023 7:50:09 PM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

> One thing that may not be obvious about this work is that what it effectively
> does is provide a supported, public, specified means to expose the
> functionality that is now restricted to internal JDK use via `@Stable`. (So
> computed constants is-to @Stable as VarHandles are to Unsafe::{get,put}Xxx.)
Not exactly, computed constant is more like an AtomicReference (as said in the javadoc) than a VarHandle. 
For a computed constant stored in an instance field (of a non constant instance), you pay the indirection cost. 

Perhaps what is missing is a ComputedConstant that have a method get() that takes an instance as first parameter (like a VarHandle on an instance field does), so we can have one computed constant for all the instances, so no indirection once the code is optimized. 

R?mi 

> On 7/27/2023 11:52 AM, Per-Ake Minborg wrote:

>> Hi all,

>> Maurizio and I have drafted a JEP for computed constants, which are
>> immutable value holders that are initialized at most once. They offer
>> the performance and safety benefits of final fields while offering
>> greater flexibility as to the timing of initialization. In the
>> context of Leyden, they could be one basis for shifting computation
>> both forward and backward in time.

>> The draft is here: [ https://openjdk.org/jeps/8312611 |
>> https://openjdk.org/jeps/8312611 ]

>> Now that the Leyden repo is open, I?ll publish the prototype code to a
>> new branch there shortly.

>> Comments are welcome!

>> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/17f76874/attachment.htm>

From tanksherman27 at gmail.com  Fri Jul 28 02:40:12 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 28 Jul 2023 10:40:12 +0800
Subject: JEP draft
Message-ID: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>

Hi all,

A JEP draft regarding Leyden has been submitted at
https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/336d99dc/attachment.htm>

From davidalayachew at gmail.com  Fri Jul 28 03:07:24 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 27 Jul 2023 23:07:24 -0400
Subject: JEP draft
In-Reply-To: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
Message-ID: <CAA9v-_NQ9Md-7aARP6sYF8tNgJJbUvNoSAhLDF1XDwCH_O9ZYQ@mail.gmail.com>

Hello Julian,

Thank you for posting the draft!

As you mentioned, it's unfinished, so I'll ignore the unpopulated parts.

What I did appreciate is how the compiler specifics in the Motivation
section were clearly explained. It was easy to follow along, even as an
outsider.

" and that no C1 nmethods have to be discarded once the C2 "

Is that word intentional?

Only other thing I would say would be to break up some of the paragraphs
and sentences. You have a few run-on sentences, and it might be easier to
parse if some of the jumbo paragraphs were broken up into (titled?) smaller
sub-sections. Don't get me wrong, it's very efficient and clearly
described, but it's dense too. For something that goes into the guts of the
compiler world, loosening things up a bit might make it easier to digest.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/f8bafc79/attachment.htm>

From tanksherman27 at gmail.com  Fri Jul 28 03:12:02 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 28 Jul 2023 11:12:02 +0800
Subject: JEP draft
In-Reply-To: <CAA9v-_NQ9Md-7aARP6sYF8tNgJJbUvNoSAhLDF1XDwCH_O9ZYQ@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
 <CAA9v-_NQ9Md-7aARP6sYF8tNgJJbUvNoSAhLDF1XDwCH_O9ZYQ@mail.gmail.com>
Message-ID: <CAP2b4GOHT1UYm8qNfK8mNzaU4HuUpJ2KSjuAJCu5rYLMTFfcFw@mail.gmail.com>

Hi David,

Thanks for the feedback, I'll modify the JEP as such. Yes, that word is
intentional, "nmethod" is what fully compiled Java methods are called in
HotSpot code

best regards,
Julian

On Fri, Jul 28, 2023 at 11:07?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Julian,
>
> Thank you for posting the draft!
>
> As you mentioned, it's unfinished, so I'll ignore the unpopulated parts.
>
> What I did appreciate is how the compiler specifics in the Motivation
> section were clearly explained. It was easy to follow along, even as an
> outsider.
>
> " and that no C1 nmethods have to be discarded once the C2 "
>
> Is that word intentional?
>
> Only other thing I would say would be to break up some of the paragraphs
> and sentences. You have a few run-on sentences, and it might be easier to
> parse if some of the jumbo paragraphs were broken up into (titled?) smaller
> sub-sections. Don't get me wrong, it's very efficient and clearly
> described, but it's dense too. For something that goes into the guts of the
> compiler world, loosening things up a bit might make it easier to digest.
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/9039dbf3/attachment.htm>

From davidalayachew at gmail.com  Fri Jul 28 03:17:07 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 27 Jul 2023 23:17:07 -0400
Subject: JEP draft
In-Reply-To: <CAP2b4GOHT1UYm8qNfK8mNzaU4HuUpJ2KSjuAJCu5rYLMTFfcFw@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
 <CAA9v-_NQ9Md-7aARP6sYF8tNgJJbUvNoSAhLDF1XDwCH_O9ZYQ@mail.gmail.com>
 <CAP2b4GOHT1UYm8qNfK8mNzaU4HuUpJ2KSjuAJCu5rYLMTFfcFw@mail.gmail.com>
Message-ID: <CAA9v-_P9y9JLJsAWVhWBqYVRzpwdCe5ir8HM6UHfak3gFoYNXQ@mail.gmail.com>

Much appreciated, google wasn't much help for nmethods. I had to uncorrect
gmail's autocorrect multiple times when typing the previous sentence, so I
imagine that's why.

I know it's still in progress, but it already looks way better!



On Thu, Jul 27, 2023 at 11:12?PM Julian Waters <tanksherman27 at gmail.com>
wrote:

> Hi David,
>
> Thanks for the feedback, I'll modify the JEP as such. Yes, that word is
> intentional, "nmethod" is what fully compiled Java methods are called in
> HotSpot code
>
> best regards,
> Julian
>
> On Fri, Jul 28, 2023 at 11:07?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello Julian,
>>
>> Thank you for posting the draft!
>>
>> As you mentioned, it's unfinished, so I'll ignore the unpopulated parts.
>>
>> What I did appreciate is how the compiler specifics in the Motivation
>> section were clearly explained. It was easy to follow along, even as an
>> outsider.
>>
>> " and that no C1 nmethods have to be discarded once the C2 "
>>
>> Is that word intentional?
>>
>> Only other thing I would say would be to break up some of the paragraphs
>> and sentences. You have a few run-on sentences, and it might be easier to
>> parse if some of the jumbo paragraphs were broken up into (titled?) smaller
>> sub-sections. Don't get me wrong, it's very efficient and clearly
>> described, but it's dense too. For something that goes into the guts of the
>> compiler world, loosening things up a bit might make it easier to digest.
>>
>> Thank you for your time and help!
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/67c086ff/attachment.htm>

From mike at hydraulic.software  Fri Jul 28 07:26:00 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Fri, 28 Jul 2023 09:26:00 +0200
Subject: JEP draft
In-Reply-To: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
Message-ID: <CAGv+2bN+gFeZ__P9V53GNx9BNBGE8WT=SQQbBUUmp1nh-t5Q4A@mail.gmail.com>

Nice to see!

Presumably the concrete goal will be to nail down an ABI between compiled
code and the HotSpot runtime services? The compiler independence of the
goals is quite interesting. In theory if there's a precise ABI for
accessing runtime services like the GC, reflection, deoptimization, TLS
etc, then you could write a new non-Java language that compiles to native
code ahead of time using some pre-existing compiler infrastructure (e.g.
.NET?), which then uses HotSpot almost as a normal language runtime
library. Minimal Java code would be executed in this model and you could
theoretically even use LTO to get rid of the bits of the JVM you aren't
using. So if you wanted to make a new GCd language but wanted to skip
bytecode and Truffle then you could do so, with a Leyden of that form.

Or is the idea to go in some other direction?

On Fri, 28 Jul 2023 at 04:41, Julian Waters <tanksherman27 at gmail.com> wrote:

> Hi all,
>
> A JEP draft regarding Leyden has been submitted at
> https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome
>
> best regards,
> Julian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/f97448e7/attachment.htm>

From per-ake.minborg at oracle.com  Fri Jul 28 07:29:48 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Fri, 28 Jul 2023 07:29:48 +0000
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
 <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>

Hi R?mi,

I share your view that it is important to be able to use ComputedConstant "early" in the VM startup sequence. There is nothing inherent to the proposed API that *requires* a lambda or a method reference to be used. An anonymous or regular class, implementing Supplier would also do. Also, there is nothing fundamental that prevents us from *implementing* the API in a way it can be used "early".

We do not add any keywords, the JEP is a pure library approach so, I do not foresee any backward compatibility issues.

Thanks for your feedback.

Best, Per
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, July 27, 2023 6:36 PM
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: Per-Ake Minborg <per-ake.minborg at oracle.com>; leyden-dev <leyden-dev at openjdk.org>; John Rose <john.r.rose at oracle.com>
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"



________________________________
From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg" <per-ake.minborg at oracle.com>
Cc: "leyden-dev" <leyden-dev at openjdk.org>, "John Rose" <john.r.rose at oracle.com>
Sent: Thursday, July 27, 2023 6:14:48 PM
Subject: Re: Draft JEP Announcement: "Computed Constants"

Hi Remi
Yes, of course we were aware of that.

Think of this proposal as an API-driven approach (in the style of ThreadLocal, ClassValue, ScopedValue, ...) which delivers more or less the same feature, but w/o changing the language.


One thing that's attractive about the API approach is that it is not limited to just static fields, but it can also work for instance fields as well.


(that said, I agree the two jeps should somehow be related/link to each other)

I see two problems with your suggested approach:
- this proposal is on top of lambdas, which means that it can be used for applications but not for the VM startup because it can only be used after method handles sub-system have been initialized.
- this is not a backward compatible change, if you add a new keyword to static final fields, you can rewrite any public static final fields to a public lazy static final field,
  by example, String.CASE_INSENSITIVE_ORDER which is rarely used but can not be changed with your proposal.


Maurizio

R?mi



On 27/07/2023 17:09, Remi Forax wrote:
Hello,
Are you aware of the lazy static final fields proposal ?
  https://bugs.openjdk.org/browse/JDK-8209964

In think both proposals should be merged.

R?mi

________________________________
From: "Per-Ake Minborg" <per-ake.minborg at oracle.com><mailto:per-ake.minborg at oracle.com>
To: "leyden-dev" <leyden-dev at openjdk.org><mailto:leyden-dev at openjdk.org>
Sent: Thursday, July 27, 2023 5:52:46 PM
Subject: Draft JEP Announcement: "Computed Constants"
Hi all,

  Maurizio and I have drafted a JEP for computed constants, which are
  immutable value holders that are initialized at most once.  They offer
  the performance and safety benefits of final fields while offering
  greater flexibility as to the timing of initialization.  In the
  context of Leyden, they could be one basis for shifting computation
  both forward and backward in time.

  The draft is here:https://openjdk.org/jeps/8312611

  Now that the Leyden repo is open, I?ll publish the prototype code to a
  new branch there shortly.

  Comments are welcome!

  Best, Per



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/267d1d8e/attachment.htm>

From tanksherman27 at gmail.com  Fri Jul 28 07:58:12 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 28 Jul 2023 15:58:12 +0800
Subject: JEP draft
In-Reply-To: <CAGv+2bN+gFeZ__P9V53GNx9BNBGE8WT=SQQbBUUmp1nh-t5Q4A@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
 <CAGv+2bN+gFeZ__P9V53GNx9BNBGE8WT=SQQbBUUmp1nh-t5Q4A@mail.gmail.com>
Message-ID: <CAP2b4GPqPruM4Z4fSB0qWTqKVLgb4e5TkOq_+D-V0X3GgiFbCQ@mail.gmail.com>

Hi Mike,

Although the goal wasn't written with that in mind (the compiler
independence is for code produced by JVMCI compilers, most notably to help
what Galahad intends to do with the Graal JIT by AOT compiling it, rather
than only restricting such code to only use C1 and C2), I suppose you could
indeed use this platform to execute any arbitrary language with HotSpot,
much in the same way any language can compile to Java's bytecode and
execute in the Java Virtual Machine currently. The ABI is very probably
going to be the same as what C1, C2, and JVMCI use, so any language that
respects the same ABI as a JVMCI compiler could probably run with HotSpot,
but again I will mention that this is not what the JEP was written in mind
with. See also non-goals, which mentions that this feature will only be
applicable to Java code (or any language trying to use this platform to
compile to native) that respects the constraints that Leyden normally
applies to its closed world standalone binaries

best regards,
Julian

On Fri, Jul 28, 2023 at 3:26?PM Mike Hearn <mike at hydraulic.software> wrote:

> Nice to see!
>
> Presumably the concrete goal will be to nail down an ABI between compiled
> code and the HotSpot runtime services? The compiler independence of the
> goals is quite interesting. In theory if there's a precise ABI for
> accessing runtime services like the GC, reflection, deoptimization, TLS
> etc, then you could write a new non-Java language that compiles to native
> code ahead of time using some pre-existing compiler infrastructure (e.g.
> .NET?), which then uses HotSpot almost as a normal language runtime
> library. Minimal Java code would be executed in this model and you could
> theoretically even use LTO to get rid of the bits of the JVM you aren't
> using. So if you wanted to make a new GCd language but wanted to skip
> bytecode and Truffle then you could do so, with a Leyden of that form.
>
> Or is the idea to go in some other direction?
>
> On Fri, 28 Jul 2023 at 04:41, Julian Waters <tanksherman27 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> A JEP draft regarding Leyden has been submitted at
>> https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome
>>
>> best regards,
>> Julian
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/23d9b170/attachment.htm>

From mike at hydraulic.software  Fri Jul 28 08:04:16 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Fri, 28 Jul 2023 10:04:16 +0200
Subject: JEP draft
In-Reply-To: <CAP2b4GPqPruM4Z4fSB0qWTqKVLgb4e5TkOq_+D-V0X3GgiFbCQ@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
 <CAGv+2bN+gFeZ__P9V53GNx9BNBGE8WT=SQQbBUUmp1nh-t5Q4A@mail.gmail.com>
 <CAP2b4GPqPruM4Z4fSB0qWTqKVLgb4e5TkOq_+D-V0X3GgiFbCQ@mail.gmail.com>
Message-ID: <CAGv+2bO0SPttr9xEWueM4k24A698Z1_WFvNcU3HdKY8+QauUnQ@mail.gmail.com>

Understood, I was just observing that it might be possible. I guess it
really would depend on how well documented the interface is. If it's
clearly documented and relatively stable, others could use it. If not, then
nobody would try. As far as I know the ABI that compiled code must conform
to in HotSpot isn't currently documented anywhere?

On Fri, 28 Jul 2023 at 09:58, Julian Waters <tanksherman27 at gmail.com> wrote:

> Hi Mike,
>
> Although the goal wasn't written with that in mind (the compiler
> independence is for code produced by JVMCI compilers, most notably to help
> what Galahad intends to do with the Graal JIT by AOT compiling it, rather
> than only restricting such code to only use C1 and C2), I suppose you could
> indeed use this platform to execute any arbitrary language with HotSpot,
> much in the same way any language can compile to Java's bytecode and
> execute in the Java Virtual Machine currently. The ABI is very probably
> going to be the same as what C1, C2, and JVMCI use, so any language that
> respects the same ABI as a JVMCI compiler could probably run with HotSpot,
> but again I will mention that this is not what the JEP was written in mind
> with. See also non-goals, which mentions that this feature will only be
> applicable to Java code (or any language trying to use this platform to
> compile to native) that respects the constraints that Leyden normally
> applies to its closed world standalone binaries
>
> best regards,
> Julian
>
> On Fri, Jul 28, 2023 at 3:26?PM Mike Hearn <mike at hydraulic.software>
> wrote:
>
>> Nice to see!
>>
>> Presumably the concrete goal will be to nail down an ABI between compiled
>> code and the HotSpot runtime services? The compiler independence of the
>> goals is quite interesting. In theory if there's a precise ABI for
>> accessing runtime services like the GC, reflection, deoptimization, TLS
>> etc, then you could write a new non-Java language that compiles to native
>> code ahead of time using some pre-existing compiler infrastructure (e.g.
>> .NET?), which then uses HotSpot almost as a normal language runtime
>> library. Minimal Java code would be executed in this model and you could
>> theoretically even use LTO to get rid of the bits of the JVM you aren't
>> using. So if you wanted to make a new GCd language but wanted to skip
>> bytecode and Truffle then you could do so, with a Leyden of that form.
>>
>> Or is the idea to go in some other direction?
>>
>> On Fri, 28 Jul 2023 at 04:41, Julian Waters <tanksherman27 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> A JEP draft regarding Leyden has been submitted at
>>> https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome
>>>
>>> best regards,
>>> Julian
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/0cbb1d9f/attachment.htm>

From tanksherman27 at gmail.com  Fri Jul 28 08:04:27 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 28 Jul 2023 16:04:27 +0800
Subject: JEP draft
In-Reply-To: <CAP2b4GPqPruM4Z4fSB0qWTqKVLgb4e5TkOq_+D-V0X3GgiFbCQ@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
 <CAGv+2bN+gFeZ__P9V53GNx9BNBGE8WT=SQQbBUUmp1nh-t5Q4A@mail.gmail.com>
 <CAP2b4GPqPruM4Z4fSB0qWTqKVLgb4e5TkOq_+D-V0X3GgiFbCQ@mail.gmail.com>
Message-ID: <CAP2b4GMiimbXS8md5RQBKx8Uw-4qFYmGMBZqGHFz6FfVkAHANA@mail.gmail.com>

I should mention that although this isn't in the JEP yet, the plan is to
have 2 different compilation modes available, "Profiling" for compilers
like C1 in Tiers 2 and 3, which is compiled profiling code that will work
in tandem with the Tiered Compilation execution pipeline that HotSpot
employs, meaning it can then be optimized even more as HotSpot collects
profiling data from it, and "Optimized" which is for compilers like C2 and
C1 in Tier 1. Such Ahead of Time code that is compiled as "Optimized" will
be treated as having been optimized to the best extent possible, and will
not be part of the optimization and deoptimization cycles like "Profiling"
code will be

On Fri, Jul 28, 2023 at 3:58?PM Julian Waters <tanksherman27 at gmail.com>
wrote:

> Hi Mike,
>
> Although the goal wasn't written with that in mind (the compiler
> independence is for code produced by JVMCI compilers, most notably to help
> what Galahad intends to do with the Graal JIT by AOT compiling it, rather
> than only restricting such code to only use C1 and C2), I suppose you could
> indeed use this platform to execute any arbitrary language with HotSpot,
> much in the same way any language can compile to Java's bytecode and
> execute in the Java Virtual Machine currently. The ABI is very probably
> going to be the same as what C1, C2, and JVMCI use, so any language that
> respects the same ABI as a JVMCI compiler could probably run with HotSpot,
> but again I will mention that this is not what the JEP was written in mind
> with. See also non-goals, which mentions that this feature will only be
> applicable to Java code (or any language trying to use this platform to
> compile to native) that respects the constraints that Leyden normally
> applies to its closed world standalone binaries
>
> best regards,
> Julian
>
> On Fri, Jul 28, 2023 at 3:26?PM Mike Hearn <mike at hydraulic.software>
> wrote:
>
>> Nice to see!
>>
>> Presumably the concrete goal will be to nail down an ABI between compiled
>> code and the HotSpot runtime services? The compiler independence of the
>> goals is quite interesting. In theory if there's a precise ABI for
>> accessing runtime services like the GC, reflection, deoptimization, TLS
>> etc, then you could write a new non-Java language that compiles to native
>> code ahead of time using some pre-existing compiler infrastructure (e.g.
>> .NET?), which then uses HotSpot almost as a normal language runtime
>> library. Minimal Java code would be executed in this model and you could
>> theoretically even use LTO to get rid of the bits of the JVM you aren't
>> using. So if you wanted to make a new GCd language but wanted to skip
>> bytecode and Truffle then you could do so, with a Leyden of that form.
>>
>> Or is the idea to go in some other direction?
>>
>> On Fri, 28 Jul 2023 at 04:41, Julian Waters <tanksherman27 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> A JEP draft regarding Leyden has been submitted at
>>> https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome
>>>
>>> best regards,
>>> Julian
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/bb9333ae/attachment.htm>

From tanksherman27 at gmail.com  Fri Jul 28 08:06:21 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 28 Jul 2023 16:06:21 +0800
Subject: JEP draft
In-Reply-To: <CAGv+2bO0SPttr9xEWueM4k24A698Z1_WFvNcU3HdKY8+QauUnQ@mail.gmail.com>
References: <CAP2b4GN4FqoNmQm5UAbZbm+xq4PtZdCM4R27+z6zBFS9G5Y4Hg@mail.gmail.com>
 <CAGv+2bN+gFeZ__P9V53GNx9BNBGE8WT=SQQbBUUmp1nh-t5Q4A@mail.gmail.com>
 <CAP2b4GPqPruM4Z4fSB0qWTqKVLgb4e5TkOq_+D-V0X3GgiFbCQ@mail.gmail.com>
 <CAGv+2bO0SPttr9xEWueM4k24A698Z1_WFvNcU3HdKY8+QauUnQ@mail.gmail.com>
Message-ID: <CAP2b4GPoENS54i7T9UHaKqXX8rK+6hp63e1GteXGVwJ0MCkg2Q@mail.gmail.com>

I suppose it could be an avenue to pursue as a sub-task of some sort ;)

On Fri, Jul 28, 2023 at 4:04?PM Mike Hearn <mike at hydraulic.software> wrote:

> Understood, I was just observing that it might be possible. I guess it
> really would depend on how well documented the interface is. If it's
> clearly documented and relatively stable, others could use it. If not, then
> nobody would try. As far as I know the ABI that compiled code must conform
> to in HotSpot isn't currently documented anywhere?
>
> On Fri, 28 Jul 2023 at 09:58, Julian Waters <tanksherman27 at gmail.com>
> wrote:
>
>> Hi Mike,
>>
>> Although the goal wasn't written with that in mind (the compiler
>> independence is for code produced by JVMCI compilers, most notably to help
>> what Galahad intends to do with the Graal JIT by AOT compiling it, rather
>> than only restricting such code to only use C1 and C2), I suppose you could
>> indeed use this platform to execute any arbitrary language with HotSpot,
>> much in the same way any language can compile to Java's bytecode and
>> execute in the Java Virtual Machine currently. The ABI is very probably
>> going to be the same as what C1, C2, and JVMCI use, so any language that
>> respects the same ABI as a JVMCI compiler could probably run with HotSpot,
>> but again I will mention that this is not what the JEP was written in mind
>> with. See also non-goals, which mentions that this feature will only be
>> applicable to Java code (or any language trying to use this platform to
>> compile to native) that respects the constraints that Leyden normally
>> applies to its closed world standalone binaries
>>
>> best regards,
>> Julian
>>
>> On Fri, Jul 28, 2023 at 3:26?PM Mike Hearn <mike at hydraulic.software>
>> wrote:
>>
>>> Nice to see!
>>>
>>> Presumably the concrete goal will be to nail down an ABI between
>>> compiled code and the HotSpot runtime services? The compiler independence
>>> of the goals is quite interesting. In theory if there's a precise ABI for
>>> accessing runtime services like the GC, reflection, deoptimization, TLS
>>> etc, then you could write a new non-Java language that compiles to native
>>> code ahead of time using some pre-existing compiler infrastructure (e.g.
>>> .NET?), which then uses HotSpot almost as a normal language runtime
>>> library. Minimal Java code would be executed in this model and you could
>>> theoretically even use LTO to get rid of the bits of the JVM you aren't
>>> using. So if you wanted to make a new GCd language but wanted to skip
>>> bytecode and Truffle then you could do so, with a Leyden of that form.
>>>
>>> Or is the idea to go in some other direction?
>>>
>>> On Fri, 28 Jul 2023 at 04:41, Julian Waters <tanksherman27 at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> A JEP draft regarding Leyden has been submitted at
>>>> https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome
>>>>
>>>> best regards,
>>>> Julian
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/b98a34d1/attachment.htm>

From zjx001202 at gmail.com  Fri Jul 28 09:23:59 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 28 Jul 2023 17:23:59 +0800
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
 <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAJL5A3=if3JKGDF9RD5LX9CKrPd5QpsXuoeKCfWL3V1vSsBAgA@mail.gmail.com>

>
> I share your view that it is important to be able to use ComputedConstant
> "early" in the VM startup sequence. There is nothing inherent to the
> proposed API that *requires* a lambda or a method reference to be used. An
> anonymous or regular class, implementing Supplier would also do. Also,
> there is nothing fundamental that prevents us from *implementing* the API
> in a way it can be used "early".
>

If anonymous classes need to be used, what is its advantage over the
initialization-on-demand holder idiom?
It seems to be completely inferior to initialization-on-demand holder
idiom, except for being able to use it as instance fields.

Glavo

On Fri, Jul 28, 2023 at 3:29?PM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Hi R?mi,
>
> I share your view that it is important to be able to use ComputedConstant
> "early" in the VM startup sequence. There is nothing inherent to the
> proposed API that *requires* a lambda or a method reference to be used. An
> anonymous or regular class, implementing Supplier would also do. Also,
> there is nothing fundamental that prevents us from *implementing* the API
> in a way it can be used "early".
>
> We do not add any keywords, the JEP is a pure library approach so, I do
> not foresee any backward compatibility issues.
>
> Thanks for your feedback.
>
> Best, Per
> ------------------------------
> *From:* forax at univ-mlv.fr <forax at univ-mlv.fr>
> *Sent:* Thursday, July 27, 2023 6:36 PM
> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> *Cc:* Per-Ake Minborg <per-ake.minborg at oracle.com>; leyden-dev <
> leyden-dev at openjdk.org>; John Rose <john.r.rose at oracle.com>
> *Subject:* [External] : Re: Draft JEP Announcement: "Computed Constants"
>
>
>
> ------------------------------
>
> *From: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg" <
> per-ake.minborg at oracle.com>
> *Cc: *"leyden-dev" <leyden-dev at openjdk.org>, "John Rose" <
> john.r.rose at oracle.com>
> *Sent: *Thursday, July 27, 2023 6:14:48 PM
> *Subject: *Re: Draft JEP Announcement: "Computed Constants"
>
> Hi Remi
> Yes, of course we were aware of that.
>
> Think of this proposal as an API-driven approach (in the style of
> ThreadLocal, ClassValue, ScopedValue, ...) which delivers more or less the
> same feature, but w/o changing the language.
>
>
> One thing that's attractive about the API approach is that it is not
> limited to just static fields, but it can also work for instance fields as
> well.
>
>
> (that said, I agree the two jeps should somehow be related/link to each
> other)
>
>
> I see two problems with your suggested approach:
> - this proposal is on top of lambdas, which means that it can be used for
> applications but not for the VM startup because it can only be used after
> method handles sub-system have been initialized.
> - this is not a backward compatible change, if you add a new keyword to
> static final fields, you can rewrite any public static final fields to a
> public lazy static final field,
>   by example, String.CASE_INSENSITIVE_ORDER which is rarely used but can
> not be changed with your proposal.
>
>
> Maurizio
>
>
> R?mi
>
>
> On 27/07/2023 17:09, Remi Forax wrote:
>
> Hello,
> Are you aware of the lazy static final fields proposal ?
>   https://bugs.openjdk.org/browse/JDK-8209964
>
> In think both proposals should be merged.
>
> R?mi
>
> ------------------------------
>
> *From: *"Per-Ake Minborg" <per-ake.minborg at oracle.com>
> <per-ake.minborg at oracle.com>
> *To: *"leyden-dev" <leyden-dev at openjdk.org> <leyden-dev at openjdk.org>
> *Sent: *Thursday, July 27, 2023 5:52:46 PM
> *Subject: *Draft JEP Announcement: "Computed Constants"
>
> Hi all,
>
>   Maurizio and I have drafted a JEP for computed constants, which are
>   immutable value holders that are initialized at most once.  They offer
>   the performance and safety benefits of final fields while offering
>   greater flexibility as to the timing of initialization.  In the
>   context of Leyden, they could be one basis for shifting computation
>   both forward and backward in time.
>
>   The draft is here:https://openjdk.org/jeps/8312611
>
>   Now that the Leyden repo is open, I?ll publish the prototype code to a
>   new branch there shortly.
>
>   Comments are welcome!
>
>   Best, Per
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/27c9b5a6/attachment.htm>

From maurizio.cimadamore at oracle.com  Fri Jul 28 09:43:38 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 28 Jul 2023 10:43:38 +0100
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAJL5A3=if3JKGDF9RD5LX9CKrPd5QpsXuoeKCfWL3V1vSsBAgA@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
 <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJL5A3=if3JKGDF9RD5LX9CKrPd5QpsXuoeKCfWL3V1vSsBAgA@mail.gmail.com>
Message-ID: <5582cc5f-57f6-2509-ef99-5ca12d6abb4a@oracle.com>


On 28/07/2023 10:23, Glavo wrote:
>
>     I share your view that it is important to be able to use
>     ComputedConstant "early" in the VM startup sequence. There is
>     nothing inherent to the proposed API that *requires* a lambda or a
>     method reference to be used. An anonymous or regular class,
>     implementing Supplier would also do. Also, there is nothing
>     fundamental that prevents us from *implementing* the API in a way
>     it can be used "early".
>
>
> If anonymous classes need to be used, what is its advantage over the 
> initialization-on-demand holder idiom?
> It seems to be completely inferior to initialization-on-demand holder 
> idiom, except for being able to use it as instance fields.

Note that, using a ComputedConstant _list_ you can have a single 
supplier to serve a big number of computed constants. This is something 
that the holder idiom cannot do (and IMHO, _the_ most useful thing 
provided by the API).

To make a concrete example - jextract generates classes with lots of 
constants (MethodHandles, VarHandles and MemoryLayouts).

To make startup acceptable, we have to "aplit" the constants into 
several holder class.

When extracting sizeable libraries, it is common to have hundreds of 
such holder classes. So, peak performance and startup comes at a 
footprint cost.

We have made an experiment to tweak jextract generation to use a list of 
computed constants instead with a _single_ supplier. The index passed to 
the list is the index of the constant jextract wants to retrieve 
(basically think of this as a dynamic constant pool implementation).

This gives better startup that with the split holder idiom we use today, 
same peak performance (because all constants are still treated as such 
by C2, even if initialized lazily) and gneerates _one_ class instead of 
hundreds.

Maurizio

>
> Glavo
>
> On Fri, Jul 28, 2023 at 3:29?PM Per-Ake Minborg 
> <per-ake.minborg at oracle.com> wrote:
>
>     Hi R?mi,
>
>     I share your view that it is important to be able to use
>     ComputedConstant "early" in the VM startup sequence. There is
>     nothing inherent to the proposed API that *requires* a lambda or a
>     method reference to be used. An anonymous or regular class,
>     implementing Supplier would also do. Also, there is nothing
>     fundamental that prevents us from *implementing* the API in a way
>     it can be used "early".
>
>     We do not add any keywords, the JEP is a pure library approach so,
>     I do not foresee any backward compatibility issues.
>
>     Thanks for your feedback.
>
>     Best, Per
>     ------------------------------------------------------------------------
>     *From:* forax at univ-mlv.fr <forax at univ-mlv.fr>
>     *Sent:* Thursday, July 27, 2023 6:36 PM
>     *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>     *Cc:* Per-Ake Minborg <per-ake.minborg at oracle.com>; leyden-dev
>     <leyden-dev at openjdk.org>; John Rose <john.r.rose at oracle.com>
>     *Subject:* [External] : Re: Draft JEP Announcement: "Computed
>     Constants"
>
>
>     ------------------------------------------------------------------------
>
>         *From: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>         *To: *"Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg"
>         <per-ake.minborg at oracle.com>
>         *Cc: *"leyden-dev" <leyden-dev at openjdk.org>, "John Rose"
>         <john.r.rose at oracle.com>
>         *Sent: *Thursday, July 27, 2023 6:14:48 PM
>         *Subject: *Re: Draft JEP Announcement: "Computed Constants"
>
>         Hi Remi
>         Yes, of course we were aware of that.
>
>         Think of this proposal as an API-driven approach (in the style
>         of ThreadLocal, ClassValue, ScopedValue, ...) which delivers
>         more or less the same feature, but w/o changing the language.
>
>
>         One thing that's attractive about the API approach is that it
>         is not limited to just static fields, but it can also work for
>         instance fields as well.
>
>
>         (that said, I agree the two jeps should somehow be
>         related/link to each other)
>
>
>     I see two problems with your suggested approach:
>     - this proposal is on top of lambdas, which means that it can be
>     used for applications but not for the VM startup because it can
>     only be used after method handles sub-system have been initialized.
>     - this is not a backward compatible change, if you add a new
>     keyword to static final fields, you can rewrite any public static
>     final fields to a public lazy static final field,
>     ? by example, String.CASE_INSENSITIVE_ORDER which is rarely used
>     but can not be changed with your proposal.
>
>
>         Maurizio
>
>
>     R?mi
>
>
>         On 27/07/2023 17:09, Remi Forax wrote:
>
>             Hello,
>             Are you aware of the lazy static final fields proposal ?
>             https://bugs.openjdk.org/browse/JDK-8209964
>
>             In think both proposals should be merged.
>
>             R?mi
>
>             ------------------------------------------------------------------------
>
>                 *From: *"Per-Ake Minborg" <per-ake.minborg at oracle.com>
>                 <mailto:per-ake.minborg at oracle.com>
>                 *To: *"leyden-dev" <leyden-dev at openjdk.org>
>                 <mailto:leyden-dev at openjdk.org>
>                 *Sent: *Thursday, July 27, 2023 5:52:46 PM
>                 *Subject: *Draft JEP Announcement: "Computed Constants"
>
>                 Hi all,
>
>                 Maurizio and I have drafted a JEP for computed
>                 constants, which are
>                 immutable value holders that are initialized at most
>                 once.? They offer
>                 the performance and safety benefits of final fields
>                 while offering
>                 greater flexibility as to the timing of
>                 initialization.? In the
>                 context of Leyden, they could be one basis for
>                 shifting computation
>                 both forward and backward in time.
>
>                 The draft is here:https://openjdk.org/jeps/8312611
>
>                 Now that the Leyden repo is open, I?ll publish the
>                 prototype code to a
>                 new branch there shortly.
>
>                 Comments are welcome!
>
>                 Best, Per
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/998c2e56/attachment.htm>

From forax at univ-mlv.fr  Fri Jul 28 11:08:40 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 28 Jul 2023 13:08:40 +0200 (CEST)
Subject: ComputedConstant.ofEmpty() javadoc has a reference to a method that
 does not exist
Message-ID: <395248163.4804795.1690542520949.JavaMail.zimbra@univ-eiffel.fr>

Hi Per,
in the javadoc referenced by the JEP, the doc of ofEmpty() has the following snippet of code

         private static final ComputedConstant<Foo> FOO = ComputedConstant.ofEmpty();

         public Foo theBar() {
             // Foo is lazily constructed and recorded here upon first invocation
             return FOO.computeIfUnbound(Foo::new);
         }

I was not able to find a description of the method computeIfUnbound ?

regards,
R?mi

From aph at redhat.com  Fri Jul 28 11:21:38 2023
From: aph at redhat.com (Andrew Haley)
Date: Fri, 28 Jul 2023 12:21:38 +0100
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <85cf5265-f8e1-983b-48e0-c3b1494572c0@redhat.com>

On 7/27/23 16:52, Per-Ake Minborg wrote:

>  ? Comments are welcome!
Typo:

  the API dynamically detects circular dependencies and throws a StackOverflowException when a circularity is found:

s/StackOverflowError/StackOverflowException/

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From forax at univ-mlv.fr  Fri Jul 28 13:18:03 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 28 Jul 2023 15:18:03 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <1880656954.4833135.1690550283535.JavaMail.zimbra@univ-eiffel.fr>

I've re-implemented the API without VM support or directly using @Stable (the JDK already provides List.of()), it works with Java 17+. 
[ https://github.com/forax/computed-constant | https://github.com/forax/computed-constant ] 

The API seems quite good, apart ComputedConstant.isBinding(), I see the purpose of it when debugging but at the same time I fear people will use it in a busy loop. 

regards, 
R?mi 

> From: "Per-Ake Minborg" <per-ake.minborg at oracle.com>
> To: "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Thursday, July 27, 2023 5:52:46 PM
> Subject: Draft JEP Announcement: "Computed Constants"

> Hi all,

> Maurizio and I have drafted a JEP for computed constants, which are
> immutable value holders that are initialized at most once. They offer
> the performance and safety benefits of final fields while offering
> greater flexibility as to the timing of initialization. In the
> context of Leyden, they could be one basis for shifting computation
> both forward and backward in time.

> The draft is here: [ https://openjdk.org/jeps/8312611 |
> https://openjdk.org/jeps/8312611 ]

> Now that the Leyden repo is open, I?ll publish the prototype code to a
> new branch there shortly.

> Comments are welcome!

> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/49e3dfb5/attachment.htm>

From brian.goetz at oracle.com  Fri Jul 28 15:06:07 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 28 Jul 2023 11:06:07 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
 <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <bb968afb-d335-1fcc-21dc-4311f831016b@oracle.com>



> I share your view that it is important to be able to use 
> ComputedConstant "early" in the VM startup sequence. There is nothing 
> inherent to the proposed API that *requires* a lambda or a method 
> reference to be used. An anonymous or regular class, implementing 
> Supplier would also do. Also, there is nothing fundamental that 
> prevents us from *implementing* the API in a way it can be used "early".
>
> We do not add any keywords, the JEP is a pure library approach so, I 
> do not foresee any backward compatibility issues.

Allow me to translate ...

Remi was assuming a goal.? The problem is that he didn't state that 
goal, or his assumption that this was a goal, before jumping to 
criticizing your proposal.? As a result, his criticism was unclear, and 
IMO misplaced.

The hidden goal that Remi was assuming is that "it should be possible to 
migrate existing code that uses static final fields to use computed 
constants in a source- and binary-compatible way." Now, it should have 
been entirely clear from content that this was a non-goal of this JEP 
(you didn't propose a language or VM solution, and that was clearly 
deliberate), and if he wanted to express his disappointment, he should 
have done so more directly, such as "I wish there was a way to let old 
code play in this game."? To which the answer would have been "We may 
get there someday, some day, but we're starting with something simpler."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/15ed30e1/attachment.htm>

From heidinga at redhat.com  Fri Jul 28 15:53:31 2023
From: heidinga at redhat.com (Dan Heidinga)
Date: Fri, 28 Jul 2023 11:53:31 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>

First off, congrats Per and Maurizio for such a clear well written draft
JEP and for finding a library solution to this problem.  It's great work!

I've spent a lot of time looking into "unscrambling the <clinit> egg"
through the use of the IDOH pattern, GraalVM's Substitution mechanism,
qbicc's per-field <rtinit> method(s) and I'm pretty happy with the approach
you've taken here as it provides an essential building block for decoupling
state in <clinit> for new classes.  One of the challenges in this space has
been trying to discern / reverse-engineer the developer's intent after the
fact from the very conjoined <clinit> method.  This approach provides
developers a way to easily separate out each field's initialization code
and lifecycle from the other static fields in a class.

With my "optimizing startup hat on", I share some of the concerns others
have expressed about the use of lambdas to initialize ComputedConstant as
it exposes the lambda cost model to end users - users now need to
understand if the cost of the lambda generation (inflation?  Not sure what
the right term is for converting a lambda expression to a functional
interface instance) will be more or less than the cost of the computation
they want to store in a ComputedConstant if they want to realize a startup
benefit from this change.

While Per and Maurizio have already suggested partial solutions for this -
use an anonymous class, a predefined Supplier instance, or
ComputedConstant.ofList - I'm slightly concerned this can become a
tragedy of the commons like problem where multiple classes in an
application - or even multiple libraries - each use ComputedConstant.of()
and see an improvement for their use class, but a degradation when all are
put together in a single application.  Maurizio indicates they saw exactly
this problem with jextract and were able to use the
ComputedConstant.ofList() to address it, but that's when all uses are from
a single source and can be updated together.  Do you have any thoughts on
how to avoid this unstable state where using more ComputedConstants might
regress startup?

As suggested in the "Dependencies" section of the JEP, this may enable
pre-evaluating computed constants.  Given that goal, should language like
the following sentence from the java.util.concurrent.constant package
summary javadoc be avoid?
> In other words, a provider can only run once and in the first-calling
thread and so, there is no race across threads which guarantees the
at-most-once evaluation
This defines when the provider is called which may need to be adapted if
time-shifting a ComputedConstant becomes possible.  Is it better to avoid
the "first-calling thread" claim from the start?

>From the java.util.concurrent.constant.ComputedConstant javadoc:
> If a thread calls this method while being bound by another thread, the
current thread will be suspended until the binding completes (successfully
or not). Otherwise, this method is guaranteed to be lock-free.
Which lock is being used to serialize the computation?  Is it the same lock
used for serializing access to <clinit> or is some other lock for just the
constants or....?  Using the same lock as <clinit> may lead to similar
surprising deadlocks as when the appserver folk were first experimenting
with more complex classloading designs (ie: osgi, others) which took many
years to resolve so I'd suggest picking something unrelated if possible.

Again, I think this is a great building block and I'm excited to see it
being proposed.

--Dan


On Thu, Jul 27, 2023 at 11:53?AM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Hi all,
>
>   Maurizio and I have drafted a JEP for computed constants, which are
>   immutable value holders that are initialized at most once.  They offer
>   the performance and safety benefits of final fields while offering
>   greater flexibility as to the timing of initialization.  In the
>   context of Leyden, they could be one basis for shifting computation
>   both forward and backward in time.
>
>   The draft is here: https://openjdk.org/jeps/8312611
>
>   Now that the Leyden repo is open, I?ll publish the prototype code to a
>   new branch there shortly.
>
>   Comments are welcome!
>
>   Best, Per
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/6474d39f/attachment.htm>

From brian.goetz at oracle.com  Fri Jul 28 16:21:54 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 28 Jul 2023 12:21:54 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
Message-ID: <bc02e6fb-a8ef-1cf2-727b-7161ad6d08d2@oracle.com>



On 7/28/2023 11:53 AM, Dan Heidinga wrote:
>
> With my "optimizing startup hat on", I share some of the concerns 
> others have expressed about the use of lambdas to initialize 
> ComputedConstant as it exposes the lambda cost model to end users - 
> users now need to understand if the cost of the lambda generation 
> (inflation?? Not sure what the right term is for converting a lambda 
> expression to a functional interface instance) will be more or less 
> than the cost of the computation they want to store in a 
> ComputedConstant if they want to realize a startup benefit from this 
> change.

I share the concern, though I think we can address that as a separate 
follow-on topic.

Given a computed constant

 ??? public static final ComputedConstant<String> swellGuy = 
ComputedConstant.of(() -> "Dan");

the lambda `() -> "Dan"` is likely to be fairly constrained.? It is 
unlikely to be aliased, it is only going to be called once, it doesn't 
capture any state from the lexical environment, etc.? A condenser could 
easily refactor this (assuming the above constraints are observed to be 
true) to move the body `{ return "Dan"; }` to a private static method in 
the same class, and rewrite the CC declaration to

 ??? ... = ComputedConstant.of( Constant_MethodHandle[private method] );

This eliminates the proxy class / anon class.? The CC API can be 
designed in such a way to permit such lowerings, and paired with a 
condenser that understands the necessarily constraints (a MH overload 
factory is entirely reasonable.)

A separate condenser might pre-resolve the MH constant and put it in the 
CDS archive, on the observation that it may be needed early.

> As suggested in the "Dependencies" section of the JEP, this may enable 
> pre-evaluating computed constants.? Given that goal, should language 
> like the following sentence from the java.util.concurrent.constant 
> package summary javadoc be avoid?
> >?In other words, a provider can only run once and in the 
> first-calling thread and so, there is no race across threads which 
> guarantees the at-most-once evaluation
> This defines when the provider is called which may need to be adapted 
> if time-shifting a ComputedConstant becomes possible.? Is it better to 
> avoid the "first-calling thread" claim from the start?

Yes, I think this was probably a leftover from an earlier draft. The 
sensible constraint is "no later than first use", leaving early 
initialization wide open to be specified by a separate mechanism.



From maurizio.cimadamore at oracle.com  Fri Jul 28 16:25:14 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 28 Jul 2023 17:25:14 +0100
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <bc02e6fb-a8ef-1cf2-727b-7161ad6d08d2@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <bc02e6fb-a8ef-1cf2-727b-7161ad6d08d2@oracle.com>
Message-ID: <fec77d78-f79d-e4cf-9143-7418a19eff6b@oracle.com>


On 28/07/2023 17:21, Brian Goetz wrote:
> (a MH overload factory is entirely reasonable.) 

This was also what I was tinkering with when thinking about Dan's question.

Maurizio


From maurizio.cimadamore at oracle.com  Fri Jul 28 16:28:38 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 28 Jul 2023 17:28:38 +0100
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <fec77d78-f79d-e4cf-9143-7418a19eff6b@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <bc02e6fb-a8ef-1cf2-727b-7161ad6d08d2@oracle.com>
 <fec77d78-f79d-e4cf-9143-7418a19eff6b@oracle.com>
Message-ID: <55a09a62-8b46-dba4-895d-2258643a9bbc@oracle.com>


On 28/07/2023 17:25, Maurizio Cimadamore wrote:
>
> On 28/07/2023 17:21, Brian Goetz wrote:
>> (a MH overload factory is entirely reasonable.) 
>
> This was also what I was tinkering with when thinking about Dan's 
> question.

Hit send too fast. There's other avenues to explore to. For instance, 
lambdas that have same signature and captured state might be able to 
share the same class (e.g. by accepting a MH as construction parameter 
and stashing it in a private "trusted" final field). This should deliver 
footprint savings not just for computed constants, but for all 
lambda-heavy APIs (e.g. classfile API, streams). That said, pulling that 
off, and in a way that doesn't break C2 optimizations might be hard (I'd 
suspect that each lambda having its distinct nominal class gives C2 a 
lot of room to speculate).

Maurizio

>
> Maurizio
>

From john.r.rose at oracle.com  Fri Jul 28 18:35:30 2023
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 28 Jul 2023 11:35:30 -0700
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
Message-ID: <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>

On 28 Jul 2023, at 8:53, Dan Heidinga wrote:

> ? users now need to
> understand if the cost of the lambda generation (inflation?  Not sure what
> the right term is for converting a lambda expression to a functional
> interface instance) will be more or less than the cost of the computation
> they want to store in a ComputedConstant if they want to realize a startup
> benefit from this change.

Yes, this problem of scaling is raised by the very existence of a better alternative to <clinit>:  Can it beat <clinit> robustly or must it be used sparingly, because the language and VM don?t optimize it very well?

I would like to take CC?s as they are proposed here, and then expand their mission.  (?After some shallow name changes: package should be java.lang and s/ofList/list/ or s/ofList/of/.)

After that there are things we can do to reduce their footprint (in cycles and memory, and in user experience), so as to make them much more attractive as an everyday alternative to <clinit>-based fields.  Such ?things? might be condensers (as Brian also mentions), or maybe language and JVM support.  In any case, the goal would be to help users make a clean escape from the clutches of <clinit>, for the sake of static tools.

This will be a followup exercise to CC?s.  I?ve written some thoughts about that here, FTR:

https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html

In short:  I think the sweet spot for a condenser target here is not an array of MHs as Brian suggests, but rather a single static method with a string-switch, and a framework for invoking it reflectively from a public BSM of some sort.

From john.r.rose at oracle.com  Fri Jul 28 18:38:05 2023
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 28 Jul 2023 11:38:05 -0700
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <55a09a62-8b46-dba4-895d-2258643a9bbc@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <bc02e6fb-a8ef-1cf2-727b-7161ad6d08d2@oracle.com>
 <fec77d78-f79d-e4cf-9143-7418a19eff6b@oracle.com>
 <55a09a62-8b46-dba4-895d-2258643a9bbc@oracle.com>
Message-ID: <43D84178-59FE-4D99-99A4-929518668714@oracle.com>

On 28 Jul 2023, at 9:28, Maurizio Cimadamore wrote:

> On 28/07/2023 17:25, Maurizio Cimadamore wrote:
>>
>> On 28/07/2023 17:21, Brian Goetz wrote:
>>> (a MH overload factory is entirely reasonable.)
>>
>> This was also what I was tinkering with when thinking about Dan's question.
>
> Hit send too fast. There's other avenues to explore to. For instance, lambdas that have same signature and captured state might be able to share the same class (e.g. by accepting a MH as construction parameter and stashing it in a private "trusted" final field). This should deliver footprint savings not just for computed constants, but for all lambda-heavy APIs (e.g. classfile API, streams). That said, pulling that off, and in a way that doesn't break C2 optimizations might be hard (I'd suspect that each lambda having its distinct nominal class gives C2 a lot of room to speculate).

Maybe, but (as you suspect) C2 likes distinct lambdas, if they are going to be invoked many times.

The lambdas for CCs are by definition invoked only once, so they should be optimized more for space than for speed.  That?s why I suggest rolling all the initializers in a single class (or as single package???) into one big method with a string-switch.  That big guy doesn?t optimize well, but nobody will ever care, and he takes up the least possible space.  Just like <clinit>.  In fact, that?s how you get parity with <clinit>, defining $fieldinit$ as an alternative, better organized container for initializers.

From heidinga at redhat.com  Fri Jul 28 20:18:59 2023
From: heidinga at redhat.com (Dan Heidinga)
Date: Fri, 28 Jul 2023 16:18:59 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
Message-ID: <CAJq4Gi5BtLncLZsFuyGaJfk=+Z73O-r9sw49xvyUw11z4_F2Ag@mail.gmail.com>

On Fri, Jul 28, 2023 at 2:35?PM John Rose <john.r.rose at oracle.com> wrote:

> On 28 Jul 2023, at 8:53, Dan Heidinga wrote:
>
> > ? users now need to
> > understand if the cost of the lambda generation (inflation?  Not sure
> what
> > the right term is for converting a lambda expression to a functional
> > interface instance) will be more or less than the cost of the computation
> > they want to store in a ComputedConstant if they want to realize a
> startup
> > benefit from this change.
>
> Yes, this problem of scaling is raised by the very existence of a better
> alternative to <clinit>:  Can it beat <clinit> robustly or must it be used
> sparingly, because the language and VM don?t optimize it very well?
>
> I would like to take CC?s as they are proposed here, and then expand their
> mission.  (?After some shallow name changes: package should be java.lang
> and s/ofList/list/ or s/ofList/of/.)
>
> After that there are things we can do to reduce their footprint (in cycles
> and memory, and in user experience), so as to make them much more
> attractive as an everyday alternative to <clinit>-based fields.


I'm with you on that goal.


> Such ?things? might be condensers (as Brian also mentions),


As much as I want condensers (please, let's get condensers asap!), I'm
concerned that features which depend on condensers to get good performance
will live in an unstable state unless we can make running condensers so
cheap and routine and natural that doing so fits in developers workflows -
especially when debugging from within their IDEs.  Features that are
painful (and I'm not saying CC's are) at development time, even if great at
deployment time, tend to have lower adoption and aren't "sticky" as devs
avoid them.

Unscrambling <clinit> is an essential part of the work Leyden needs to do
and CCs are a great step forward on that path.  Now the JVM needs to find a
way to routinely optimize them so even uncondensed uses are an obvious
choice for developers.



> or maybe language and JVM support.  In any case, the goal would be to help
> users make a clean escape from the clutches of <clinit>, for the sake of
> static tools.
>
> This will be a followup exercise to CC?s.  I?ve written some thoughts
> about that here, FTR:
>
> https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html
>
> In short:  I think the sweet spot for a condenser target here is not an
> array of MHs as Brian suggests, but rather a single static method with a
> string-switch, and a framework for invoking it reflectively from a public
> BSM of some sort.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/92fb1f86/attachment.htm>

From forax at univ-mlv.fr  Fri Jul 28 20:40:56 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 28 Jul 2023 22:40:56 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <bb968afb-d335-1fcc-21dc-4311f831016b@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <1265545759.4350538.1690474147671.JavaMail.zimbra@univ-eiffel.fr>
 <ba2c9471-0052-bd7a-1e78-aefd3397c052@oracle.com>
 <534086640.4352191.1690475760233.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <bb968afb-d335-1fcc-21dc-4311f831016b@oracle.com>
Message-ID: <1061711559.4898619.1690576856766.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Per-Ake Minborg" <per-ake.minborg at oracle.com>, "Remi Forax"
> <forax at univ-mlv.fr>, "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "leyden-dev" <leyden-dev at openjdk.org>, "John Rose" <john.r.rose at oracle.com>
> Sent: Friday, July 28, 2023 5:06:07 PM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

>> I share your view that it is important to be able to use ComputedConstant
>> "early" in the VM startup sequence. There is nothing inherent to the proposed
>> API that *requires* a lambda or a method reference to be used. An anonymous or
>> regular class, implementing Supplier would also do. Also, there is nothing
>> fundamental that prevents us from *implementing* the API in a way it can be
>> used "early".

>> We do not add any keywords, the JEP is a pure library approach so, I do not
>> foresee any backward compatibility issues.

> Allow me to translate ...

> Remi was assuming a goal. The problem is that he didn't state that goal, or his
> assumption that this was a goal, before jumping to criticizing your proposal.
> As a result, his criticism was unclear, and IMO misplaced.

> The hidden goal that Remi was assuming is that "it should be possible to migrate
> existing code that uses static final fields to use computed constants in a
> source- and binary-compatible way." Now, it should have been entirely clear
> from content that this was a non-goal of this JEP (you didn't propose a
> language or VM solution, and that was clearly deliberate), and if he wanted to
> express his disappointment, he should have done so more directly, such as "I
> wish there was a way to let old code play in this game." To which the answer
> would have been "We may get there someday, some day, but we're starting with
> something simpler."
You are making the assumption that you can not have both, a binary-compatible way of moving things out of the static init block and a solution not based on a keyword. 
I do not think this is true. 

In my opinion, what this JEP got right is to try to tag what can be moved out of a static init block, making the job of a condenser easier. 
But this JEP still allows 
- any codes to create a ComputedConstant, you can create a ComputedConstant from the content of a HTTP request, 
- a ComputedConstant can be part of the API (public field), so it can not be elided, 
- multiple fields to be initialized by one ComputedConstant. 
All those things are making the implementation of a condenser far harder than it should. 

But i'm sure, i'm wrong and there is already a written condenser somewhere that shows that i'm just a naysayer not able to see how simple the ComputedConstant API really is. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/0d5f51d4/attachment.htm>

From forax at univ-mlv.fr  Fri Jul 28 20:53:55 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 28 Jul 2023 22:53:55 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
Message-ID: <1465149868.4898938.1690577635807.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Dan Heidinga" <heidinga at redhat.com>
> Cc: "Per-Ake Minborg" <per-ake.minborg at oracle.com>, "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Friday, July 28, 2023 8:35:30 PM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

> On 28 Jul 2023, at 8:53, Dan Heidinga wrote:
> 
>> ? users now need to
>> understand if the cost of the lambda generation (inflation?  Not sure what
>> the right term is for converting a lambda expression to a functional
>> interface instance) will be more or less than the cost of the computation
>> they want to store in a ComputedConstant if they want to realize a startup
>> benefit from this change.
> 
> Yes, this problem of scaling is raised by the very existence of a better
> alternative to <clinit>:  Can it beat <clinit> robustly or must it be used
> sparingly, because the language and VM don?t optimize it very well?
> 
> I would like to take CC?s as they are proposed here, and then expand their
> mission.  (?After some shallow name changes: package should be java.lang and
> s/ofList/list/ or s/ofList/of/.)
> 
> After that there are things we can do to reduce their footprint (in cycles and
> memory, and in user experience), so as to make them much more attractive as an
> everyday alternative to <clinit>-based fields.  Such ?things? might be
> condensers (as Brian also mentions), or maybe language and JVM support.  In any
> case, the goal would be to help users make a clean escape from the clutches of
> <clinit>, for the sake of static tools.
> 
> This will be a followup exercise to CC?s.  I?ve written some thoughts about that
> here, FTR:
> 
> https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html
> 
> In short:  I think the sweet spot for a condenser target here is not an array of
> MHs as Brian suggests, but rather a single static method with a string-switch,
> and a framework for invoking it reflectively from a public BSM of some sort.

I'm fine with a method <class-field-init> that takes an int (the index from the AutonomousValue attribute) and returns an Object to initialize each autonomous field at the first call. For me, there is no need for a BSM here.

Also I prefer the CC initialization semantics (the field initializer is only executed once) to the one you are using in your prototype, the field initializer can be called several times concurrently but only store the first value that complete.

R?mi

From john.r.rose at oracle.com  Fri Jul 28 23:58:49 2023
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 28 Jul 2023 16:58:49 -0700
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <1465149868.4898938.1690577635807.JavaMail.zimbra@univ-eiffel.fr>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
 <1465149868.4898938.1690577635807.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CC5D6973-0758-4F3F-AE0C-12516E38617B@oracle.com>

On 28 Jul 2023, at 13:53, Remi Forax wrote:

> I'm fine with a method <class-field-init> that takes an int (the index from the AutonomousValue attribute) and returns an Object to initialize each autonomous field at the first call. For me, there is no need for a BSM here.
>
> Also I prefer the CC initialization semantics (the field initializer is only executed once) to the one you are using in your prototype, the field initializer can be called several times concurrently but only store the first value that complete.

Yeah, after polishing my prototype it might end up somewhere like that.

The benefit of the CC stuff is that it can clearly provide and document the correct high-level semantics.  And the low-level VM machinery can be simpler (fewer guarantees), right?  Or we could do an all-in-one solution where the JVMS promises to mimic the CC logic example.

But I prefer a layered design, where the VM uses a BSM to route through the CC logic, which then elevates the result to what the JLS or the CC API will guarantee.  So the VM can use the condy-like binding it is accustomed to, which uses CC directly to get the right mutex behavior.

From forax at univ-mlv.fr  Sat Jul 29 15:25:30 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 29 Jul 2023 17:25:30 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CC5D6973-0758-4F3F-AE0C-12516E38617B@oracle.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
 <1465149868.4898938.1690577635807.JavaMail.zimbra@univ-eiffel.fr>
 <CC5D6973-0758-4F3F-AE0C-12516E38617B@oracle.com>
Message-ID: <1892441985.5264560.1690644330643.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Dan Heidinga" <heidinga at redhat.com>, "Per-Ake Minborg" <per-ake.minborg at oracle.com>, "leyden-dev"
> <leyden-dev at openjdk.org>
> Sent: Saturday, July 29, 2023 1:58:49 AM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

> On 28 Jul 2023, at 13:53, Remi Forax wrote:
> 
>> I'm fine with a method <class-field-init> that takes an int (the index from the
>> AutonomousValue attribute) and returns an Object to initialize each autonomous
>> field at the first call. For me, there is no need for a BSM here.
>>
>> Also I prefer the CC initialization semantics (the field initializer is only
>> executed once) to the one you are using in your prototype, the field
>> initializer can be called several times concurrently but only store the first
>> value that complete.
> 
> Yeah, after polishing my prototype it might end up somewhere like that.
> 
> The benefit of the CC stuff is that it can clearly provide and document the
> correct high-level semantics.  

yes !

>. And the low-level VM machinery can be simpler
> (fewer guarantees), right?  Or we could do an all-in-one solution where the
> JVMS promises to mimic the CC logic example.
> 
> But I prefer a layered design, where the VM uses a BSM to route through the CC
> logic, which then elevates the result to what the JLS or the CC API will
> guarantee.  So the VM can use the condy-like binding it is accustomed to, which
> uses CC directly to get the right mutex behavior.

I do not think a layered design will be the end game, paying the transition through a BSM for each initialization may be more expensive that the initialization of the constant itself. That's one of the challenge of the computed constants, we know the initialization is done only once, so the VM has to be more than with invokedynamic / constant dynamic. 
So in the end, my gut feeling is that the VM will have to do the job, like it does currently with a <clinit>.

But the layered design / using a BSM is a nice middle step, to help us to find the right semantics.

R?mi

From forax at univ-mlv.fr  Sun Jul 30 21:04:23 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 30 Jul 2023 23:04:23 +0200 (CEST)
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <1025974116.5707580.1690751063100.JavaMail.zimbra@univ-eiffel.fr>

Hi all, 
I've spent some time to try to improve the API given the constraints, 
- an API instead of a language feature, 
- distangle the fields initialized lazily from the ones initialized in the <clinit>, 
- the initialization code is made thread safe and executed exactly once, 
- as fast as a static final constant when c2 optimize the code, 
- condenser friendly, 
- can evolve to a langage feature in the future. 

I've re-used the idea of John of having one method able to initialize all the computed/autonomous fields, but it uses strings instead of ints because ints are not very user friendly :) 
I have one central object per class, i've called it FieldInit but I'm sure there is a better name. It it only able to initialize the field of the lookup class taken as parameter (I hope the current class). 
It has one method get(fieldName) that takes a field name as parameter and return the corresponding value lazily initialized. There are also overloads for all primitive types but it's more for convenience than anything else. The semantics for the initialization is the same as with a computed constant (I hope I get this right). 

public class Main { 
private static final FieldInit FIELD_INIT = FieldInit . ofStatic ( MethodHandles . lookup ()); 

private static Object $staticFieldInit$ ( String fieldName) { 
return switch (fieldName) { 
case "X" -> 42 ; 
case "HELLO" -> "hello field init !" ; 
default -> throw new AssertionError( "unknown " + fieldName); 
}; 
} 

private static int X ; 
private static String HELLO ; 

public static void main ( String [] args) { 
System . out .println( FIELD_INIT .getInt( "X" ));  // 42 
System . out .println( FIELD_INIT .< String >get( "HELLO" ));  // hello field init 
} 
} 

Major issues with that API, 
- it's string based so a renaming of one of the computed/autonomous field will make the corresponding FieldInit.get() to fail at runtime with a NoSuchFieldError, 
- it's not typesafe, a user can ask for the value of an int field as a String, it will fail at runtime with a ClassCastException, 
- if a code that directly access to a computed/autonomous field instead of using FieldInit.get() may see either the default value or the intialized value (don't do that), 
- the implementation put a lot more pressure to the JIT so the time to steady state may be delayed compared to a solution without computed/autonomous fields. 

The implementation is available here: 
https://github.com/forax/computed-constant/tree/master/field-init/src/main/java/com/github/forax/concurrent/constant 

The time to access to static final constant and to access to static constant through FieldInit.get() is identical once c2 JIT the code. 
Benchmark Mode Cnt Score Error Units 
Benchmarks.static_constant_get_42 avgt 5 0.316 ? 0.001 ns/op 
Benchmarks.static_constant_get_null avgt 5 0.316 ? 0.001 ns/op 
Benchmarks.static_field_init_get_42 avgt 5 0.315 ? 0.001 ns/op 
Benchmarks.static_field_init_get_null avgt 5 0.316 ? 0.001 ns/op 

I've not implemented the initialization of the instance field, mostly because I want feedback on this proposal before going further and unlike with a computed constant, there is a problem to make the difference between an uninitialized value and a default value of an instance field. 
regards, 
R?mi 

PS: There is also possible implementation using a template processor especially if it implements TemplatedString.Processor.Linkage. Something like FieldInitProcessor."X". Sadly, FieldInitProcessor.<Integer>"X" is not legal, there is no easy way to specify a return type. 

> From: "Per-Ake Minborg" <per-ake.minborg at oracle.com>
> To: "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Thursday, July 27, 2023 5:52:46 PM
> Subject: Draft JEP Announcement: "Computed Constants"

> Hi all,

> Maurizio and I have drafted a JEP for computed constants, which are
> immutable value holders that are initialized at most once. They offer
> the performance and safety benefits of final fields while offering
> greater flexibility as to the timing of initialization. In the
> context of Leyden, they could be one basis for shifting computation
> both forward and backward in time.

> The draft is here: [ https://openjdk.org/jeps/8312611 |
> https://openjdk.org/jeps/8312611 ]

> Now that the Leyden repo is open, I?ll publish the prototype code to a
> new branch there shortly.

> Comments are welcome!

> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230730/08c8cd29/attachment.htm>

From per-ake.minborg at oracle.com  Mon Jul 31 07:05:49 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 31 Jul 2023 07:05:49 +0000
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAA9v-_OF=HVv0utmB9JV68p3fHCy=Nw+TcD7=7yL71kc2844Tg@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAA9v-_OF=HVv0utmB9JV68p3fHCy=Nw+TcD7=7yL71kc2844Tg@mail.gmail.com>
Message-ID: <DM6PR10MB42837584DB2E87A5E958BD55DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>

Hi David.

Thanks for the encouragement.

You can actually *reference* CC objects in a circular way as long as you do not create circularity in the *evaluation* of CC objects. So, it is, for example, perfectly legal to query if a CC is bound via the isBound() method in a circular way.

Just to remind you, initialization can only be made at most once per CC instance/element.

Best, Per
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Thursday, July 27, 2023 7:27 PM
To: Per-Ake Minborg <per-ake.minborg at oracle.com>
Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"

Hello Per,

Thank you for posting this JEP!

It looks great. The solution is concise, clear, and simple, and any complaints I have about verbosity can be mostly addressed with var. And that list suggestion was especially nice. That's very neat.

I'd like to ask about the safety point. I certainly understand the reason why it exists -- some developers will inadvertently create a circular reference and end up causing problems.

However, I see a lot of utility for circular references too. Any chance that we could allow devs to opt-in to circular references?

Earlier this month, I started 2 threads that were broaching the subject of a very similar pain point to this one. Here they both are.

https://mail.openjdk.org/pipermail/amber-dev/2023-July/008129.html

https://mail.openjdk.org/pipermail/amber-dev/2023-July/008154.html

I'm curious how this Computed Constant solution would work out for the problem I have. But in order for it to work, it would need to enable circular references, hence my question.

But even without it, I see a lot of utility for this tool. I'm excited to get to work prototyping with it.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/c2b28a6e/attachment.htm>

From davidalayachew at gmail.com  Mon Jul 31 08:30:21 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 31 Jul 2023 04:30:21 -0400
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB42837584DB2E87A5E958BD55DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAA9v-_OF=HVv0utmB9JV68p3fHCy=Nw+TcD7=7yL71kc2844Tg@mail.gmail.com>
 <DM6PR10MB42837584DB2E87A5E958BD55DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_ODHZCRkNTGjN-okE4nL_q8nH2OGa1QMr-dLH0396rpYQ@mail.gmail.com>

Hello Per,

Thank you for the response!

I'm afraid I don't follow. Could you demonstrate what you mean?

Thank you for your time and help!
David Alayachew

On Mon, Jul 31, 2023 at 3:05?AM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Hi David.
>
> Thanks for the encouragement.
>
> You can actually *reference* CC objects in a circular way as long as you
> do not create circularity in the *evaluation* of CC objects. So, it is, for
> example, perfectly legal to query if a CC is bound via the isBound() method
> in a circular way.
>
> Just to remind you, initialization can only be made at most once per CC
> instance/element.
>
> Best, Per
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, July 27, 2023 7:27 PM
> *To:* Per-Ake Minborg <per-ake.minborg at oracle.com>
> *Cc:* leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* [External] : Re: Draft JEP Announcement: "Computed Constants"
>
> Hello Per,
>
> Thank you for posting this JEP!
>
> It looks great. The solution is concise, clear, and simple, and any
> complaints I have about verbosity can be mostly addressed with var. And
> that list suggestion was especially nice. That's very neat.
>
> I'd like to ask about the safety point. I certainly understand the reason
> why it exists -- some developers will inadvertently create a circular
> reference and end up causing problems.
>
> However, I see a lot of utility for circular references too. Any chance
> that we could allow devs to opt-in to circular references?
>
> Earlier this month, I started 2 threads that were broaching the subject of
> a very similar pain point to this one. Here they both are.
>
> https://mail.openjdk.org/pipermail/amber-dev/2023-July/008129.html
>
> https://mail.openjdk.org/pipermail/amber-dev/2023-July/008154.html
>
> I'm curious how this Computed Constant solution would work out for the
> problem I have. But in order for it to work, it would need to enable
> circular references, hence my question.
>
> But even without it, I see a lot of utility for this tool. I'm excited to
> get to work prototyping with it.
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/d2f7ff98/attachment.htm>

From per-ake.minborg at oracle.com  Mon Jul 31 09:41:57 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 31 Jul 2023 09:41:57 +0000
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAA9v-_ODHZCRkNTGjN-okE4nL_q8nH2OGa1QMr-dLH0396rpYQ@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAA9v-_OF=HVv0utmB9JV68p3fHCy=Nw+TcD7=7yL71kc2844Tg@mail.gmail.com>
 <DM6PR10MB42837584DB2E87A5E958BD55DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAA9v-_ODHZCRkNTGjN-okE4nL_q8nH2OGa1QMr-dLH0396rpYQ@mail.gmail.com>
Message-ID: <DM6PR10MB4283DA30D27933B4E772078ADA05A@DM6PR10MB4283.namprd10.prod.outlook.com>

Sorry for being unclear.

So, the API guarantees evaluation is made at most once, so it is an error to recursively invoke a value provider (which value would we then bind?). Consequently, there are no plans to allow circular evaluation.

However, you can check if another ComputedConstant isBound() from a provider for another ComputedConstant. It is also allowed to get() the bound value from other ComputedConstants as long as they do not query the querying ComputedConstant instance. For example, you might want to have a List<ComputedConstant<Integer>> that caches the Fibonacci series and when computing fib(n), you invoke fib(n-1) and fib(n-2) as the latter do not invoke fib(n).

I hope that clears things up.

Best, Per
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Monday, July 31, 2023 10:30 AM
To: Per-Ake Minborg <per-ake.minborg at oracle.com>
Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Re: [External] : Re: Draft JEP Announcement: "Computed Constants"

Hello Per,

Thank you for the response!

I'm afraid I don't follow. Could you demonstrate what you mean?

Thank you for your time and help!
David Alayachew

On Mon, Jul 31, 2023 at 3:05?AM Per-Ake Minborg <per-ake.minborg at oracle.com<mailto:per-ake.minborg at oracle.com>> wrote:
Hi David.

Thanks for the encouragement.

You can actually *reference* CC objects in a circular way as long as you do not create circularity in the *evaluation* of CC objects. So, it is, for example, perfectly legal to query if a CC is bound via the isBound() method in a circular way.

Just to remind you, initialization can only be made at most once per CC instance/element.

Best, Per
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Thursday, July 27, 2023 7:27 PM
To: Per-Ake Minborg <per-ake.minborg at oracle.com<mailto:per-ake.minborg at oracle.com>>
Cc: leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"

Hello Per,

Thank you for posting this JEP!

It looks great. The solution is concise, clear, and simple, and any complaints I have about verbosity can be mostly addressed with var. And that list suggestion was especially nice. That's very neat.

I'd like to ask about the safety point. I certainly understand the reason why it exists -- some developers will inadvertently create a circular reference and end up causing problems.

However, I see a lot of utility for circular references too. Any chance that we could allow devs to opt-in to circular references?

Earlier this month, I started 2 threads that were broaching the subject of a very similar pain point to this one. Here they both are.

https://mail.openjdk.org/pipermail/amber-dev/2023-July/008129.html

https://mail.openjdk.org/pipermail/amber-dev/2023-July/008154.html

I'm curious how this Computed Constant solution would work out for the problem I have. But in order for it to work, it would need to enable circular references, hence my question.

But even without it, I see a lot of utility for this tool. I'm excited to get to work prototyping with it.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/7d6b5d84/attachment.htm>

From davidalayachew at gmail.com  Mon Jul 31 10:46:44 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 31 Jul 2023 06:46:44 -0400
Subject: [External] : Re: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <DM6PR10MB4283DA30D27933B4E772078ADA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAA9v-_OF=HVv0utmB9JV68p3fHCy=Nw+TcD7=7yL71kc2844Tg@mail.gmail.com>
 <DM6PR10MB42837584DB2E87A5E958BD55DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAA9v-_ODHZCRkNTGjN-okE4nL_q8nH2OGa1QMr-dLH0396rpYQ@mail.gmail.com>
 <DM6PR10MB4283DA30D27933B4E772078ADA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PZ8mSDdEFBTwCrqBHQn=jv3Dr9WgC4ZiTbjngqr2XBGQ@mail.gmail.com>

It does help, thank you very much. I will have to play around with it to
make sure I do, but I think I see what you mean now.

On Mon, Jul 31, 2023 at 5:42?AM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Sorry for being unclear.
>
> So, the API guarantees evaluation is made at most once, so it is an error
> to recursively invoke a value provider (which value would we then bind?).
> Consequently, there are no plans to allow circular evaluation.
>
> However, you can check if another ComputedConstant isBound() from a
> provider for another ComputedConstant. It is also allowed to get() the
> bound value from other ComputedConstants as long as they do not query the
> querying ComputedConstant instance. For example, you might want to have a
> List<ComputedConstant<Integer>> that caches the Fibonacci series and when
> computing fib(n), you invoke fib(n-1) and fib(n-2) as the latter do not
> invoke fib(n).
>
> I hope that clears things up.
>
> Best, Per
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, July 31, 2023 10:30 AM
> *To:* Per-Ake Minborg <per-ake.minborg at oracle.com>
> *Cc:* leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Draft JEP Announcement: "Computed
> Constants"
>
> Hello Per,
>
> Thank you for the response!
>
> I'm afraid I don't follow. Could you demonstrate what you mean?
>
> Thank you for your time and help!
> David Alayachew
>
> On Mon, Jul 31, 2023 at 3:05?AM Per-Ake Minborg <
> per-ake.minborg at oracle.com> wrote:
>
> Hi David.
>
> Thanks for the encouragement.
>
> You can actually *reference* CC objects in a circular way as long as you
> do not create circularity in the *evaluation* of CC objects. So, it is, for
> example, perfectly legal to query if a CC is bound via the isBound() method
> in a circular way.
>
> Just to remind you, initialization can only be made at most once per CC
> instance/element.
>
> Best, Per
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, July 27, 2023 7:27 PM
> *To:* Per-Ake Minborg <per-ake.minborg at oracle.com>
> *Cc:* leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* [External] : Re: Draft JEP Announcement: "Computed Constants"
>
> Hello Per,
>
> Thank you for posting this JEP!
>
> It looks great. The solution is concise, clear, and simple, and any
> complaints I have about verbosity can be mostly addressed with var. And
> that list suggestion was especially nice. That's very neat.
>
> I'd like to ask about the safety point. I certainly understand the reason
> why it exists -- some developers will inadvertently create a circular
> reference and end up causing problems.
>
> However, I see a lot of utility for circular references too. Any chance
> that we could allow devs to opt-in to circular references?
>
> Earlier this month, I started 2 threads that were broaching the subject of
> a very similar pain point to this one. Here they both are.
>
> https://mail.openjdk.org/pipermail/amber-dev/2023-July/008129.html
>
> https://mail.openjdk.org/pipermail/amber-dev/2023-July/008154.html
>
> I'm curious how this Computed Constant solution would work out for the
> problem I have. But in order for it to work, it would need to enable
> circular references, hence my question.
>
> But even without it, I see a lot of utility for this tool. I'm excited to
> get to work prototyping with it.
>
> Thank you for your time and help!
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/b455c4b9/attachment.htm>

From brian.goetz at oracle.com  Mon Jul 31 12:49:08 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 31 Jul 2023 08:49:08 -0400
Subject: Draft JEP Announcement: "Computed Constants"
In-Reply-To: <CAJq4Gi5BtLncLZsFuyGaJfk=+Z73O-r9sw49xvyUw11z4_F2Ag@mail.gmail.com>
References: <DM6PR10MB42837B145AE7240575E9D057DA01A@DM6PR10MB4283.namprd10.prod.outlook.com>
 <CAJq4Gi56ao4aSV2z_FDjfAtdr+v9LsCRufAqxKifHKdKpd6cnQ@mail.gmail.com>
 <8FDD3FBF-5638-4CC9-B91A-CD42D8C5EBCF@oracle.com>
 <CAJq4Gi5BtLncLZsFuyGaJfk=+Z73O-r9sw49xvyUw11z4_F2Ag@mail.gmail.com>
Message-ID: <18d9142d-411d-6dc5-b763-a7270f2c97f3@oracle.com>



On 7/28/2023 4:18 PM, Dan Heidinga wrote:
>
> I'm with you on that goal.
>
>     Such ?things? might be condensers (as Brian also mentions), 
>
>
> As much as I want condensers (please, let's get condensers asap!), I'm 
> concerned that features which depend on condensers to get good 
> performance will live in an unstable state unless we can make running 
> condensers so cheap and routine and natural that doing so fits in 
> developers workflows

Agreed.? And we intend to make this cheap and routine.

As one example of the pain that the JDK is in, we often have 
bootstrapping problems where we can't use lambdas in code that runs 
early.? So some code in java.base gets refactored to use inner classes 
(e.g., classfile API), and eventually invariably another lambda sneaks 
in and causes a bootstrap regression.? We can address this by condensing 
lambdas to explicit classes during the JDK build for a specific set of 
classes in java.base.? For this to work, it has to be easy, cheap, and 
straightforward to integrate as a build step.? The actual condensation 
work is pretty trivial (the most expensive part is a scan of all the 
classfiles for the offending bytecode), so this is mostly a matter of 
ensuring that the tooling is easy to integrate in build workflows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/cb23ba12/attachment.htm>

From davidalayachew at gmail.com  Mon Jul 31 13:00:17 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 31 Jul 2023 09:00:17 -0400
Subject: ComputedConstant.ofEmpty() javadoc has a reference to a method
 that does not exist
In-Reply-To: <395248163.4804795.1690542520949.JavaMail.zimbra@univ-eiffel.fr>
References: <395248163.4804795.1690542520949.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAA9v-_NZ8U2LzU-WsYnrja4_EWi65aNV5Wd3TrtYES9fhHwA7w@mail.gmail.com>

I am pretty sure that computeIfUnbound is an old version of this method.
https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/util/concurrent/constant/ComputedConstant.html#get()

On Fri, Jul 28, 2023 at 8:28?AM Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Per,
> in the javadoc referenced by the JEP, the doc of ofEmpty() has the
> following snippet of code
>
>          private static final ComputedConstant<Foo> FOO =
> ComputedConstant.ofEmpty();
>
>          public Foo theBar() {
>              // Foo is lazily constructed and recorded here upon first
> invocation
>              return FOO.computeIfUnbound(Foo::new);
>          }
>
> I was not able to find a description of the method computeIfUnbound ?
>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/4552c132/attachment.htm>

From davidalayachew at gmail.com  Mon Jul 31 13:13:14 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 31 Jul 2023 09:13:14 -0400
Subject: ComputedConstant -- no pre-set supplier exists?
Message-ID: <CAA9v-_MsCdHjOrDz4tqmWiu=yFZoFOOjnpyH8epHq7hDGzKY-w@mail.gmail.com>

Hello Leyden Dev Team,

I was looking at the documentation for ComputedConstant, and I was a little
surprised to see this snippet in the javadoc for ComputedConstant::get.

"If no attempt to bind a value was made previously and no pre-set supplier
exists, throws a NoSuchElementException."

What does no pre-set Supplier mean? Do they mean if the Supplier is null?
Or do they mean that we have the ability to create a ComputedConstant that
has not yet been provided a Supplier? Something else?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/d8c9736c/attachment.htm>

From per-ake.minborg at oracle.com  Mon Jul 31 13:53:31 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 31 Jul 2023 13:53:31 +0000
Subject: ComputedConstant -- no pre-set supplier exists?
In-Reply-To: <CAA9v-_MsCdHjOrDz4tqmWiu=yFZoFOOjnpyH8epHq7hDGzKY-w@mail.gmail.com>
References: <CAA9v-_MsCdHjOrDz4tqmWiu=yFZoFOOjnpyH8epHq7hDGzKY-w@mail.gmail.com>
Message-ID: <DM6PR10MB428302A34E64B507C50A5AE5DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>

Thanks for bringing this to our attention. There is always a pre-set supplier. We will fix it. /Per
________________________________
From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Monday, July 31, 2023 3:13 PM
To: leyden-dev <leyden-dev at openjdk.org>
Subject: ComputedConstant -- no pre-set supplier exists?


Hello Leyden Dev Team,

I was looking at the documentation for ComputedConstant, and I was a little surprised to see this snippet in the javadoc for ComputedConstant::get.

"If no attempt to bind a value was made previously and no pre-set supplier exists, throws a NoSuchElementException."

What does no pre-set Supplier mean? Do they mean if the Supplier is null? Or do they mean that we have the ability to create a ComputedConstant that has not yet been provided a Supplier? Something else?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/611bf96f/attachment.htm>

From davidalayachew at gmail.com  Mon Jul 31 14:41:12 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 31 Jul 2023 10:41:12 -0400
Subject: ComputedConstant -- no pre-set supplier exists?
In-Reply-To: <DM6PR10MB428302A34E64B507C50A5AE5DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
References: <CAA9v-_MsCdHjOrDz4tqmWiu=yFZoFOOjnpyH8epHq7hDGzKY-w@mail.gmail.com>
 <DM6PR10MB428302A34E64B507C50A5AE5DA05A@DM6PR10MB4283.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_OrkOgmf2=KJxMBkxNxMBQYZhtj_ofesOozD9t18k0xJw@mail.gmail.com>

Anytime. I have another question that isn't worth creating a new thread
for. The API mentions repeatedly that it can throw Error. Why Error
specifically?

On Mon, Jul 31, 2023 at 9:53?AM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Thanks for bringing this to our attention. There is always a pre-set
> supplier. We will fix it. /Per
> ------------------------------
> *From:* leyden-dev <leyden-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, July 31, 2023 3:13 PM
> *To:* leyden-dev <leyden-dev at openjdk.org>
> *Subject:* ComputedConstant -- no pre-set supplier exists?
>
>
> Hello Leyden Dev Team,
>
> I was looking at the documentation for ComputedConstant, and I was a
> little surprised to see this snippet in the javadoc for
> ComputedConstant::get.
>
> "If no attempt to bind a value was made previously and no pre-set supplier
> exists, throws a NoSuchElementException."
>
> What does no pre-set Supplier mean? Do they mean if the Supplier is null?
> Or do they mean that we have the ability to create a ComputedConstant that
> has not yet been provided a Supplier? Something else?
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230731/3e06ae84/attachment.htm>

From mark.reinhold at oracle.com  Mon Jul 31 20:30:49 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Mon, 31 Jul 2023 20:30:49 +0000
Subject: Toward Condensers
Message-ID: <20230731163047.552602075@eggemoggin.niobe.net>

A few of us have been thinking about how condensers might work.  We now
have a prototype design and implementation of a condenser API and tool.

We?ve deliberately started small, focusing on principles of condenser
operation and a minimal set of features sufficient for the simplest
condensers, i.e., those that don?t require additional changes to the
Platform Specification.

Design note: https://openjdk.org/projects/leyden/notes/03-toward-condensers

Summary:

  We elaborate the concept of composable condensers to introduce a
  simple, abstract, immutable, data-driven model of applications so that
  condensers can be expressed as transformers of instances of the model.
  The model is sufficient to express simple condensers; we include two
  examples.

This is just a starting point; we expect to evolve it considerably going
forward.  We?ll publish the prototype code shortly after we return from
the upcoming JVM Language Summit.

- Mark