Project Leyden: Beginnings
The ultimate goal of this Project, as stated in the Call for Discussion [1], is to address the long-term pain points of Java’s slow startup time, slow time to peak performance, and large footprint. In the Call for Discussion I proposed that we address these pain points by introducing a concept of _static run-time images_ to the Java Platform, and to the JDK. - A static image is a standalone program, derived from an application and a JDK, which runs that application -- and no other. - A static image is a _closed world_ with respect to the classes that it can load: At run time it cannot load classes from outside the image, nor can it create classes dynamically. The closed-world constraint imposes strict limits on Java’s natural dynamism, particularly on the run-time reflection and class-loading features upon which so many existing Java libraries and frameworks depend. Not all applications are well suited to this constraint, and not all developers are willing to live with it. So rather than adopt the closed-world constraint at the start, I propose that we instead pursue a gradual, incremental approach. We will explore a spectrum of constraints, weaker than the closed-world constraint, and discover what optimizations they enable. The resulting optimizations will almost certainly be weaker than those enabled by the closed-world constraint. Because the constraints are weaker, however, the optimizations will likely be applicable to a broader range of existing code -- thus they will be more useful to more developers. We will work incrementally along this spectrum of constraints, starting small and simple so that we can develop a firm understanding of the changes required to the Java Platform Specification. Along the way we will strive, of course, to preserve Java’s core values of readability, compatibility, and generality. We will lean heavily on existing components of the JDK including the HotSpot JVM, the C2 compiler, application class-data sharing (CDS), and the `jlink` linking tool. In the long run we will likely embrace the full closed-world constraint in order to produce fully-static images. Between now and then, however, we will develop and deliver incremental improvements which developers can use sooner rather than later. Let us begin! - Mark [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html // https://openjdk.java.net/projects/leyden/notes/01-beginnings
On 5/20/22 15:42, mark.reinhold@oracle.com wrote:
Let us begin!
As you'd expect, here at Red Hat there's a variety of opinions. Rather than simply post my own response to this, I've been talking to Middleware architects (the likely _users_ of Leyden!) as well as our OpenJDK team members. Here's what we think: We're excited to see Leyden taking shape and will be active participants. Our customers are benefiting from GraalVM today and as such we’ll continue to engage with that project as the Leyden ideas are explored and take shape. Bringing standardization to this space is important for developers as it will clarify the behaviours they can depend on. As we engage in updating the standard, we should consider not just new behavior, but also exceptions and variations that can accommodate some of the existing behavior of GraalVM such as build-time initialization. The proposed incremental approach will ensure we bring along the current ecosystem and devtools while carefully introducing any new constraints. We also see the benefit in segmenting the problem space into discrete areas that can be introduced sooner rather than waiting for a big-bang integration of multiple constraints.
In the long run we will likely embrace the full closed-world constraint in order to produce fully-static images.
Our experience with Java on K8s and containers (notably Quarkus) has demonstrated real world benefits of a closed-world approach, so it's good to see it explicitly listed as a likely goal in the long run. It will be important that Leyden is careful to specify its efforts in the fast start / small footprint space while being mindful of that constraint. Hopefully, we can all work towards a future that converges both GraalVM's efforts and those of Leyden. -- 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
Hi Andrew, Since you mentioned GraalVM: note that the GraalVM team at Oracle was advised to not talk about Native Image on this mailing list. Only when concrete questions arise, we will be happy to explain how things are handled in Native Image. -Christian On 5/27/22 06:33, Andrew Haley wrote:
On 5/20/22 15:42, mark.reinhold@oracle.com wrote:
Let us begin!
As you'd expect, here at Red Hat there's a variety of opinions. Rather than simply post my own response to this, I've been talking to Middleware architects (the likely _users_ of Leyden!) as well as our OpenJDK team members. Here's what we think:
We're excited to see Leyden taking shape and will be active participants. Our customers are benefiting from GraalVM today and as such we’ll continue to engage with that project as the Leyden ideas are explored and take shape.
Bringing standardization to this space is important for developers as it will clarify the behaviours they can depend on. As we engage in updating the standard, we should consider not just new behavior, but also exceptions and variations that can accommodate some of the existing behavior of GraalVM such as build-time initialization.
The proposed incremental approach will ensure we bring along the current ecosystem and devtools while carefully introducing any new constraints. We also see the benefit in segmenting the problem space into discrete areas that can be introduced sooner rather than waiting for a big-bang integration of multiple constraints.
> In the long run we will likely embrace the full closed-world > constraint in order to produce fully-static images.
Our experience with Java on K8s and containers (notably Quarkus) has demonstrated real world benefits of a closed-world approach, so it's good to see it explicitly listed as a likely goal in the long run. It will be important that Leyden is careful to specify its efforts in the fast start / small footprint space while being mindful of that constraint. Hopefully, we can all work towards a future that converges both GraalVM's efforts and those of Leyden.
On 5/28/22 17:46, Christian Wimmer wrote:
Since you mentioned GraalVM: note that the GraalVM team at Oracle was advised to not talk about Native Image on this mailing list. Only when concrete questions arise, we will be happy to explain how things are handled in Native Image.
I see. Thanks for letting us know. -- 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
On Sat, May 28, 2022 at 6:47 PM Christian Wimmer <christian.wimmer@oracle.com> wrote:
Hi Andrew,
Since you mentioned GraalVM: note that the GraalVM team at Oracle was advised to not talk about Native Image on this mailing list. Only when concrete questions arise, we will be happy to explain how things are handled in Native Image.
Sorry, but this seems really weird to me. With OpenJDK and GraalVM Oracle is running two major open source projects and now Oracle forbids its own employees working on one of the project to communicate with the other ones? Is Oracle afraid of its own Terms of Use [1] or am I missing something obvious? From my understanding, Oracle employees working on the OpenJDK have started project Leyden to introduce "a concept of _static images_ to the Java Platform" [2] and "take inspiration from past efforts to explore this" like "the Native Image feature of GraalVM" [2]. And then it took some other Oracle employees another two years just to find out that they don't want its first open source project to get too much inspired by the second one? I'm puzzled... [1] https://openjdk.java.net/legal/tou/terms [2] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
-Christian
On 5/27/22 06:33, Andrew Haley wrote:
On 5/20/22 15:42, mark.reinhold@oracle.com wrote:
Let us begin!
As you'd expect, here at Red Hat there's a variety of opinions. Rather than simply post my own response to this, I've been talking to Middleware architects (the likely _users_ of Leyden!) as well as our OpenJDK team members. Here's what we think:
We're excited to see Leyden taking shape and will be active participants. Our customers are benefiting from GraalVM today and as such we’ll continue to engage with that project as the Leyden ideas are explored and take shape.
Bringing standardization to this space is important for developers as it will clarify the behaviours they can depend on. As we engage in updating the standard, we should consider not just new behavior, but also exceptions and variations that can accommodate some of the existing behavior of GraalVM such as build-time initialization.
The proposed incremental approach will ensure we bring along the current ecosystem and devtools while carefully introducing any new constraints. We also see the benefit in segmenting the problem space into discrete areas that can be introduced sooner rather than waiting for a big-bang integration of multiple constraints.
In the long run we will likely embrace the full closed-world constraint in order to produce fully-static images.
Our experience with Java on K8s and containers (notably Quarkus) has demonstrated real world benefits of a closed-world approach, so it's good to see it explicitly listed as a likely goal in the long run. It will be important that Leyden is careful to specify its efforts in the fast start / small footprint space while being mindful of that constraint. Hopefully, we can all work towards a future that converges both GraalVM's efforts and those of Leyden.
To my knowledge Leyden had always planned to have a different implementation than Graal when it came to native binaries, instead of just merging code from Graal into HotSpot; The former is envisioned to be entirely native to the official JVM and only working through enhancing HotSpot itself for code generation (Andrew mentioned discussions of it being a reference implementation of AOT Java binaries), while the latter focuses more on "Java on Java". My guess is the advisory is so that too much of Graal's design and code doesn't seep into Leyden - Inspiration from Graal is helpful, turning Leyden into Graal itself wouldn't be (Hence why it's only advised and not outright forbidden). best regards. Julian On Tue, May 31, 2022 at 10:29 PM Volker Simonis <volker.simonis@gmail.com> wrote:
On Sat, May 28, 2022 at 6:47 PM Christian Wimmer <christian.wimmer@oracle.com> wrote:
Hi Andrew,
Since you mentioned GraalVM: note that the GraalVM team at Oracle was advised to not talk about Native Image on this mailing list. Only when concrete questions arise, we will be happy to explain how things are handled in Native Image.
Sorry, but this seems really weird to me. With OpenJDK and GraalVM Oracle is running two major open source projects and now Oracle forbids its own employees working on one of the project to communicate with the other ones? Is Oracle afraid of its own Terms of Use [1] or am I missing something obvious? From my understanding, Oracle employees working on the OpenJDK have started project Leyden to introduce "a concept of _static images_ to the Java Platform" [2] and "take inspiration from past efforts to explore this" like "the Native Image feature of GraalVM" [2]. And then it took some other Oracle employees another two years just to find out that they don't want its first open source project to get too much inspired by the second one?
I'm puzzled...
[1] https://openjdk.java.net/legal/tou/terms [2] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
-Christian
On 5/27/22 06:33, Andrew Haley wrote:
On 5/20/22 15:42, mark.reinhold@oracle.com wrote:
Let us begin!
As you'd expect, here at Red Hat there's a variety of opinions. Rather than simply post my own response to this, I've been talking to Middleware architects (the likely _users_ of Leyden!) as well as our OpenJDK team members. Here's what we think:
We're excited to see Leyden taking shape and will be active participants. Our customers are benefiting from GraalVM today and as such we’ll continue to engage with that project as the Leyden ideas are explored and take shape.
Bringing standardization to this space is important for developers as it will clarify the behaviours they can depend on. As we engage in updating the standard, we should consider not just new behavior, but also exceptions and variations that can accommodate some of the existing behavior of GraalVM such as build-time initialization.
The proposed incremental approach will ensure we bring along the current ecosystem and devtools while carefully introducing any new constraints. We also see the benefit in segmenting the problem space into discrete areas that can be introduced sooner rather than waiting for a big-bang integration of multiple constraints.
In the long run we will likely embrace the full closed-world constraint in order to produce fully-static images.
Our experience with Java on K8s and containers (notably Quarkus) has demonstrated real world benefits of a closed-world approach, so it's good to see it explicitly listed as a likely goal in the long run. It will be important that Leyden is careful to specify its efforts in the fast start / small footprint space while being mindful of that constraint. Hopefully, we can all work towards a future that converges both GraalVM's efforts and those of Leyden.
Hi Volker, On 31/05/2022 15:28, Volker Simonis wrote:
On Sat, May 28, 2022 at 6:47 PM Christian Wimmer
Since you mentioned GraalVM: note that the GraalVM team at Oracle was advised to not talk about Native Image on this mailing list. Only when concrete questions arise, we will be happy to explain how things are handled in Native Image.
Sorry, but this seems really weird to me. With OpenJDK and GraalVM Oracle is running two major open source projects and now Oracle forbids its own employees working on one of the project to communicate with the other ones? Is Oracle afraid of its own Terms of Use [1] or am I missing something obvious? From my understanding, Oracle employees working on the OpenJDK have started project Leyden to introduce "a concept of _static images_ to the Java Platform" [2] and "take inspiration from past efforts to explore this" like "the Native Image feature of GraalVM" [2]. And then it took some other Oracle employees another two years just to find out that they don't want its first open source project to get too much inspired by the second one?
I'm puzzled...
[1] https://openjdk.java.net/legal/tou/terms [2] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html I am not sure how you arrived at the conclusion that "Oracle forbids its own employees working on one of the project to communicate with the other ones". That's particularly weird since I know that the two teams have been working together for a long time -- for example to ensure GraalVM is ready to implement Loom.
I took Christian's first statement merely to indicate that this would not be the correct forum for general discussion of GraalVM Native. That's not surprising. This project is primarily about arriving at a satisfactory model for static Java. That may ultimately lead to some revisions in how GraalVM Native operates and -- we hope - some revisions to the language or runtime that might simplify the life of GraalVM developers. It may also need to consider some of the things that were done or are being done in the GraalVM Native project. However, mostly what is discussed here will have no direct bearing on how the GraalVM Native implementation proceeds. The GraalVM project has its own forums for those discussions and that is where they should proceed. If you think that first statement means anything more than that then I recommend you what he said in follow up to that. Christian explicitly stated that the GraalVM team will be "happy to talk about how things are handled in Native Image ... when concrete questions arise". That looks to me to be a fairly unambiguous and generous offer to provide advice, based on the experience garnered by the GraalVM team, where it applies to problems Leyden needs to address. I must say I find the rest of your post to be equally as marred by speculation and misreading of the prior and current situation. However, that's not my main takeaway; most of all I find what what you said to be irrelevant. I would much prefer to drop all speculation about what might or might not be going on inside Oracle and instead get on with looking into how we can move this project forward. Oracle staff from both the OpenJDK and GraalVM projects have stated that they are willing to provide input to this project. Can we not simply thank them for that and work with them? regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
participants (6)
-
Andrew Dinn
-
Andrew Haley
-
Christian Wimmer
-
Julian Waters
-
mark.reinhold＠oracle.com
-
Volker Simonis