September 2024 - leyden-dev

RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and MethodTypeForm when storing heap objects into AOT cache
by ioi.lam＠oracle.com 17 Sep '24

17 Sep '24

Hi, this is the 6th PR for JEP 483 - Ahead-of-Time Class Loading & Linking [1] The PR is https://github.com/openjdk/jdk/pull/21049 - When writing heap objects to the AOT cache (currently this is done only when dumping "static" CDS archive), avoid using SoftReferences in LambdaFormEditor and MethodTypeForm. - This is a requirement by JDK-8293336 [3] (AOT-linking of invokedynamic for lambda expression and string concat), which is the 7th and last PR for JEP 483 The plan [2] is to break down JEP 483 in a series of 7 PRs to make it easier to review. I will post the other PRs soon. Thanks - Ioi === [1] https://openjdk.org/jeps/483 [2] https://bugs.openjdk.org/browse/JDK-8331497 [3] https://bugs.openjdk.org/browse/JDK-8293336

1 0

git: openjdk/leyden-docs: master: 2 new changesets
by Mark Reinhold 17 Sep '24

17 Sep '24

Changeset: 6a01cae2 Branch: master Author: Mark Reinhold <mr(a)openjdk.org> Date: 2024-09-17 15:50:01 +0000 URL: https://git.openjdk.org/leyden-docs/commit/6a01cae2165acde7b0b6a4a9d85513dc… Rework main page ! site/_index.md - site/leyden-jar-200.jpg + site/leyden-jar.jpg Changeset: 35475b30 Branch: master Author: Mark Reinhold <mr(a)openjdk.org> Date: 2024-09-17 15:51:51 +0000 URL: https://git.openjdk.org/leyden-docs/commit/35475b30f9b6861128a40c4350b9ffff… Training Runs note: Fix metadata ! site/notes/05-training-runs.md

1 0

AOTHolder pattern for caching heap objects
by ioi.lam＠oracle.com 17 Sep '24

17 Sep '24

For the development of JDK-8293336 [1], I am experimenting with a pattern of Java code to indicate what heap objects should be stored in the AOT cache. This code has been pushed to the premain branch. It looks like this [2]: class java.lang.invoke.MethodType { static class AOTHolder { private static final @Stable MethodType[] objectOnlyTypes = new MethodType[20]; private static @Stable HashMap<MethodType,MethodType> archivedMethodTypes; } Essentially the class MethodType$AOTHolder will be stored in its "already initialized" state in the AOT cache. In the production run, MethodType$AOTHolder.<clinit> will NOT be run. Its static fields are already initialized and point to the objects that were created during the assembly phase. Currently, the JVM is hard-wired to recognize only a few known AOTHolder classes. This pattern is used strictly for the AOT-caching of MethodType.internTable. I want to hear people's reaction to this. I think other internal JDK classes can use a similar pattern as well. (In the long term, we will need a more generalized way (a.k.a. the "Scrambled Egg API"), but I need to have a mechanism that works for the short term). *** The reason I needed to use the AOTHolder pattern is to remove this horrible hack [3]. (It's now removed from the premain branch). You can see more info in the comments of [3], but the gist is: - The old way of CDS heap object caching depends on re-executing the <clinit> methods of classes that want to cache heap objects - These classes would call CDS.initializeFromArchive() to fetch the cached objects. - Before CDS.initializeFromArchive() returns the objects, it wants to initialize all the classes of these objects (or else the caller would end up with an object whose class is not yet initialized) - This scheme breaks down when several classes want to cache heap objects, and their <clinit> intertwine with each other. The old code in [3] tries to work around a NullPointerException that happens due to the intertwining. That is certainly not a sustainable approach. *** The AOTHolder pattern tries to accomplish two things - Clearly identify what objects should be AOT-cached. In the case of MethodType.java, I moved only two of its many fields into its AOTHolder inner class. - Cache the static fields in all the AOTHolder classes as a single snapshot. Avoid the need to run <clinit> so we don't need to worry about execution order, etc. ====== [1] https://bugs.openjdk.org/browse/JDK-8293336 [2] https://github.com/openjdk/leyden/blob/e33ecb3ec42d142569227b4bd1987124e555… [3] https://github.com/openjdk/leyden/blob/3a84df9d9860e743684e335282e3910b14cc…

2 2

RFR: Add Premain EA link, Premain JEP links, link to training run doc
by John R Rose 17 Sep '24

17 Sep '24

Some adds to the index page: - premain JEP and EA links - link to Dan's doc about training runs One thing that baffled me a bit is the `<br/>` elements in the markdown. These seem to be either hand-inserted as an attempt to do line length control, or else they are artifacts of an old cut-and-paste. Do we really want them? If so, can we put in a comment in the markdown that says how to maintain them, please? ------------- Commit messages: - Add Premain EA link, Premain JEP links, link to training run doc Changes: https://git.openjdk.org/leyden-docs/pull/4/files Webrev: https://webrevs.openjdk.org/?repo=leyden-docs&pr=4&range=00 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.org/leyden-docs/pull/4.diff Fetch: git fetch https://git.openjdk.org/leyden-docs.git pull/4/head:pull/4 PR: https://git.openjdk.org/leyden-docs/pull/4

2 2

git: openjdk/leyden-docs: master: Add Premain EA link, Premain JEP links, link to training run doc (#4)
by duke 17 Sep '24

17 Sep '24

Changeset: 2faaf6e8 Branch: master Author: John Rose <rose00(a)mac.com> Committer: GitHub <noreply(a)github.com> Date: 2024-09-17 08:41:17 +0000 URL: https://git.openjdk.org/leyden-docs/commit/2faaf6e80b43e953320a6461da691546… Add Premain EA link, Premain JEP links, link to training run doc (#4) Co-authored-by: John Rose <jrose(a)openjdk.org> ! site/_index.md

1 0

RFR: Reformat internal profiling stats
by Aleksey Shipilev 16 Sep '24

16 Sep '24

For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well. ------------- Commit messages: - Reformat internal profiling stats Changes: https://git.openjdk.org/leyden/pull/18/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=18&range=00 Stats: 80 lines in 15 files changed: 17 ins; 0 del; 63 mod Patch: https://git.openjdk.org/leyden/pull/18.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/18/head:pull/18 PR: https://git.openjdk.org/leyden/pull/18

3 6

git: openjdk/leyden: premain: Reformat internal profiling stats
by Andrew Dinn 16 Sep '24

16 Sep '24

Changeset: a8b8d7da Branch: premain Author: Aleksey Shipilev <shade(a)openjdk.org> Committer: Andrew Dinn <adinn(a)openjdk.org> Date: 2024-09-16 09:13:44 +0000 URL: https://git.openjdk.org/leyden/commit/a8b8d7da9ecbdfedbf30ec430aaa1deea9343… Reformat internal profiling stats Reviewed-by: kvn ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/perfData.inline.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/services/management.cpp ! src/hotspot/share/services/management.hpp

1 0

RFR: Rework rich PrintCompilation logs
by Aleksey Shipilev 13 Sep '24

13 Sep '24

I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though: - The columns are misindented - The precision is too low to capture short events: most of the times are zero - Output seems to rely on "now" timestamp, which depends on _when_ we print This PR reworks the logs to be more straightforward. Example before: S296 C0 Q229 3531 A 2 com.sun.tools.javac.parser.JavacParser::typeName (37 bytes) S296 C0 Q245 2030 A 2 com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes) S296 C0 Q0 4169 3 com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes) S296 C0 Q245 2042 A 2 com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes) S296 C0 Q0 4170 3 com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes) S296 C0 Q0 4171 3 com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes) S296 C0 Q245 2098 A 2 com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes) S296 C0 Q244 2348 A 2 com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes) S296 C0 Q244 2349 A 2 com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes) Example after: 346 C0.0 4146 3 com.sun.tools.javac.comp.Check::checkAllDefined (66 bytes) 346 C0.0 Q0.0 W0.1 4144 3 com.sun.tools.javac.comp.Attr$$Lambda/0x80000004f::<init> (10 bytes) 346 C0.6 Q281.9 W0.1 3535 A 2 com.sun.tools.javac.parser.JavacParser::variableDeclaratorId (529 bytes) 346 C0.0 4148 3 com.sun.tools.javac.comp.Check::checkDefaultMethodClashes (383 bytes) 346 C0.0 Q0.0 W0.1 4145 3 com.sun.tools.javac.comp.Attr$$Lambda/0x800000052::test (8 bytes) 346 C0.4 2631 A 2 com.sun.tools.javac.jvm.Items$ImmediateItem::numericValue (14 bytes) 346 C0.0 4149 3 com.sun.tools.javac.comp.Check::checkPotentiallyAmbiguousOverloads (79 bytes) 346 C0.4 Q295.2 W0.0 2631 A 2 com.sun.tools.javac.jvm.Items$ImmediateItem::numericValue (14 bytes) 346 C0.1 2790 A 2 java.lang.invoke.InnerClassLambdaMetafactory::methodDesc (45 bytes) 346 C0.1 Q294.5 W0.0 2790 A 2 java.lang.invoke.InnerClassLambdaMetafactory::methodDesc (45 bytes) Note this effectively prints the task twice: one in the "usual" place we do it (near task creation), and one at the end, when we know all counters are populated and trustworthy. ------------- Commit messages: - Work Changes: https://git.openjdk.org/leyden/pull/16/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=16&range=00 Stats: 40 lines in 3 files changed: 23 ins; 0 del; 17 mod Patch: https://git.openjdk.org/leyden/pull/16.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/16/head:pull/16 PR: https://git.openjdk.org/leyden/pull/16

4 10

git: openjdk/leyden: premain: Tidy up
by duke 12 Sep '24

12 Sep '24

Changeset: 07ad2086 Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2024-09-12 09:44:31 +0000 URL: https://git.openjdk.org/leyden/commit/07ad2086bdac70ac2fd87876a68906519cf79… Tidy up ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp

1 0

Re: premain: CGLIB error during the training run with Petclinic
by Alan Bateman 12 Sep '24

12 Sep '24

On 11/09/2024 13:16, Sebastien Deleuze wrote: > Yes, it works without --add-opens and without -XX:CacheDataStore, in > all my use cases I never set --add-opens explicitly. > > There are various fallback paths, and potentially the original > exception is hidden, so let me have a deeper look by comparing broken > and successful code paths. > I will share more details in an upcoming email. > Maybe running with -Xlog:exceptions might reveal something. -Alan

3 3