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

[Andrew Dinn]

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
>