Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden)

Sat Apr 24 10:07:31 UTC 2021

Hi Volker,

This is certainly a conversation we need to have, however one of most important reasons for project Leyden is to understand and define a specification that works properly under the closed world-aot assumption.

I think there is tremendous value in doing so within the OpenJDK umbrella with hotspot as reference implementation, depending on external or downstream projects would limit the scope considerably and may not work at all.

Cheers,
Mario

—
Mario Torre
Java Champion and OpenJDK contributor

PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E

Twitter: @neugens
Web: https://www.mario-torre.eu/
Music: https://mario-torre.bandcamp.com/

> On Saturday, Apr 24, 2021 at 11:29, Volker Simonis <volker.simonis at gmail.com (mailto:volker.simonis at gmail.com)> wrote:
> Hi Andrew,
>
> thank you so much for resurrecting the discussion on project Leyden! I
> read through your leydendoc [1] which I think is an excellent and
> technically deep-dive summary of the current workings of the GraalVM
> Native Image Generator. The analysis and ideas how this functionality
> could be implemented in the context of OpenJDK and HotSpot is
> technically sound and very interesting.
>
> I'm really a little reluctant to add some non-technical doubts and
> acting as a killjoy here, but I think there's one real caveat with
> your approach and that's (unfortunately) licensing. As you know, the
> whole HotSpot code base (with the exception of very few header files
> [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE).
> HotSpot code can only be accessed without getting tainted by the GPL
> through a restricted set of exported, GPLv2+CPE licensed interfaces
> [2]. This is already a "weak" construct which has never been disputed
> but I don't want to discuss that here.
>
> I'm however afraid that your approach of linking large parts of the
> HotSpot code together with application classes into a single static
> image will undoubtedly "infect" all the user code with the GPL
> license. I think that's unacceptable for the majority of Java
> applications which are not already GPLv2 licensed. Unfortunately, in
> my opinion this seems to be a much bigger problem compared to the
> technical difficulties to implement your approach. Maybe we should
> have a look at alternative, existing JVM implementations (like OpenJ9,
> which I'm not all all familiar with) which are more liberally
> licensed? Having another write-up, similar to yours, which explores
> the same possibilities with OpenJ9 would be definitely a nice read :)
>
> As a side note, it seems like all the Java classes and even the native
> code parts of the class library are all licensed under GPLv2+CPE. So
> linking them into a native image together with user/application code
> seems to be less of a problem.
>
> Thanks again for your great analysis,
> Volker
>
> [1] https://github.com/adinn/leydendoc
> [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl
>
> On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn <adinn at redhat.com> wrote:
> >
> > Hello All,
> >
> > There has been a rather long and quiet interlude since the result of the
> > Leyden vote was reported (see below). Unfortunately, there has not yet
> > been any follow-up announcement of a project repo, mail list(s) or
> > working group. However, that's no indication that the project is not
> > still of great interest to those of us who voted for it, nor that some
> > of us have not been thinking about how we might proceed.
> >
> > I'd like to resume the initial discussion and, I hope, trigger some
> > follow-up actions by offering a few recommendations for how we might
> > wish to progress with Leyden. This is based on lessons learned from
> > working with the GraalVM Native implementation over the last year or two.
> >
> > Please note that I'm not suggesting that GraalVM Native provides a
> > blueprint for how Leyden should proceed. Indeed, I recognise that one of
> > the key reasons for creating the Leyden project is to sharpen up the
> > definition of static Java and, in doing so, critique some of the choices
> > made in implementing GraalVM Native.
> >
> > The path I am proposing we follow here is to:
> >
> > - identify some of the key architectural and design decisions made in
> > implementing GraalVM Native that appear to be relevant to a Hotspot
> > implementation
> >
> > - gauge how far those decisions contribute to improvements in certain
> > aspects of GraalVM Native performance vs degradation in other aspects
> >
> > - at the same time assess how systematically and coherently those same
> > decisions deal, or fail to deal, with some of the problematic semantic
> > issues involved in delivering static Java deployments
> >
> > - consider whether similar decisions might be worth taking in the
> > context of an implementation based on the current Hotspot code base
> >
> > I have posted a document to github [1] that provides a summary of my own
> > thoughts on the above themes. It starts with a critique of GraalVM
> > which, for the benefit of OpenJDK project members who are not familiar
> > with the implementation, also explains (as accurately as my
> > understanding permits) relevant aspects of the design and
> > implementation. It then goes on to discuss how this might be relevant to
> > a Leyden implementation that reuses existing Hotspot components as far
> > as possible.
> >
> > The document has been reviewed informally by a few OpenJDK project
> > colleagues. I'd be very grateful if others who have expressed an
> > interest in the project could take the time to read it and reflect on
> > it, either providing feedback directly on the document or following up
> > with their own opinions and suggestions for how to proceed.
> >
> > [1] https://github.com/adinn/leydendoc
> > n.b. the repo has a Creative Commons 1.0 open source license.
> >
> > 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
> >
> >
> >
> > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote:
> > > Voting on the Leyden Project [1], with me as the initial Lead,
> > > is now closed.
> > >
> > > Yes: 38
> > > Veto: 0
> > > Abstain: 0
> > >
> > > (Two votes, by individuals not in the Members Group [2], did
> > > not count.)
> > >
> > > According to the Bylaws definition of Lazy Consensus, this is
> > > sufficient to approve the new Project and its initial Lead.
> > >
> > > - Mark
> > >
> > >
> > > [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html
> > > [2] https://openjdk.java.net/census#members
> > >
> >