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

[David Griffiths]

Hi Andrew and all, could I just add a plea if possible to retain ScopeDesc
and PCDesc info (or equivalent) in the compiled code image? I work for a
company called Undo and we recently released a reversible debugger for
OpenJDK that lets you record an entire Java program history at the machine
level and then play it back under IntelliJ via an extended JDWP interface.
It allows you to set breakpoints on and single step through compiled code,
view all local variables and so on. But this depends heavily on ScopeDesc
and PCDesc and similar structures. We have a "bridge" program that talks
JDWP to IntelliJ and uses a modified version of gdb to set breakpoints and
poke around in compiled code in the target (unmodified) JVM. We set
breakpoints at nearby safepoints (PCDescs) and then do the same thing the
deoptimizer does to transfer the current frame state to our own bytecode
interpreter in the bridge from where we can single step, examine local
variables etc.

For situations like debugging microservices in the cloud, technology like
ours could be very useful. Whilst we have an obvious interest in this, it
seems like a good idea to try and aim to retain such structures for future
similar technologies to be built on.

Cheers,

David

On Fri, 23 Apr 2021 at 16:31, 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
> >
>
>

-- 
David Griffiths, Senior Software Engineer

Undo <https://undo.io> | Accelerate software defect resolution by
eliminating the guesswork in failure diagnosis