From forax at univ-mlv.fr  Sun May  3 22:18:24 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 4 May 2020 00:18:24 +0200 (CEST)
Subject: Revival of JEP 198 (Light-Weight JSON API)?
In-Reply-To: <303B6825-9B90-4935-9C09-5B44DFC03E7D@oracle.com>
References: <1b36d358-cded-ef25-7e7d-3e3c40f3112d@oracle.com>
 <1248493129.412574.1587051715750.JavaMail.zimbra@u-pem.fr>
 <74BD3167-D5A8-44D0-9F52-0111C71E3053@oracle.com>
 <3EE20EA0-1DD7-4791-8B49-90739E0E6C0B@oracle.com>
 <92965CED-DA0D-4709-978B-EB5472EB0FFC@oracle.com>
 <560354821.440529.1587665109404.JavaMail.zimbra@u-pem.fr>
 <303B6825-9B90-4935-9C09-5B44DFC03E7D@oracle.com>
Message-ID: <1799220204.10298.1588544304799.JavaMail.zimbra@u-pem.fr>

I've been mulling an implementation since this email 
here is my take 
https://github.com/forax/jsonapi 

R?mi 

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "discuss" <discuss at openjdk.java.net>
> Envoy?: Vendredi 24 Avril 2020 00:41:04
> Objet: Re: Revival of JEP 198 (Light-Weight JSON API)?

> On Apr 23, 2020, at 11:05 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>> most APIs do not provide a generic tree API but a data binding API that takes a
>> tree of types (a bean/record/interface tree) and a stream of JSON tokens and
>> construct the corresponding Java representation (creating instances
>> Bean/Record/Proxy).

> Yep. A Lisp refugee like me will immediately think ?S-expressions
> are enough; why use anything else? and that me to look for some
> sort of clunky prefab node structure. The more modern side of me
> will look for a mapping or transcoding to/from the event stream
> and whatever AST or other data I choose to work with at the moment.

> My point here is that the event stream ?layer? of the library is
> a safe-ish first step, even if it fails to use value types in the clever
> way you suggest. The next layer up will surely be data binding,
> and maybe a prefab tree for folks like me. IMO, the upper layers
> will want to work well (IMO) with *both* mutable vs. immutable
> (easy to edit vs. safe) AST representations, just as ju.List supplies
> both options, and will also want to perform more ad hoc transcodings
> (not just standard ASTs) to both mutable and immutable objects.
> The immutable objects are likely to be inline objects, sometimes.
> (For that matter, inlines can also express logically mutable objects.)
> The longer we delay nailing down the transcoding layer, the more
> future features of the language we can use to make that layer more
> flexible and powerful.

> ? John

From ropalka at redhat.com  Mon May  4 10:09:29 2020
From: ropalka at redhat.com (Richard Opalka)
Date: Mon, 4 May 2020 12:09:29 +0200
Subject: Revival of JEP 198 (Light-Weight JSON API)?
In-Reply-To: <1799220204.10298.1588544304799.JavaMail.zimbra@u-pem.fr>
References: <1b36d358-cded-ef25-7e7d-3e3c40f3112d@oracle.com>
 <1248493129.412574.1587051715750.JavaMail.zimbra@u-pem.fr>
 <74BD3167-D5A8-44D0-9F52-0111C71E3053@oracle.com>
 <3EE20EA0-1DD7-4791-8B49-90739E0E6C0B@oracle.com>
 <92965CED-DA0D-4709-978B-EB5472EB0FFC@oracle.com>
 <560354821.440529.1587665109404.JavaMail.zimbra@u-pem.fr>
 <303B6825-9B90-4935-9C09-5B44DFC03E7D@oracle.com>
 <1799220204.10298.1588544304799.JavaMail.zimbra@u-pem.fr>
Message-ID: <CABSyOEEN-mB=gF-QtkGqwz+HuOtGeBn9gNKyLksdjNBB26cdLw@mail.gmail.com>

Hi all,

   I've been also playing with JSON API few years ago and here's my attempt:

https://github.com/fossnova/json/

It provides two kinds of API style, STREAM & DOM.
It is very performant compared to other available Java JSON libraries.

Rio

On Mon, May 4, 2020 at 12:22 AM <forax at univ-mlv.fr> wrote:

> I've been mulling an implementation since this email
> here is my take
> https://github.com/forax/jsonapi
>
> R?mi
>
>
>

-- 
BSc. Richard Op?lka
Principal Software Engineer
Red Hat JBoss Middleware
E-mail: ropalka at redhat.com

From aph at redhat.com  Mon May  4 10:19:24 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 4 May 2020 11:19:24 +0100
Subject: Revival of JEP 198 (Light-Weight JSON API)?
In-Reply-To: <303B6825-9B90-4935-9C09-5B44DFC03E7D@oracle.com>
References: <1b36d358-cded-ef25-7e7d-3e3c40f3112d@oracle.com>
 <1248493129.412574.1587051715750.JavaMail.zimbra@u-pem.fr>
 <74BD3167-D5A8-44D0-9F52-0111C71E3053@oracle.com>
 <3EE20EA0-1DD7-4791-8B49-90739E0E6C0B@oracle.com>
 <92965CED-DA0D-4709-978B-EB5472EB0FFC@oracle.com>
 <560354821.440529.1587665109404.JavaMail.zimbra@u-pem.fr>
 <303B6825-9B90-4935-9C09-5B44DFC03E7D@oracle.com>
Message-ID: <24ff611e-35fe-0195-6b00-96f033b3f9fa@redhat.com>

On 4/23/20 11:41 PM, John Rose wrote:
> The longer we delay nailing down the transcoding layer, the more
> future features of the language we can use to make that layer more
> flexible and powerful.

Now and always.  :-)

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


From lhersch at dssgmbh.de  Tue May  5 14:43:27 2020
From: lhersch at dssgmbh.de (Lars Herschke)
Date: Tue, 05 May 2020 16:43:27 +0200
Subject: Unexpected behavior when changing the modifier of a member variable
 in connection with an inner class
Message-ID: <5EB17B8F.1030300@dssgmbh.de>

Hello,

there is a small test program in the appendix that I would like to know
about, bug or not.
The output of the program is the following for me.


main: set                outer.x=1
main: set                           inner.x=2
main: set                outer.y=1
main: set                           inner.y=2
work: out     private x: outer.x=1, inner.x=2, non-qualified.x=1
work: out non-private y: outer.y=1, inner.y=2, non-qualified.y=2
work: set                                      non-qualified.x=3
work: set                                      non-qualified.y=3
main: out     private x: outer.x=3, inner.x=2
main: out non-private y: outer.y=1, inner.y=3


Why does the interpretation of unqualified variables change here,
depending on the modifier.

Is this behavior desired and described somewhere or is it an error.

Thanks, Lars

From lhersch at dssgmbh.de  Tue May  5 14:50:41 2020
From: lhersch at dssgmbh.de (Lars Herschke)
Date: Tue, 05 May 2020 16:50:41 +0200
Subject: Unexpected behavior when changing the modifier of a member
 variable in connection with an inner class
In-Reply-To: <5EB17B8F.1030300@dssgmbh.de>
References: <5EB17B8F.1030300@dssgmbh.de>
Message-ID: <5EB17D41.4060203@dssgmbh.de>

Oh, i'm seeing attachments don't work in the mailing list. So here is
the code.

public class Outer
{
    private int x;
            int y;

    private class Inner extends Outer
    {
        void work()
        {
            System.out.println("work: out     private x: outer.x=" +
Outer.this.getX() + ", inner.x=" + this.getX() + ", non-qualified.x=" + x);
            System.out.println("work: out non-private y: outer.y=" +
Outer.this.getY() + ", inner.y=" + this.getY() + ", non-qualified.y=" + y);
            System.out.println("work: set
       non-qualified.x=3");
            x = 3;
            System.out.println("work: set
       non-qualified.y=3");
            y = 3;
        }
    }

    void setX(int value)
    {
        x = value;
    }

    int getX()
    {
        return x;
    }

    void setY(int value)
    {
        y = value;
    }

    int getY()
    {
        return y;
    }

    public static void main(String... args) {
        Outer out = new Outer();
        Outer.Inner inn = out.new Inner();
        System.out.println("main: set                outer.x=1");
        out.setX(1);
        System.out.println("main: set                           inner.x=2");
        inn.setX(2);
System.out.println("main: set                outer.y=1");
        out.setY(1);
        System.out.println("main: set                           inner.y=2");
        inn.setY(2);
        inn.work();
        System.out.println("main: out     private x: outer.x=" +
out.getX() + ", inner.x=" + inn.getX());
        System.out.println("main: out non-private y: outer.y=" +
out.getY() + ", inner.y=" + inn.getY());
    }
}


> Hello,
> 
> there is a small test program in the appendix that I would like to know
> about, bug or not.
> The output of the program is the following for me.
> 
> 
> main: set                outer.x=1
> main: set                           inner.x=2
> main: set                outer.y=1
> main: set                           inner.y=2
> work: out     private x: outer.x=1, inner.x=2, non-qualified.x=1
> work: out non-private y: outer.y=1, inner.y=2, non-qualified.y=2
> work: set                                      non-qualified.x=3
> work: set                                      non-qualified.y=3
> main: out     private x: outer.x=3, inner.x=2
> main: out non-private y: outer.y=1, inner.y=3
> 
> 
> Why does the interpretation of unqualified variables change here,
> depending on the modifier.
> 
> Is this behavior desired and described somewhere or is it an error.
> 
> Thanks, Lars
> 


From jesper at selskabet.org  Tue May  5 15:19:41 2020
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Tue, 5 May 2020 17:19:41 +0200
Subject: Unexpected behavior when changing the modifier of a member
 variable in connection with an inner class
In-Reply-To: <5EB17B8F.1030300@dssgmbh.de>
References: <5EB17B8F.1030300@dssgmbh.de>
Message-ID: <49C25817-94E9-4602-8A7E-389CDD42CD1A@selskabet.org>

Hi Lars

I'm not sure we're entirely on topic here, but I couldn't resist:

Are you preparing a puzzler talk, or writing a compiler or other semantic tool? ;-)

The detail is in https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.2 <https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.2>.

In "Inner", only one x is visible, namely Outer.this.x. The private x is not inherited into Inner, as per ?8.2 "Members of a class that are declared private are not inherited by subclasses of that class."

In "Inner", both y's are visible and this.y is the closest one, i.e. the one inherited from Outer, qualified as Outer.Inner.this.y. You can still access the other y, by using Outer.this.y.

Hope this "helps".

-Jesper

BTW, IMHO: While name inhertance and scope rules are tricky for members, they're mind-boggling for type names, at least for my mind.



From lhersch at dssgmbh.de  Wed May  6 07:35:55 2020
From: lhersch at dssgmbh.de (Lars Herschke)
Date: Wed, 06 May 2020 09:35:55 +0200
Subject: Unexpected behavior when changing the modifier of a member
 variable in connection with an inner class
In-Reply-To: <49C25817-94E9-4602-8A7E-389CDD42CD1A@selskabet.org>
References: <5EB17B8F.1030300@dssgmbh.de>
 <49C25817-94E9-4602-8A7E-389CDD42CD1A@selskabet.org>
Message-ID: <5EB268DB.8030704@dssgmbh.de>

Hello Jesper,

thanks a lot. The reference in the oracle-doc is exactly what I was
looking for. I don't write a tool. I debugged a piece of software that
did not behave as expected. The problem was precisely with the modifier.


Jesper Steen M?ller schrieb:
> Hi Lars
> 
> I'm not sure we're entirely on topic here, but I couldn't resist:
> 
> Are you preparing a puzzler talk, or writing a compiler or other
> semantic tool? ;-)
> 
> The detail is
> in https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.2.
> 
> In "Inner", only one x is visible, namely Outer.this.x. The private x is
> not inherited into Inner, as per ?8.2 "Members of a class that are
> declared |private| are not inherited by subclasses of that class."
> 
> In "Inner", both y's are visible and this.y is the closest one, i.e. the
> one inherited from Outer, qualified as Outer.Inner.this.y. You can still
> access the other y, by using Outer.this.y.
> 
> Hope this "helps".
> 
> -Jesper
> 
> BTW, IMHO: While name inhertance and scope rules are tricky for members,
> they're mind-boggling for type names, at least for my mind.
> 
> 


From joe.darcy at oracle.com  Thu May  7 16:16:05 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 7 May 2020 09:16:05 -0700
Subject: Invitation to Project Skara update, Thursday May 7, 2020 at 8:30
 am PST (UTC-8) / 4:30 pm GMT (UTC+0) / 5:30 pm CET (UTC+1)
In-Reply-To: <883c0164-cdef-af90-6c42-74ab9277058b@oracle.com>
References: <883c0164-cdef-af90-6c42-74ab9277058b@oracle.com>
Message-ID: <e56f99d1-5da0-613a-b6e1-8cb17d7629c8@oracle.com>

PS Slides for the presentation today:

https://cr.openjdk.java.net/~rwestberg/skara/skara_status_update_2020_05_07.pdf

To call out a particular item, we're looking to transition the mainline 
JDK development (http://hg.openjdk.java.net/jdk/jdk) to Skara at the end 
of JDK 15, start of JDK 16 time frame.

Thanks,

-Joe

On 4/30/2020 4:15 PM, Joe Darcy wrote:
> Hello,
>
> Project Skara has been investigating migrating from Mercurial to Git 
> for the OpenJDK Community's source code management needs. [1] Please 
> join the Skara team for an update on this work on Thursday May 7 at
>
> ???? 8:30 am PST (UTC-8) / 4:30 pm GMT (UTC+0) / 5:30 pm CET (UTC+1)
>
> The update will discuss OpenJDK projects that have transitioned to 
> using the Skara tooling, features of that tooling, and the future 
> roadmap. The meeting will be hosted on Zoom; connection details below.
>
> Cheers,
>
> -Joe
>
> [1] https://wiki.openjdk.java.net/display/SKARA; also see JEPs, JEP 
> 357: "Migrate from Mercurial to Git" 
> (http://openjdk.java.net/jeps/357) and JEP 369: "Migrate to GitHub." 
> (http://openjdk.java.net/jeps/369).
>
>

From michal at kleczek.org  Thu May 14 07:56:35 2020
From: michal at kleczek.org (=?utf-8?q?K=c5=82eczek=2c=20Micha=c5=82?=)
Date: Thu, 14 May 2020 07:56:35 +0000
Subject: Union types and exception handling
Message-ID: <em33e00d9c-9462-440f-a7ff-827d0e262e7a@lonn34339744a>

Hello All,

I am playing with javac lately looking for a way to implement some form 
of union types - along the lines of:

interface Function<S, T, E extends Exception> {
   T apply(S arg) throws E;
}

interface Stream<T, E extends Exception> {
   // resulting stream is parametrized with a union type
   <S, MapperEx extends Exception, ResultEx extends E | MapperEx> 
Stream<S, ResultEx> map(Function<? super T, S, MapperEx> mapper);
   boolean isEmpty() throws E;
}

<S, T, E extends IOException | ClassNotFoundException> T foo(Function<S, 
T, E> f, S arg) throws ClassNotFoundException {
   try {
     return f.apply(arg);
   }
   catch (IOException e) {
   }
}

A very limited form of union types is already implemented for 
multi-catch clauses and I am wondering
if:
- it can be reused
- anything more general has been discussed/prototyped - is anyone aware 
of such efforts?

Thanks,
Michal


From jianglizhou at google.com  Mon May 18 22:43:34 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Mon, 18 May 2020 15:43:34 -0700
Subject: Call for Discussion: New Project: Leyden
Message-ID: <CALrW1jxyx=t0DLSSs8JnOVhZuEFvOevw9A4wmnqEot9QP1wLYA@mail.gmail.com>

Didn't see this discussion until today. I think this will be welcomed by
Java developers! How do we participate in the project and coordinate?

I have been experimenting with preserving pre-initialized classes (at build
time) as part of the CDS archive image. Class pre-initialization can help
field and method pre-resolution and generate better AOT code. Here is a class
pre-resolution & pre-initialization proposal
<https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing>
that enhances
the existing Hotspot heap archiving and provides more general support to
pre-initialize classes and preserve static field values for both JDK
classes and application classes (loaded by system class loader). I adopted
the annotation approach in the proposal, after comparing it to other
alternatives, please see details in the design doc. Here are the slides
<https://docs.google.com/presentation/d/1pfHZugMalMAWISGLxrNODow-99A9-TC_6DUMnc15_Ko/edit?usp=sharing>
that contain the high-level overview of the design proposal.

My prototype that implements the proposal on JDK 11 showed ~2ms JVM startup
time improvement when pre-initializing ~100 JDK classes.

Best regards,

Jiangli

From vladimir.kozlov at oracle.com  Tue May 19 00:31:06 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 18 May 2020 17:31:06 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
Message-ID: <fedb592d-0418-d0cc-05a5-06746d30771a@oracle.com>

The HotSpot group will gladly participate in sponsoring this project.

Regards,
Vladimir Kozlov

On 4/27/20 9:38 AM, mark.reinhold at oracle.com wrote:
> I hereby invite discussion of a new Project, Leyden, whose primary goal
> will be to address the long-term pain points of Java?s slow startup time,
> slow time to peak performance, and large footprint.
> 
> Leyden will address these pain points by introducing a concept of _static
> images_ to the Java Platform, and to the JDK.
> 
>    - A static image is a standalone program, derived from an application,
>      which runs that application -- and no other.
> 
>    - A static image is a closed world: It cannot load classes from outside
>      the image, nor can it spin new bytecodes at run time.
> 
> These two constraints enable build-time analyses that can remove unused
> classes and identify class initializers which can be run at build time,
> thereby reducing both the size of the image and its startup time.  These
> constraints also enable aggressive ahead-of-time compilation, thereby
> reducing the image?s time to peak performance.
> 
> Static images are not for everyone, due to the closed-world constraint,
> nor are they for every type of application.  They often require manual
> configuration in order to achieve the best results.  We do, however,
> expect the results to be worthwhile in important deployment scenarios
> such as small embedded devices and the cloud.
> 
> Project Leyden will take inspiration from past efforts to explore this
> space, including the GNU Compiler for Java [1] and the Native Image
> feature of GraalVM [2].  Leyden will add static images to the Java
> Platform Specification, and we expect that GraalVM will evolve to
> implement that Specification.  Developers who use only the standard,
> specified static-image feature will then be able to switch with ease
> between Leyden (in the JDK), Native Image (in GraalVM), and whatever
> other conforming implementations may arise, choosing amongst tradeoffs
> of compile time, startup time, and image size.
> 
> We do not intend to implement Leyden by merging the Native Image code
> from GraalVM into the JDK.  Leyden will, rather, be based upon existing
> components in the JDK such as the HotSpot JVM, the `jaotc` ahead-of-time
> compiler [3], application class-data sharing [4], and the `jlink` linking
> tool [5].
> 
> I propose to lead this Project with an initial set of Reviewers that
> includes, but is not limited to, Alex Buckley, Bob Vandette, Claes
> Redestad, Igor Veresov, Ioi Lam, Mandy Chung, and Vladimir Kozlov.
> 
> This Project will start with a clone of the current JDK main-line
> release, JDK 15, and track main-line releases going forward.  We expect
> to deliver Leyden over time, in a series of JEPs that will likely span
> multiple feature releases.
> 
> Comments?
> 
> - Mark
> 
> 
> [1] https://en.wikipedia.org/wiki/GNU_Compiler_for_Java
> [2] https://www.graalvm.org/docs/reference-manual/native-image/
> [3] https://openjdk.java.net/jeps/295
> [4] https://openjdk.java.net/jeps/310
> [5] https://openjdk.java.net/jeps/282
> 

From Alan.Bateman at oracle.com  Tue May 19 07:12:04 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 May 2020 08:12:04 +0100
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <fedb592d-0418-d0cc-05a5-06746d30771a@oracle.com>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
 <fedb592d-0418-d0cc-05a5-06746d30771a@oracle.com>
Message-ID: <038e48d1-e2d4-463f-2f01-2f778005360d@oracle.com>

On 19/05/2020 01:31, Vladimir Kozlov wrote:
> The HotSpot group will gladly participate in sponsoring this project.
The Core Libraries group is happy to co-sponsor this project too.

-Alan.

From mike at plan99.net  Tue May 19 14:07:33 2020
From: mike at plan99.net (Mike Hearn)
Date: Tue, 19 May 2020 10:07:33 -0400
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <20200428094038.5375939@eggemoggin.niobe.net>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
 <CA+3eh12PQsN_DU3BVq4Xd7ow3955bZf19qg3UPVkkdzkW+VyQw@mail.gmail.com>
 <20200428094038.5375939@eggemoggin.niobe.net>
Message-ID: <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>

Although this may be veering into an unwanted "what will it be" discussion,
I'm curious how fundamental it is that an image must be either static or
dynamic.

HotSpot already does some speculative optimisations on the assumption that
new code isn't loaded e.g. the class hierarchy analysis. Speculative
optimisations do a great job of removing costs of dynamic language features
like class redefinition. Leyden seems to be proposed as a new 'mode' of the
Java language, but could it also be envisioned as a new set of
optimisations that optimistically assume no dynamic code loading? For
instance, could a module be marked as "available to dynamically loaded
code" and then the points-to analysis / dead code elimination would pin the
public API of the module before running, and if it's not marked as such,
then DCE runs across the boundaries too?

A big part of the SubstrateVM startup time win appears to come from a more
aggressive version of the AppCDS heap serialisation feature, and a general
focus on startup time to the exclusion of other factors (e.g. there's no
notion of module layers or module boundary enforcement). To what extent is
the closed-world assumption contributing to the footprint/startup time wins
vs other spec changes - is that known?

These questions aren't rhetorical, I don't have any view on the answers.
After playing around with native-image and seeing mixed results (e.g.
smaller wins than I thought for GUI JavaFX apps), and looking at the work
being done on AppCDS, I started to wonder if HotSpot can eventually match
the startup time and footprint wins of native-image without the
compatibility breaking changes SVM makes to get there, just through
doubling down on current optimisation techniques like jlink and speculation.

Thanks for any insight offered!

From hohensee at amazon.com  Tue May 19 15:53:00 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 19 May 2020 15:53:00 +0000
Subject: Call for Discussion: New Project: Leyden
Message-ID: <4AB85D2E-5449-40A4-8826-F3A0B1B48102@amazon.com>

See also this sub-thread.

https://mail.openjdk.java.net/pipermail/discuss/2020-April/005435.html

Others may correct me, but the gestalt answer I think I got was along the lines of "Project Leyden is restricted to the creation of static images, but feel free to propose a similar project that would allow full Java language support".

I agree that such new, relatively-long-compile-time, optimizations are possible and desirable. What amounts to "whole program" (in quotes because you can't see the whole program in the face of native code, but you can see "large chunks of the whole program") type flow analysis can give you much or the majority of the information you can get from profile-driven type flow analysis and inlining.

Thanks,
Paul

?On 5/19/20, 7:10 AM, "discuss on behalf of Mike Hearn" <discuss-bounces at openjdk.java.net on behalf of mike at plan99.net> wrote:

    Although this may be veering into an unwanted "what will it be" discussion,
    I'm curious how fundamental it is that an image must be either static or
    dynamic.

    HotSpot already does some speculative optimisations on the assumption that
    new code isn't loaded e.g. the class hierarchy analysis. Speculative
    optimisations do a great job of removing costs of dynamic language features
    like class redefinition. Leyden seems to be proposed as a new 'mode' of the
    Java language, but could it also be envisioned as a new set of
    optimisations that optimistically assume no dynamic code loading? For
    instance, could a module be marked as "available to dynamically loaded
    code" and then the points-to analysis / dead code elimination would pin the
    public API of the module before running, and if it's not marked as such,
    then DCE runs across the boundaries too?

    A big part of the SubstrateVM startup time win appears to come from a more
    aggressive version of the AppCDS heap serialisation feature, and a general
    focus on startup time to the exclusion of other factors (e.g. there's no
    notion of module layers or module boundary enforcement). To what extent is
    the closed-world assumption contributing to the footprint/startup time wins
    vs other spec changes - is that known?

    These questions aren't rhetorical, I don't have any view on the answers.
    After playing around with native-image and seeing mixed results (e.g.
    smaller wins than I thought for GUI JavaFX apps), and looking at the work
    being done on AppCDS, I started to wonder if HotSpot can eventually match
    the startup time and footprint wins of native-image without the
    compatibility breaking changes SVM makes to get there, just through
    doubling down on current optimisation techniques like jlink and speculation.

    Thanks for any insight offered!


From john.r.rose at oracle.com  Tue May 19 21:09:56 2020
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 19 May 2020 14:09:56 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
 <CA+3eh12PQsN_DU3BVq4Xd7ow3955bZf19qg3UPVkkdzkW+VyQw@mail.gmail.com>
 <20200428094038.5375939@eggemoggin.niobe.net>
 <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>
Message-ID: <2DBEB037-3BA4-4901-8A67-006153A40B68@oracle.com>

On May 19, 2020, at 7:07 AM, Mike Hearn <mike at plan99.net> wrote:
> 
> Leyden seems to be proposed as a new 'mode' of the
> Java language, but could it also be envisioned as a new set of
> optimisations that optimistically assume no dynamic code loading? 

I think I see what you are asking.  Everybody responsible for JVM
startup has been asking themselves that for 25 years.  The answer
seems to be ?no, all the ideas have been explored, several times over?.

(An analogous thing is happening with Valhalla.  For 20 years we
said, ?If we are smart enough with escape analysis and inlining,
we won?t need C-style structs.?  Nice sentiment, but it doesn?t work,
and we do need some rule changes to get flattened data.  The very
hard problem, and our 5-year mission, is to figure out how to
formulate the new rules for inline classes so they fit in almost
like they were designed in from the start.)

Eventually you have to stop losing at the game as it is, by changing
the rules, not saying ?I?ll play better next time, really I will.?
Positively framed:  We?ve gotten so good at the startup game,
we can?t get any better without rule changes.

Leyden is carefully positioned to allow the changing of Java?s basic
rules, with great care, if needed.  I think it will be needed, not that
I?m in a hurry to do so.  The rules that get us every time have to do
with the ordering of initializers, and (inevitably) the management
of side effect interactions due to ordering.  We need to cut ourselves
more slack in the ordering of initialization order, if startup is to
get better.  At least, that?s my view, and Leyden is the place to run
experiments to prove or disprove it.

? John

From ioi.lam at oracle.com  Thu May 21 18:59:09 2020
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 21 May 2020 11:59:09 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
 <CA+3eh12PQsN_DU3BVq4Xd7ow3955bZf19qg3UPVkkdzkW+VyQw@mail.gmail.com>
 <20200428094038.5375939@eggemoggin.niobe.net>
 <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>
Message-ID: <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com>

On 5/19/20 7:07 AM, Mike Hearn wrote:
> Although this may be veering into an unwanted "what will it be" discussion,
> I'm curious how fundamental it is that an image must be either static or
> dynamic.
>
> HotSpot already does some speculative optimisations on the assumption that
> new code isn't loaded e.g. the class hierarchy analysis. Speculative
> optimisations do a great job of removing costs of dynamic language features
> like class redefinition. Leyden seems to be proposed as a new 'mode' of the
> Java language, but could it also be envisioned as a new set of
> optimisations that optimistically assume no dynamic code loading? For
> instance, could a module be marked as "available to dynamically loaded
> code" and then the points-to analysis / dead code elimination would pin the
> public API of the module before running, and if it's not marked as such,
> then DCE runs across the boundaries too?
>
> A big part of the SubstrateVM startup time win appears to come from a more
> aggressive version of the AppCDS heap serialisation feature, and a general
> focus on startup time to the exclusion of other factors (e.g. there's no
> notion of module layers or module boundary enforcement). To what extent is
> the closed-world assumption contributing to the footprint/startup time wins
> vs other spec changes - is that known?
>
> These questions aren't rhetorical, I don't have any view on the answers.
> After playing around with native-image and seeing mixed results (e.g.
> smaller wins than I thought for GUI JavaFX apps), and looking at the work
> being done on AppCDS, I started to wonder if HotSpot can eventually match
> the startup time and footprint wins of native-image without the
> compatibility breaking changes SVM makes to get there, just through
> doubling down on current optimisation techniques like jlink and speculation.
>
> Thanks for any insight offered!
Hi Mike,

Thanks for mentioning AppCDS. As someone working primarily on AppCDS, I 
am happy to hear that you have a good impression on its current state 
and potentials. Over the past few years, we have done many start-up 
optimizations, in AppCDS and many other parts of the JDK (core libs, 
jlink, hotspot, etc). You can see Claes Redestat's excellent 
presentation here:

https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html

Since JDK9, we have cut down the HelloWorld start-up time from about 
120ms in JDK 9? to less than 40ms in JDK 14. We will be eking out a few 
more ms in JDK 15.

A large part of the improvement is due to archiving heap objects into 
CDS -- mostly related module information. In JDK 16, I hope to finish 
JDK-8244778 (Archive complete module graph in CDS). My prototype shows 
about 7~10ms improvement in start-up time.

The problem with archiving heap objects, though, is currently it 
requires a lot of manual work and knowledge about the code. I am 
spending a lot of effort to take out 7~10ms for JDK-8244778. To be 
useful in general applications, we need to make it much easier to use.

A key assumption of archiving heap objects is -- part of my program will 
always produce the same set of objects, so I can execute it ahead of 
time and save the results for later use. Maybe "closed world" sounds too 
strong, but at least I need to have a "stable world", where I am 
guaranteed to always see the exact same bytecodes in the exact set of 
classes, so I can analyze them to see if they will indeed always produce 
the same results.

The problem is Java classes are loosely coupled, and the linking happens 
only at execution time. A reference to "Foo" can give you a completely 
different class (an app can even define classes dynamically). I hope we 
can introduce a new "linking" concept in the JLS, so Java classes can be 
more strongly combined together into a bigger execution unit.

For example, a "linked" app will already have Foo in the VM's dictionary 
before any bytecodes are executed. So the app won't be able to 
substitute an different Foo. I think this will help not only AppCDS but 
also AOT compilation.

I don't think speculation can help here -- if we have archived a set of 
objects that involves Foo, and have used these objects part away during 
execution, and (assuming we have not yet touched any archived Foo 
objects yet) the app defines a new Foo class, we are stuck. It would 
take tremendous effort to look at the archived objects to patch the new 
version of the Foo objects, and this won't be possible if you add or 
remove fields in Foo. We would also need to add a lot of run time checks 
at every step to guarantee that we indeed load the same classes. All 
these checks will be counterproductive to start-up.

Thanks
- Ioi






From jianglizhou at google.com  Thu May 21 19:35:42 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 21 May 2020 12:35:42 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
 <CA+3eh12PQsN_DU3BVq4Xd7ow3955bZf19qg3UPVkkdzkW+VyQw@mail.gmail.com>
 <20200428094038.5375939@eggemoggin.niobe.net>
 <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>
 <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com>
Message-ID: <CALrW1jxO0tkvqmUy2TV_p9oDLGXx7SLmbJ4C7K4g7sX4AqqtnQ@mail.gmail.com>

Hi Ioi,

On Thu, May 21, 2020 at 11:59 AM Ioi Lam <ioi.lam at oracle.com> wrote:
>
> On 5/19/20 7:07 AM, Mike Hearn wrote:
> > Although this may be veering into an unwanted "what will it be"
discussion,
> > I'm curious how fundamental it is that an image must be either static or
> > dynamic.
> >
> > HotSpot already does some speculative optimisations on the assumption
that
> > new code isn't loaded e.g. the class hierarchy analysis. Speculative
> > optimisations do a great job of removing costs of dynamic language
features
> > like class redefinition. Leyden seems to be proposed as a new 'mode' of
the
> > Java language, but could it also be envisioned as a new set of
> > optimisations that optimistically assume no dynamic code loading? For
> > instance, could a module be marked as "available to dynamically loaded
> > code" and then the points-to analysis / dead code elimination would pin
the
> > public API of the module before running, and if it's not marked as such,
> > then DCE runs across the boundaries too?
> >
> > A big part of the SubstrateVM startup time win appears to come from a
more
> > aggressive version of the AppCDS heap serialisation feature, and a
general
> > focus on startup time to the exclusion of other factors (e.g. there's no
> > notion of module layers or module boundary enforcement). To what extent
is
> > the closed-world assumption contributing to the footprint/startup time
wins
> > vs other spec changes - is that known?
> >
> > These questions aren't rhetorical, I don't have any view on the answers.
> > After playing around with native-image and seeing mixed results (e.g.
> > smaller wins than I thought for GUI JavaFX apps), and looking at the
work
> > being done on AppCDS, I started to wonder if HotSpot can eventually
match
> > the startup time and footprint wins of native-image without the
> > compatibility breaking changes SVM makes to get there, just through
> > doubling down on current optimisation techniques like jlink and
speculation.
> >
> > Thanks for any insight offered!
> Hi Mike,
>
> Thanks for mentioning AppCDS. As someone working primarily on AppCDS, I
> am happy to hear that you have a good impression on its current state
> and potentials. Over the past few years, we have done many start-up
> optimizations, in AppCDS and many other parts of the JDK (core libs,
> jlink, hotspot, etc). You can see Claes Redestat's excellent
> presentation here:
>
> https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html
>
> Since JDK9, we have cut down the HelloWorld start-up time from about
> 120ms in JDK 9  to less than 40ms in JDK 14. We will be eking out a few
> more ms in JDK 15.
>
> A large part of the improvement is due to archiving heap objects into
> CDS -- mostly related module information. In JDK 16, I hope to finish
> JDK-8244778 (Archive complete module graph in CDS). My prototype shows
> about 7~10ms improvement in start-up time.
>
> The problem with archiving heap objects, though, is currently it
> requires a lot of manual work and knowledge about the code. I am
> spending a lot of effort to take out 7~10ms for JDK-8244778. To be
> useful in general applications, we need to make it much easier to use.
>

Looks like we are shooting for the same goal and both are trying to improve
the Java heap (object subgraph) archiving mechanism for bigger performance
gain. :) That's good to hear! As the author of the original code, I truly
believed it's potential and always wanted to make it for more general
pre-initialization via opt-in approach. To help corrodation and avoid
potential waste of work, please let me know if there will be any
duplication or similar work that's described in the selective class
pre-init proposal
<https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing>,
particularly on generalizing subgraph archiving (with multi-phases,
multi-class state, including mirror, etc). I'm hoping to contribute the
proposed work to OpenJDK via project Leyden.

Thanks!

Jiangli

> A key assumption of archiving heap objects is -- part of my program will
> always produce the same set of objects, so I can execute it ahead of
> time and save the results for later use. Maybe "closed world" sounds too
> strong, but at least I need to have a "stable world", where I am
> guaranteed to always see the exact same bytecodes in the exact set of
> classes, so I can analyze them to see if they will indeed always produce
> the same results.
>
> The problem is Java classes are loosely coupled, and the linking happens
> only at execution time. A reference to "Foo" can give you a completely
> different class (an app can even define classes dynamically). I hope we
> can introduce a new "linking" concept in the JLS, so Java classes can be
> more strongly combined together into a bigger execution unit.
>
> For example, a "linked" app will already have Foo in the VM's dictionary
> before any bytecodes are executed. So the app won't be able to
> substitute an different Foo. I think this will help not only AppCDS but
> also AOT compilation.
>
> I don't think speculation can help here -- if we have archived a set of
> objects that involves Foo, and have used these objects part away during
> execution, and (assuming we have not yet touched any archived Foo
> objects yet) the app defines a new Foo class, we are stuck. It would
> take tremendous effort to look at the archived objects to patch the new
> version of the Foo objects, and this won't be possible if you add or
> remove fields in Foo. We would also need to add a lot of run time checks
> at every step to guarantee that we indeed load the same classes. All
> these checks will be counterproductive to start-up.
>
> Thanks
> - Ioi
>
>
>
>
>

From mark.reinhold at oracle.com  Thu May 21 22:48:09 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 21 May 2020 15:48:09 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <CALrW1jxyx=t0DLSSs8JnOVhZuEFvOevw9A4wmnqEot9QP1wLYA@mail.gmail.com>
References: <CALrW1jxyx=t0DLSSs8JnOVhZuEFvOevw9A4wmnqEot9QP1wLYA@mail.gmail.com>
Message-ID: <20200521154809.788017090@eggemoggin.niobe.net>

2020/5/18 15:43:34 -0700, jianglizhou at google.com:
> Didn't see this discussion until today. I think this will be welcomed by
> Java developers! How do we participate in the project and coordinate?

I?ll shortly start the CFV to create the Project.  Once the Project
exists, your participation will be most welcome!

> I have been experimenting with preserving pre-initialized classes (at build
> time) as part of the CDS archive image. Class pre-initialization can help
> field and method pre-resolution and generate better AOT code. Here is a class
> pre-resolution & pre-initialization proposal
> <https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing>
> that enhances
> the existing Hotspot heap archiving and provides more general support to
> pre-initialize classes and preserve static field values for both JDK
> classes and application classes (loaded by system class loader).

Sorry, but for IP clarity could you please either post that document to
cr.openjdk.java.net or enter it into a JBS issue?  (Likewise for the
slides that you mention later on.)

>                                                                  I adopted
> the annotation approach in the proposal, after comparing it to other
> alternatives, please see details in the design doc.

In a prototype, using an annotation to identify pre-initializable
classes is fine.  In the long run, however, we?ll likely wind up with a
keyword since annotations must not be used to change language semantics.

- Mark

From jianglizhou at google.com  Fri May 22 00:23:47 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 21 May 2020 17:23:47 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <20200521154809.788017090@eggemoggin.niobe.net>
References: <CALrW1jxyx=t0DLSSs8JnOVhZuEFvOevw9A4wmnqEot9QP1wLYA@mail.gmail.com>
 <20200521154809.788017090@eggemoggin.niobe.net>
Message-ID: <CALrW1jzX4+_FWwZbGxbriGyjcy_KGj2U2ffq+R5CyYHrMiw6pg@mail.gmail.com>

On Thu, May 21, 2020 at 3:48 PM <mark.reinhold at oracle.com> wrote:

> 2020/5/18 15:43:34 -0700, jianglizhou at google.com:
> > Didn't see this discussion until today. I think this will be welcomed by
> > Java developers! How do we participate in the project and coordinate?
>
> I?ll shortly start the CFV to create the Project.  Once the Project
> exists, your participation will be most welcome!
>

Sounds great!


>
> > I have been experimenting with preserving pre-initialized classes (at
> build
> > time) as part of the CDS archive image. Class pre-initialization can help
> > field and method pre-resolution and generate better AOT code. Here is a
> class
> > pre-resolution & pre-initialization proposal
> > <
> https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing
> >
> > that enhances
> > the existing Hotspot heap archiving and provides more general support to
> > pre-initialize classes and preserve static field values for both JDK
> > classes and application classes (loaded by system class loader).
>
> Sorry, but for IP clarity could you please either post that document to
> cr.openjdk.java.net or enter it into a JBS issue?  (Likewise for the
> slides that you mention later on.)
>

I've posted the docs to cr.openjdk.java.net:

Design doc:
http://cr.openjdk.java.net/~jiangli/Leyden/Java%20Class%20Pre-resolution%20and%20Pre-initialization%20(OpenJDK).pdf
Slides:
http://cr.openjdk.java.net/~jiangli/Leyden/Selectively%20Pre-initializing%20and%20Preserving%20Java%20Classes%20(OpenJDK).pdf

Will also attach them to JBS as suggested.


> >                                                                  I
> adopted
> > the annotation approach in the proposal, after comparing it to other
> > alternatives, please see details in the design doc.
>
> In a prototype, using an annotation to identify pre-initializable
> classes is fine.  In the long run, however, we?ll likely wind up with a
> keyword since annotations must not be used to change language semantics.
>

That sounds workable. The underlying heap object archiving mechanism can
support different approaches (list, interface, annotation, keyword, etc) as
an 'indicator' for pre-initializing & preserving classes and static fields.

Really excited about the project!

Best regards,
Jiangli


> - Mark
>

From mike at plan99.net  Fri May 22 10:11:23 2020
From: mike at plan99.net (Mike Hearn)
Date: Fri, 22 May 2020 03:11:23 -0700
Subject: Call for Discussion: New Project: Leyden
In-Reply-To: <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com>
References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net>
 <CA+3eh12PQsN_DU3BVq4Xd7ow3955bZf19qg3UPVkkdzkW+VyQw@mail.gmail.com>
 <20200428094038.5375939@eggemoggin.niobe.net>
 <CANEZrP3YY0sAjU8AstaTuBWOGOeCHZg9SZKQwOvNOKUT-LRRbw@mail.gmail.com>
 <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com>
Message-ID: <CANEZrP3mAY6ZAk1xP5NWD+5SWJqwAWLjeSnAdGKAF_gx-AiziQ@mail.gmail.com>

Thanks Ioi, and thanks to Jiangli for the interesting presentation.

Yes, class definition changes are certainly a problem. I spent a bit of
time looking at the AppCDS code a few months ago, back when I thought the
feature seemed not to be receiving much attention (glad to see now that
this was wrong!). I was curious if a customised JDK could be used to make
desktop apps start faster.

My investigation went down the path of neither an annotation nor language
change but rather a "box api" like this:

private static final Foo = new Archive<>(() ->
    return new Foo("some-expensive-to-load-thing.xml");
);

For example, caching JavaFX scene graphs loaded from FXML. The Archive
class is defined to optionally run the lambda, but it may choose not to if
a prior object graph can be loaded.

For the classloader situation I was digging in to whether AppCDS archives
could be scoped per module. At the moment OpenJDK seems to be going down
the path of shipping-oriented optimisations e.g. jlink, "App"CDS. I wanted
to see how re-usable the infrastructure was for use during app development
itself, because one area where startup time really matters, and I don't see
it being mentioned as part of Leyden, is the edit/compile/run cycle.
Obviously with an app-centric system the answer is it can't help because
the app is always changing. With a more module-centric view, if the
developer uses JPMS enthusiastically e.g. one module per screen of the app,
then other modules could be seen as unchanging and have optimisations
applied to them, i.e. AppCDS archives dumped during a prior shutdown could
be reused.

For this to work you have to know if a module has changed, so you can try
to load or discard cached data. In JMOD/JAR form there's a checksumming
mechanism added to provide some basic enforcement of "exports ? to ?"
clauses. So I started looking at whether that could be used, but during
development modules are often in exploded/directory form. So you'd need to
be able to rapidly determine if an entire directory hierarchy had changed,
*or* monitor it using something like Facebook Watchman. This took me down
the road of thinking you'd need build system integration, which OpenJDK
cannot have in its current scope. My conclusion was that the Java world
would benefit from some kind of ?ber-project on top of OpenJDK and other
tools that integrated them more tightly together ? and that's where it
ended.

No specific implementation conclusions, but I hope a more module-centric vs
app-centric set of features is explored - one of the big wins of the Java
platform is the combination of static type checking *and* script-like
edit/run cycles. It'd be nice if some of the Leyden work finds ways to be
applicable prior to a final jpackage-for-ship pass is done.




On Thu, May 21, 2020 at 20:59:09, Ioi Lam <ioi.lam at oracle.com> wrote:

> On 5/19/20 7:07 AM, Mike Hearn wrote:
>
> Although this may be veering into an unwanted "what will it be"
> discussion, I'm curious how fundamental it is that an image must be either
> static or dynamic.
>
> HotSpot already does some speculative optimisations on the assumption that
> new code isn't loaded e.g. the class hierarchy analysis. Speculative
> optimisations do a great job of removing costs of dynamic language features
> like class redefinition. Leyden seems to be proposed as a new 'mode' of the
> Java language, but could it also be envisioned as a new set of
> optimisations that optimistically assume no dynamic code loading? For
> instance, could a module be marked as "available to dynamically loaded
> code" and then the points-to analysis / dead code elimination would pin the
> public API of the module before running, and if it's not marked as such,
> then DCE runs across the boundaries too?
>
> A big part of the SubstrateVM startup time win appears to come from a more
> aggressive version of the AppCDS heap serialisation feature, and a general
> focus on startup time to the exclusion of other factors (e.g. there's no
> notion of module layers or module boundary enforcement). To what extent is
> the closed-world assumption contributing to the footprint/startup time wins
> vs other spec changes - is that known?
>
> These questions aren't rhetorical, I don't have any view on the answers.
> After playing around with native-image and seeing mixed results (e.g.
> smaller wins than I thought for GUI JavaFX apps), and looking at the work
> being done on AppCDS, I started to wonder if HotSpot can eventually match
> the startup time and footprint wins of native-image without the
> compatibility breaking changes SVM makes to get there, just through
> doubling down on current optimisation techniques like jlink and
> speculation.
>
> Thanks for any insight offered!
>
> Hi Mike,
>
> Thanks for mentioning AppCDS. As someone working primarily on AppCDS, I am
> happy to hear that you have a good impression on its current state and
> potentials. Over the past few years, we have done many start-up
> optimizations, in AppCDS and many other parts of the JDK (core libs, jlink,
> hotspot, etc). You can see Claes Redestat's excellent presentation here:
>
> https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html
>
> Since JDK9, we have cut down the HelloWorld start-up time from about 120ms
> in JDK 9  to less than 40ms in JDK 14. We will be eking out a few more ms
> in JDK 15.
>
> A large part of the improvement is due to archiving heap objects into CDS
> -- mostly related module information. In JDK 16, I hope to finish
> JDK-8244778 (Archive complete module graph in CDS). My prototype shows
> about 7~10ms improvement in start-up time.
>
> The problem with archiving heap objects, though, is currently it requires
> a lot of manual work and knowledge about the code. I am spending a lot of
> effort to take out 7~10ms for JDK-8244778. To be useful in general
> applications, we need to make it much easier to use.
>
> A key assumption of archiving heap objects is -- part of my program will
> always produce the same set of objects, so I can execute it ahead of time
> and save the results for later use. Maybe "closed world" sounds too strong,
> but at least I need to have a "stable world", where I am guaranteed to
> always see the exact same bytecodes in the exact set of classes, so I can
> analyze them to see if they will indeed always produce the same results.
>
> The problem is Java classes are loosely coupled, and the linking happens
> only at execution time. A reference to "Foo" can give you a completely
> different class (an app can even define classes dynamically). I hope we can
> introduce a new "linking" concept in the JLS, so Java classes can be more
> strongly combined together into a bigger execution unit.
>
> For example, a "linked" app will already have Foo in the VM's dictionary
> before any bytecodes are executed. So the app won't be able to substitute
> an different Foo. I think this will help not only AppCDS but also AOT
> compilation.
>
> I don't think speculation can help here -- if we have archived a set of
> objects that involves Foo, and have used these objects part away during
> execution, and (assuming we have not yet touched any archived Foo objects
> yet) the app defines a new Foo class, we are stuck. It would take
> tremendous effort to look at the archived objects to patch the new version
> of the Foo objects, and this won't be possible if you add or remove fields
> in Foo. We would also need to add a lot of run time checks at every step to
> guarantee that we indeed load the same classes. All these checks will be
> counterproductive to start-up.
>
> Thanks
> - Ioi
>

From neugens at redhat.com  Wed May 27 15:32:59 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 27 May 2020 17:32:59 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <CAJwKKmZvQdxMk8dCK4M=oRSGrVHwLYG4auhxToX9b3JDcZHp5A@mail.gmail.com>

Vote: Yes!

Cheers,
Mario

On Wed, May 27, 2020 at 5:32 PM <mark.reinhold at oracle.com> wrote:
>
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From adinn at redhat.com  Wed May 27 15:34:48 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 27 May 2020 16:34:48 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <d0ab6c49-d236-f15e-5286-7ad5a9801b21@redhat.com>

Vote: yes

On 27/05/2020 16:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
> 

-- 
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From brian.goetz at oracle.com  Wed May 27 15:37:22 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 May 2020 11:37:22 -0400
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <5f75237f-9fd6-e4de-dbbc-07c969dfee4a@oracle.com>

Vote: Yes.

On 5/27/2020 11:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From Alan.Bateman at oracle.com  Wed May 27 15:41:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 27 May 2020 16:41:46 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <7901d026-c65c-1fa3-a3a9-f8d07ce80678@oracle.com>

Vote: yes

From chris.hegarty at oracle.com  Wed May 27 15:42:31 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 27 May 2020 16:42:31 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <AB532E30-0E62-4626-B4D4-783B8E068506@oracle.com>

Vote: YES

-Chris.

> On 27 May 2020, at 16:24, mark.reinhold at oracle.com wrote:
> 
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.


From mbalao at redhat.com  Wed May 27 15:52:00 2020
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 27 May 2020 12:52:00 -0300
Subject: CFV: New Project: Leyden
In-Reply-To: <CAJwKKmZvQdxMk8dCK4M=oRSGrVHwLYG4auhxToX9b3JDcZHp5A@mail.gmail.com>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
 <CAJwKKmZvQdxMk8dCK4M=oRSGrVHwLYG4auhxToX9b3JDcZHp5A@mail.gmail.com>
Message-ID: <d57cfdb7-a035-2738-5efe-3b22696e8bd6@redhat.com>

Vote: Yes

On 5/27/20 12:32 PM, Mario Torre wrote:
> On Wed, May 27, 2020 at 5:32 PM <mark.reinhold at oracle.com> wrote:
>>
>> I hereby propose the creation a new Project, Leyden, with me as
>> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>>
>> Leyden?s primary goal will be to address the long-term pain points
>> of Java?s slow startup time, slow time to peak performance, and large
>> footprint.  Leyden will address these pain points by introducing a
>> concept of static images to the Java Platform, and to the JDK.
>>
>> For further details, please see the call for discussion [1].
>>
>> I propose that the initial Reviewers of this Project include Alex
>> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
>> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
>> and Vladimir Kozlov.
>>
>> I expect ongoing contributions in the form of experience reports,
>> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
>> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>>
>> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>>
>> Only current OpenJDK Members [2] are eligible to vote on this motion.
>> Votes must be cast in the open on the discuss list.  Replying to this
>> message is sufficient if your mail program honors the Reply-To header.
>>
>> For Lazy Consensus voting instructions, see [3].
>>
>> - Mark
>>
>>
>> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
>> [2] https://openjdk.java.net/census#members
>> [3] https://openjdk.java.net/projects/#new-project-vote
>>
> 
> 


From gnu.andrew at redhat.com  Wed May 27 15:56:27 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 May 2020 16:56:27 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <5e1a70e4-47d4-7c6b-ee6e-489bfa09bc6e@redhat.com>

On 27/05/2020 16:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
> 

Vote: Yes
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From tmarble at info9.net  Wed May 27 16:01:35 2020
From: tmarble at info9.net (Tom Marble)
Date: Wed, 27 May 2020 16:01:35 +0000
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <CABbwLD_puspYb=QUtpn-Xqwwp68=z9Y5cu8UfgFnbn8_xviDig@mail.gmail.com>

On Wed, May 27, 2020 at 3:38 PM <mark.reinhold at oracle.com> wrote:

> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>

Vote: yes

Excellent!

--Tom

From joe.darcy at oracle.com  Wed May 27 16:03:57 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 27 May 2020 09:03:57 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <56c0da0b-db08-a774-3f6d-13ef41d06114@oracle.com>

Vote: yes

-Joe

On 5/27/2020 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote

From james.laskey at oracle.com  Wed May 27 16:15:01 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 27 May 2020 13:15:01 -0300
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <166B7777-DB37-4137-8445-9F61A521189F@oracle.com>

Vote: Yes

> On May 27, 2020, at 12:24 PM, mark.reinhold at oracle.com wrote:
> 
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From Roger.Riggs at oracle.com  Wed May 27 16:18:22 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 27 May 2020 12:18:22 -0400
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <6beb7429-5187-a2ba-7b26-c0fcb8e748d0@oracle.com>

Vote: Yes

On 5/27/20 11:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.


From magnus.ihse.bursie at oracle.com  Wed May 27 16:33:22 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 27 May 2020 18:33:22 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <b0f0ffa4-fc30-10ab-ad46-49f6d05ea647@oracle.com>

Vote: yes

/Magnus

On 2020-05-27 17:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From vicente.romero at oracle.com  Wed May 27 16:36:20 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 27 May 2020 12:36:20 -0400
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <03291146-9cbc-1cbb-8afc-0d28f3e5b79f@oracle.com>

vote: yes

Vicente

On 5/27/20 11:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From maurizio.cimadamore at oracle.com  Wed May 27 16:37:40 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 May 2020 17:37:40 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <a075cb91-cc14-a68f-eb04-a3c73d9f04b6@oracle.com>

Vote: yes!

Maurizio

On 27/05/2020 16:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote

From dalibor.topic at oracle.com  Wed May 27 16:51:51 2020
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Wed, 27 May 2020 18:51:51 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <16f63ab5-4282-2ba3-8863-602e9fcbd2f1@oracle.com>

Vote: Yes.

On 27.05.2020 17:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>, Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From thomas.stuefe at gmail.com  Wed May 27 17:13:36 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 May 2020 19:13:36 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <CAA-vtUwj4jibEQ_Jtu=exJ5me1Ge9bKDC30B1uZdKCzRdKQkdQ@mail.gmail.com>

Vote: yes

On Wed, May 27, 2020 at 5:31 PM <mark.reinhold at oracle.com> wrote:

> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
>

From vladimir.kozlov at oracle.com  Wed May 27 17:21:08 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 27 May 2020 10:21:08 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <ed7bd381-1694-21b6-971d-ad86da096798@oracle.com>

Vote: yes

On 5/27/20 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
> 

From mark.reinhold at oracle.com  Wed May 27 17:24:01 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 27 May 2020 10:24:01 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <20200527102401.558344902@eggemoggin.niobe.net>

Vote: yes

- Mark

From mandy.chung at oracle.com  Wed May 27 17:35:39 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 27 May 2020 10:35:39 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <37e2be20-e5ae-a473-e1cd-59d9bf933ae6@oracle.com>

Vote: yes

Mandy

On 5/27/20 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From daniel.fuchs at oracle.com  Wed May 27 17:38:00 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 27 May 2020 18:38:00 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <90fad457-2db8-1f74-a2cd-f32b3c26f0f0@oracle.com>

Vote: yes

best regards,

-- daniel

On 27/05/2020 16:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.

From ChrisPhi at LGonQn.Org  Wed May 27 17:40:09 2020
From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O)
Date: Wed, 27 May 2020 13:40:09 -0400
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <0f738352-a24f-a108-0813-0ceac28f5540@LGonQn.Org>

Vote: yes

ChrisPhi

From brent.christian at oracle.com  Wed May 27 17:43:20 2020
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 27 May 2020 10:43:20 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <ae1ac8c4-8df4-91ce-5bac-1570757c2ac1@oracle.com>

Vote: Yes

On 5/27/20 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 

From huizhe.wang at oracle.com  Wed May 27 18:04:07 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 27 May 2020 11:04:07 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <0190277d-62ee-722e-4013-e0ef0fd1143e@oracle.com>

Vote: Yes

Joe (joehw)

On 5/27/2020 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.


From jesper.wilhelmsson at oracle.com  Wed May 27 19:58:07 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 27 May 2020 21:58:07 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <82740F87-5D5E-419A-A90A-4F49917BD789@oracle.com>

Vote: Yes
/Jesper

> On 27 May 2020, at 17:24, mark.reinhold at oracle.com wrote:
> 
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From cthalinger at twitter.com  Wed May 27 20:06:45 2020
From: cthalinger at twitter.com (Christian Thalinger)
Date: Wed, 27 May 2020 10:06:45 -1000
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <6AA4D93B-4603-470F-9639-E7E589026952@twitter.com>

Vote: yes

> On May 27, 2020, at 5:24 AM, mark.reinhold at oracle.com wrote:
> 
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From kevin.rushforth at oracle.com  Wed May 27 20:13:52 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 27 May 2020 13:13:52 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <6998cc95-3fe1-5df6-2c11-0a861b42f702@oracle.com>

Vote: YES

-- Kevin

On 5/27/2020 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.


From mikael.vidstedt at oracle.com  Wed May 27 21:42:44 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 27 May 2020 14:42:44 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <EF33B264-FCAC-4E3A-829A-38C9F87FBBEF@oracle.com>


Vote: yes

Cheers,
Mikael

> On May 27, 2020, at 8:24 AM, mark.reinhold at oracle.com wrote:
> 
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From john.r.rose at oracle.com  Thu May 28 01:04:46 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 27 May 2020 18:04:46 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <F9EAF721-60BC-4D5D-9B34-DA3667892F9A@oracle.com>

Vote: yes


From david.holmes at oracle.com  Thu May 28 05:24:17 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 May 2020 15:24:17 +1000
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <073a618a-ccd3-f153-51ef-58ef528c1721@oracle.com>

Vote: yes

David

On 28/05/2020 1:24 am, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
> 

From stefan.karlsson at oracle.com  Thu May 28 06:34:55 2020
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 28 May 2020 08:34:55 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <0b27ae01-a762-b468-4de8-85752be7edca@oracle.com>

Vote: yes

StefanK

On 2020-05-27 17:24, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote


From laurent.daynes at oracle.com  Thu May 28 07:34:53 2020
From: laurent.daynes at oracle.com (Laurent Daynes)
Date: Thu, 28 May 2020 09:34:53 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <fb24e346-f1d4-0e99-4f63-606ee7465e2a@oracle.com>

Vote: yes

Le 27/05/2020 ? 17:24, mark.reinhold at oracle.com a ?crit?:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote

From per.liden at oracle.com  Thu May 28 08:31:34 2020
From: per.liden at oracle.com (Per Liden)
Date: Thu, 28 May 2020 10:31:34 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <315a039e-520a-f859-d0d4-1342130a5868@oracle.com>

Vote: yes

/Per

On 5/27/20 5:24 PM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
> 

From sadhak001 at gmail.com  Thu May 28 12:49:08 2020
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Thu, 28 May 2020 13:49:08 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <CAGHtMWkgON4QnAUQh24OXKQAP9_UUwpF3eu5jMCTYEzXhyowQw@mail.gmail.com>

Hi Mark,

This is a great step forward. I can only see upsides to this for Java the
Platform (JVM), the fruits of which current and future JVM languages and
GraalVM guest languages (written using the Truffle framework) will benefit
from.

Regards,
Mani

On Wed, 27 May 2020 at 16:26, <mark.reinhold at oracle.com> wrote:

> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
>
> For further details, please see the call for discussion [1].
>
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
>
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [3].
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
>


-- 
@theNeomatrix369 <https://twitter.com/theNeomatrix369>*  |  **Blogs
<https://medium.com/@neomatrix369>**  |  *@adoptopenjdk
<https://twitter.com/adoptopenjdk> @graalvm <https://twitter.com/graalvm>
@truffleruby <https://twitter.com/truffleruby> *|  **Github
<https://github.com/neomatrix369>* * | * *Slideshare
<https://slideshare.net/neomatrix369>* * | **LinkedIn
<https://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*

 *Sponsor *https://github.com/sponsors/neomatrix369


*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From sadhak001 at gmail.com  Thu May 28 12:51:27 2020
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Thu, 28 May 2020 13:51:27 +0100
Subject: CFV: New Project: Leyden
In-Reply-To: <CAGHtMWkgON4QnAUQh24OXKQAP9_UUwpF3eu5jMCTYEzXhyowQw@mail.gmail.com>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
 <CAGHtMWkgON4QnAUQh24OXKQAP9_UUwpF3eu5jMCTYEzXhyowQw@mail.gmail.com>
Message-ID: <CAGHtMWmEYq=zLs2Rm2E=L8nJXUu+recycYuJee8e5qmZqtORfQ@mail.gmail.com>

Vote: yes

On Wed, 27 May 2020 at 16:26, <mark.reinhold at oracle.com> wrote:
>
>> I hereby propose the creation a new Project, Leyden, with me as
>> the Lead and the Core Libraries and HotSpot Groups as sponsors.
>>
>> Leyden?s primary goal will be to address the long-term pain points
>> of Java?s slow startup time, slow time to peak performance, and large
>> footprint.  Leyden will address these pain points by introducing a
>> concept of static images to the Java Platform, and to the JDK.
>>
>> For further details, please see the call for discussion [1].
>>
>> I propose that the initial Reviewers of this Project include Alex
>> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
>> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
>> and Vladimir Kozlov.
>>
>> I expect ongoing contributions in the form of experience reports,
>> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
>> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
>>
>> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
>>
>> Only current OpenJDK Members [2] are eligible to vote on this motion.
>> Votes must be cast in the open on the discuss list.  Replying to this
>> message is sufficient if your mail program honors the Reply-To header.
>>
>> For Lazy Consensus voting instructions, see [3].
>>
>> - Mark
>>
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
>> [2] https://openjdk.java.net/census#members
>> [3] https://openjdk.java.net/projects/#new-project-vote
>>
>
>
> --
> @theNeomatrix369 <https://twitter.com/theNeomatrix369>*  |  **Blogs
> <https://medium.com/@neomatrix369>**  |  *@adoptopenjdk
> <https://twitter.com/adoptopenjdk> @graalvm <https://twitter.com/graalvm>
> @truffleruby <https://twitter.com/truffleruby> *|  **Github
> <https://github.com/neomatrix369>* * | * *Slideshare
> <https://slideshare.net/neomatrix369>* * | **LinkedIn
> <https://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>
>  *Sponsor *https://github.com/sponsors/neomatrix369
>
>
> *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>

From sgehwolf at redhat.com  Thu May 28 15:12:29 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 28 May 2020 17:12:29 +0200
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <b1689492902c5ec5788aa752036794d726007ee2.camel@redhat.com>

Vote: yes

On Wed, 2020-05-27 at 08:24 -0700, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
> 


From sean.mullan at oracle.com  Fri May 29 13:46:00 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 29 May 2020 09:46:00 -0400
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <c7a86a9f-8911-884c-5234-65cdb4cea33e@oracle.com>

Vote: yes

--Sean

From stuart.marks at oracle.com  Fri May 29 17:56:28 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 29 May 2020 10:56:28 -0700
Subject: CFV: New Project: Leyden
In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net>
References: <20200527152448.AC816357D04@eggemoggin.niobe.net>
Message-ID: <df44299f-eb56-c289-2e31-8c1b5b8d0a8c@oracle.com>

Vote: yes

On 5/27/20 8:24 AM, mark.reinhold at oracle.com wrote:
> I hereby propose the creation a new Project, Leyden, with me as
> the Lead and the Core Libraries and HotSpot Groups as sponsors.
> 
> Leyden?s primary goal will be to address the long-term pain points
> of Java?s slow startup time, slow time to peak performance, and large
> footprint.  Leyden will address these pain points by introducing a
> concept of static images to the Java Platform, and to the JDK.
> 
> For further details, please see the call for discussion [1].
> 
> I propose that the initial Reviewers of this Project include Alex
> Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad,
> Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf,
> and Vladimir Kozlov.
> 
> I expect ongoing contributions in the form of experience reports,
> advice, and feedback from Christian Wimmer, Thomas Wuerthinger,
> Vojin Jovanovic, and other members of Oracle?s GraalVM team.
> 
> Votes are due by 23:59 UTC on Wednesday, 10 June 2020.
> 
> Only current OpenJDK Members [2] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.  Replying to this
> message is sufficient if your mail program honors the Reply-To header.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> - Mark
> 
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
> [2] https://openjdk.java.net/census#members
> [3] https://openjdk.java.net/projects/#new-project-vote
>