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

[Volker Simonis]

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
> >
>