Merge pull request #2070 from ashu-mehra/minor-corrections-quarkus-leyden

Minor changes to the Quarkus-Leyden blog

Author: Sanne

_posts/2024-08-06-quarkus-and-leyden.adoc

@@ -12,7 +12,7 @@ You might have heard of https://openjdk.org/projects/leyden/[Project Leyden], a
 
 As Quarkus users, you'll be wondering how this project will benefit you and how it's different from GraalVM native images. While we think it's fair to say that Leyden was inspired or at least motivated by some ideas first implemented in GraalVM's native images, Leyden is remarkably different. It's essential to understand how it works: as we will see, Leyden is not a replacement for GraalVM native images but rather a substantial evolution of the JVM, and we expect it to bring some benefits to native images as well.
 
-To try to clarify this, unfortunately, this post is unusually long: we wish it could have been a short guide, "This is how you enable Leyden," but this isn't quite the time yet, as we need to understand the different models first. Sometimes, the terminology is also different; for example, "Ahead of Time (AOT) compilation" has a very specific meaning in the context of GraalVM native images, but is used more broadly to indicate a variety of aspects of "compilation" in the context of Leyden; hopefully, after reading this, it will be less confusing.
+To try to clarify this, unfortunately, this post is unusually long: we wish it could have been a short guide, "This is how you enable Leyden," but this isn't quite the time yet, as we need to understand the different models first. Sometimes, the terminology is also different; for example, "Ahead of Time (AOT)" has a very specific meaning in the context of GraalVM native images and has traditionally been associated with "compilation", but in the context of Leyden it is used more broadly to indicate a variety of aspects of the JVM ; hopefully, after reading this, it will be less confusing.
 
 Another significant misconception about Leyden is that it's a project to "improve startup times"; this statement is not wrong, as improving startup times is one of its goals. Yet the other stated goals of the project offer even more significant potential for our favourite platform, Quarkus, and its users.
 
@@ -263,19 +263,19 @@ The same happens if the application is intensively using reflection. Quarkus avo
 However Quarkus in “fast-jar” mode, which is the default packaging mode, will use a custom classloader which currently would get in the way of some Leyden optimisations. One could use a different packaging mode in Quarkus to get more prominent benefits from Leyden, but doing so would disable other Quarkus optimisations, so the comparison wouldn’t be entirely fair today.
 We hope to work on improvements in this area to have all possible benefits, combined.
 
-The focus on these first early releases has been on bootstrap times. There are measurable, significant startup time improvements, due to AoT loading and linking. In some cases, these improvements on startup time have worsened the memory footprint of some applications. That’s an already known issue that is being worked on, and the expected outcome is to improve memory footprint as well, so we would suggest not worrying too much about total memory consumption at this stage.
+The focus on these first early releases has been on bootstrap times. There are measurable, significant startup time improvements, due to AOT loading and linking. In some cases, these improvements on startup time have worsened the memory footprint of some applications. That’s an already known issue that is being worked on, and the expected outcome is to improve memory footprint as well, so we would suggest not worrying too much about total memory consumption at this stage.
 
 Since the AOT archives include machine specific optimisations such as the native code generated by the C2 compiler, the training run and the production run must be done on the same type of hardware and JDK versions; it also requires using the same JAR-based classpaths and the same command line options. 
 
 Although the training run can use a different Main class to the one used for running the application, for example a test class that simulates usage.
 
 === What is on the roadmap for Leyden?
 
-There’s still work to be done regarding classes that can’t be loaded and linked in AoT with the current implementation. For example, classes loaded using a user-defined class loader. There’s also room to improve the way the training runs are made, maybe allowing the user to tweak the results to influence decisions.
+There’s still work to be done regarding classes that can’t be loaded and linked in AOT with the current implementation. For example, classes loaded using a user-defined class loader. There’s also room to improve the way the training runs are made, maybe allowing the user to tweak the results to influence decisions.
 
 Currently, the https://bugs.openjdk.org/browse/JDK-8326035[Z Garbage Collector] does not support AOT object archiving. There is an active effort to make sure all Garbage Collectors are compatible with these enhancements.
 
-There are also other things planned in the roadmap for Leyden, like adding condensers. https://openjdk.org/projects/leyden/notes/03-toward-condensers[Condensers] will be composable transformers of the source code in AoT that modify the source code optimising it. Each developer will be able to define a pipeline of condensers that improves their source code before compiling it into bytecode; this is very interesting to the Quarkus team but condensers aren’t available yet.
+There are also other things planned in the roadmap for Leyden, like adding condensers. https://openjdk.org/projects/leyden/notes/03-toward-condensers[Condensers] will be composable transformers of the source code in AOT that modify the source code optimising it. Each developer will be able to define a pipeline of condensers that improves their source code before compiling it into bytecode; this is very interesting to the Quarkus team but condensers aren’t available yet.
 
 The OpenJDK team is actively extending the range of compiled code that can be saved to and restored from the AOT cache. Our colleagues from Red Hat’s OpenJDK team are directly involved in this effort, looking into save and restore of auxiliary code that is normally generated at runtime and used to provide optimized code for 'intrinsic' methods or to link compiled Java method code to the compiled C code that implements the JVM, the interpreter and other compiled C libraries.
 
@@ -293,7 +293,7 @@ The ability that Quarkus offers to create a closed world application doesn't imp
 
 We're very excited by Project Leyden as it allows to substantially improve bootstrap times, warmup times, and overall costs even for the "regular" JVM, so retaining all the benefits of a dynamic runtime and an adaptative JIT compiler, and this will be a fantastic option for all those applications for which a fully AOT native image might not be suitable: you'll get some of the benefits from native-image (not all of them) but essentially for free, at no drawbacks.
 
-We also hope it will bring better defined semantics in regards to running certain phases “ahead of time” (or later); there is a very interesting read on this topic by Mark Reinhold: “Selectively Shifting and Constraining Computation” ; from a perspective of Quarkus developers, we can confirm that improvements in the language specification in this area would be very welcome, and also improve the quality and maintainability of applications compiled with GraalVM native-image(s).
+We also hope it will bring better defined semantics in regards to running certain phases “ahead of time” (or later); there is a very interesting read on this topic by Mark Reinhold: https://openjdk.org/projects/leyden/notes/02-shift-and-constrain[Selectively Shifting and Constraining Computation] ; from a perspective of Quarkus developers, we can confirm that improvements in the language specification in this area would be very welcome, and also improve the quality and maintainability of applications compiled with GraalVM native-image(s).
 
 For these reasons, Quarkus will definitely not deprecate support for native images; it's more plausible that, eventually, the "full JVM" will always be benefiting from Leyden powered improvements, and as usual we'll work to make these benefits work in synergy with our architecture, and at minimal effort for you all.