July 2023 - leyden-dev

Toward Condensers
by Mark Reinhold 14 Aug '23

14 Aug '23

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

4 10

ComputedConstant -- no pre-set supplier exists?
by David Alayachew 31 Jul '23

31 Jul '23

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

2 2

ComputedConstant.ofEmpty() javadoc has a reference to a method that does not exist
by Remi Forax 31 Jul '23

31 Jul '23

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

2 1

Draft JEP Announcement: "Computed Constants"
by Per-Ake Minborg 31 Jul '23

31 Jul '23

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

10 36

JEP draft
by Julian Waters 28 Jul '23

28 Jul '23

Hi all, A JEP draft regarding Leyden has been submitted at https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome best regards, Julian

3 8

git: openjdk/leyden: created branch pregenerate-lambdas based on the branch master containing 7 unique commits
by duke 27 Jul '23

27 Jul '23

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

1 0

jlink: pre-generate lambda classes
by Dan Heidinga 27 Jul '23

27 Jul '23

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:prege… [1] https://mail.openjdk.org/pipermail/leyden-dev/2022-August/000055.html

3 5

Leyden repository open
by Mark Reinhold 27 Jul '23

27 Jul '23

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

1 0

CFV and Result: Project Leyden Committers
by Mark Reinhold 25 Jul '23

25 Jul '23

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

1 0

jmods-less jlinking prototype
by Severin Gehwolf 17 Jul '23

17 Jul '23

The Problem: ------------ Why do we need the 'jmods' directory when running jlink when 'java -- list-modules' lists all the modules and all the files from the JDK build are in <install/location/of/jdk> (only 'jmods' directory is missing)[1]? Example: $ rm -rf ./images/jdk/jmods/ $ ./images/jdk/bin/jlink --add-modules java.base --output build/test-jlink-jdk Error: --module-path is not specified and this runtime image does not contain jmods directory. Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...] Use --help for a list of possible options The Proposed Solution: ---------------------- Instead of using the <module-name>.jmod archives when jlinking an application image, use the JDK installation on the file system together with the module contents from the jimage to produce the desired result, provided we initially start with a full JDK (including 'jmods' directory). Only use this mode *if and only if* the 'jmods' directory is missing in the JDK image. Use a jlink plugin that records resource files - other than classes and resources which are in the jimage file - in a new resource file 'jmod_resources' and add it to the jimage. In later jlink passes use the 'jmod_resources' resource file of the jimage in order to track other files part of the application image. The union of 'jmod_resources' (if any[2]) and the classes and resources files from the jimage form the equivalent of what '<module-name>.jmod' archives track today. The size of those extra 'jmod_resources' files are fairly small: about ~170 bytes on average over all current JDK modules. The one for 'java.base' is "largest" with 1308 bytes on my system. This seems a good trade-off. In the proposed prototype the supporting jlink plugin is enabled by default but could instead only enable given a specific option. It seems conceivable that such recursive jlink passes would become more common in context of Leyden, provided jlink serves as the tool for driving condensation passes. Supporting jmods-less jlinking would further strengthen that use-case. An additional advantage of such an approach would be that distributors could ship a lighter weight JDK distribution (without jmods), yet still support jlinking specific application images. The code is here: https://github.com/jerboaa/jdk/compare/jlink-jmods-base...jerboaa:jdk:jlink… Or the branch: https://github.com/jerboaa/jdk/tree/jlink-jmods-less Current Limitations: -------------------- The prototype only works on the actual target runtime platform. Cross- jlinking isn't supported. However, in context of Leyden this might be OK as some AOT compilations as part of some condenser runs might have similar restrictions. Also, only modules already present in the base jimage can be included in derivatives. Consider a base JDK image including JDK modules 'java.base', 'app.module1' and 'app.module2'. Further jlink passes would only be able to create images including a *subset* of those modules. Alternatives: ------------- There is a '--keep-packaged-modules <output/to/jmods/packages>' option, but that seems unsatisfying since it copies large amounts of data for no good reason. Especially when the java.base.jmod includes debuginfo in native libraries itself (in particular, libjvm.so). Example Usage: -------------- $ ./images/jdk/bin/jlink --add-modules ALL-MODULE-PATH --output build/jlinked-image WARNING: Using incubator modules: jdk.incubator.concurrent, jdk.incubator.vector $ ls ./build/jlinked-image/jmods ls: cannot access './build/jlinked-image/jmods': No such file or directory $ ./build/jlinked-image/bin/jlink --verbose --add-modules java.base \ --output ./build/java.base-image java.base jrt:/java.base (jmod-less) Providers: java.base provides java.nio.file.spi.FileSystemProvider used by java.base java.base provides java.util.random.RandomGenerator used by java.base $ ./build/java.base-image/bin/java --version openjdk 21-internal 2023-09-19 OpenJDK Runtime Environment (build 21-internal-adhoc.sgehwolf.jdk-jdk) OpenJDK 64-Bit Server VM (build 21-internal-adhoc.sgehwolf.jdk-jdk, mixed mode) Thoughts? Opinions? Note that depending on feedback, we could consider getting something like this into mainline JDK as it seems useful outside of Leyden as well. Thanks, Severin [1] In the Leyden context there is also this issue: Let 'jlink' be the tool to "drive" condensor passes. Would I be able to use it recursively, minus after the last step? Not in it's current form without using '--keep-packaged-modules': $ ./images/jdk/bin/jlink --add-modules jdk.jlink --output build/test-jlink-image $ ./build/test-jlink-image/bin/jlink --add-modules java.base --output build/test-java.base-image Error: --module-path is not specified and this runtime image does not contain jmods directory. Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...] Use --help for a list of possible options [2] Not all modules contain non-class-resource data, like native libraries or binaries, but only contain Java class files and resources. If so, all required files are already in the jimage file.

6 20