From volker.simonis at gmail.com  Mon Aug  2 13:51:41 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 2 Aug 2021 15:51:41 +0200
Subject: CFV: New Project: CRaC
In-Reply-To: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
Message-ID: <CA+3eh10atPnfoQR=wZk5_Tn5LyMyxBpQCa-aDTLzEVQ6-khAKA@mail.gmail.com>

Vote: yes


Anton Kozlov <akozlov at azul.com> schrieb am Fr., 30. Juli 2021, 21:30:

> I hereby propose the creation of the CRaC Project with myself, Anton
> Kozlov,
> as the Lead and the HotSpot Group as the sponsoring Group.
>
> The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> coordination of Java programs with mechanisms to checkpoint (make an image
> of,
> snapshot) a Java instance while it is executing.  Restoring from the image
> could be a solution to some of the problems with the start-up and warm-up
> times.  The primary aim of the project is to develop a new standard
> mechanism-agnostic API to notify Java programs about the checkpoint and
> restore
> events.  Other research activities will include, but will not be limited
> to,
> integration with existing checkpoint/restore mechanisms and development of
> new
> ones, changes to JVM and JDK to make images smaller and ensure they are
> correct.
>
> The existing proof-of-concept implementation based on the OpenJDK [2] will
> be a
> starting point of the project.
>
> I work at Azul developing JVM and JDK, focusing on bug fixing, support of
> new
> platforms, and start-up/warm-up optimizations.  I'm a co-author of JEP-391
> and
> author of the CRaC proof-of-concept implementation.
>
> Initial Committers and Reviewers are:
> Volker Simonis (Committer)
> Anton Kozlov (Reviewer)
>
> Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
>
> Only current OpenJDK Members [3] 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 [4].
>
> Anton Kozlov
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> [2] https://github.com/CRaC/jdk
> [3] https://openjdk.java.net/census#members
> [4] https://openjdk.java.net/projects/#new-project-vote
>
>

From dcherepanov at azul.com  Thu Aug  5 08:14:53 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 5 Aug 2021 11:14:53 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
Message-ID: <b90c2946-d081-65db-f320-70c61ef9153d@azul.com>

Vote: yes

On 30.07.2021 22:17, Anton Kozlov wrote:
> I hereby propose the creation of the CRaC Project with myself, Anton Kozlov,
> as the Lead and the HotSpot Group as the sponsoring Group.
>
> The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> coordination of Java programs with mechanisms to checkpoint (make an image of,
> snapshot) a Java instance while it is executing.? Restoring from the image
> could be a solution to some of the problems with the start-up and warm-up
> times.? The primary aim of the project is to develop a new standard
> mechanism-agnostic API to notify Java programs about the checkpoint and restore
> events.? Other research activities will include, but will not be limited to,
> integration with existing checkpoint/restore mechanisms and development of new
> ones, changes to JVM and JDK to make images smaller and ensure they are
> correct.
>
> The existing proof-of-concept implementation based on the OpenJDK [2] will be a
> starting point of the project.
>
> I work at Azul developing JVM and JDK, focusing on bug fixing, support of new
> platforms, and start-up/warm-up optimizations.? I'm a co-author of JEP-391 and
> author of the CRaC proof-of-concept implementation.
>
> Initial Committers and Reviewers are:
> Volker Simonis (Committer)
> Anton Kozlov (Reviewer)
>
> Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
>
> Only current OpenJDK Members [3] 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 [4].
>
> Anton Kozlov
>
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> [2] https://github.com/CRaC/jdk
> [3] https://openjdk.java.net/census#members
> [4] https://openjdk.java.net/projects/#new-project-vote
>

From adinn at redhat.com  Thu Aug  5 09:27:20 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 5 Aug 2021 10:27:20 +0100
Subject: CFV: New Project: CRaC
In-Reply-To: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
Message-ID: <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>

Vote: abstain

I don't want to stop this project being created by posting a veto. I 
think it is only right and proper that members should be allowed to 
investigate any important area for innovation uinder the aegis of a 
dedicated project. However, I am unhappy with this vote being called 
without a more clear conclusion to the prior discussion.

Specifically, I believe the summary below fails to highlight the 
critical need for a significant amount of code in the JDK runtime and 
JVM to be involved in receiving and handling checkpoint and restore 
events and, in direct consequence, being party to the the process that 
saves or constructs a restartable runtime state (obvious areas include 
network and file system i/o management, memory management, security 
management, providers of randomness -- i.e. the same areas where GraalVM 
has found it needs to enforce runtime initialization or runtime repair 
of build-time inited state). My concern is that without a close 
involvement of many existing JDK and JVM engineers in the project and a 
strong commitment from them to supporting it the project is very likely 
to fail. I don't believe we have met either of those two requirements yet.

On 30/07/2021 20:17, Anton Kozlov wrote:
> I hereby propose the creation of the CRaC Project with myself, Anton 
> Kozlov,
> as the Lead and the HotSpot Group as the sponsoring Group.
> 
> The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> coordination of Java programs with mechanisms to checkpoint (make an 
> image of,
> snapshot) a Java instance while it is executing.? Restoring from the image
> could be a solution to some of the problems with the start-up and warm-up
> times.? The primary aim of the project is to develop a new standard
> mechanism-agnostic API to notify Java programs about the checkpoint and 
> restore
> events.? Other research activities will include, but will not be limited 
> to,
> integration with existing checkpoint/restore mechanisms and development 
> of new
> ones, changes to JVM and JDK to make images smaller and ensure they are
> correct.
> 
> The existing proof-of-concept implementation based on the OpenJDK [2] 
> will be a
> starting point of the project.
> 
> I work at Azul developing JVM and JDK, focusing on bug fixing, support 
> of new
> platforms, and start-up/warm-up optimizations.? I'm a co-author of 
> JEP-391 and
> author of the CRaC proof-of-concept implementation.
> 
> Initial Committers and Reviewers are:
> Volker Simonis (Committer)
> Anton Kozlov (Reviewer)
> 
> Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
> 
> Only current OpenJDK Members [3] 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 [4].
> 
> Anton Kozlov
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> [2] https://github.com/CRaC/jdk
> [3] https://openjdk.java.net/census#members
> [4] https://openjdk.java.net/projects/#new-project-vote
> 

-- 
regards,


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


From Alan.Bateman at oracle.com  Thu Aug  5 11:56:29 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Aug 2021 12:56:29 +0100
Subject: CFV: New Project: CRaC
In-Reply-To: <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
Message-ID: <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>

On 05/08/2021 10:27, Andrew Dinn wrote:
> Vote: abstain
>
> I don't want to stop this project being created by posting a veto. I 
> think it is only right and proper that members should be allowed to 
> investigate any important area for innovation uinder the aegis of a 
> dedicated project. However, I am unhappy with this vote being called 
> without a more clear conclusion to the prior discussion.
>
> Specifically, I believe the summary below fails to highlight the 
> critical need for a significant amount of code in the JDK runtime and 
> JVM to be involved in receiving and handling checkpoint and restore 
> events and, in direct consequence, being party to the the process that 
> saves or constructs a restartable runtime state (obvious areas include 
> network and file system i/o management, memory management, security 
> management, providers of randomness -- i.e. the same areas where 
> GraalVM has found it needs to enforce runtime initialization or 
> runtime repair of build-time inited state). My concern is that without 
> a close involvement of many existing JDK and JVM engineers in the 
> project and a strong commitment from them to supporting it the project 
> is very likely to fail. I don't believe we have met either of those 
> two requirements yet.

I didn't get time to reply to the initial discussion but I share the 
concern that the changes are potentially invasive and will require 
auditing and work in many areas. There was discussion about this at 
FOSDEM and at least one OCW where concerns about security and other 
areas came up. For example, I remember at FOSDEM (I think after 
Christine Flood presented on CRIU) there was discussion about session 
keys and needing to have those to be invalidated in the checkpoint on 
disk and a complete re-initialization at restore. There was also 
discussion about the implications of adjusting the clock and the impact 
of re-connecting or invalidating file descriptors. I don't doubt that 
all challenges are solvable with effort but it does require a lot of 
components and areas to cooperate. So I think your comment on trying to 
get a wider set of contributors (those working on core and security 
libraries for example) is important.

-Alan

From jesper.wilhelmsson at oracle.com  Thu Aug  5 12:18:35 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 5 Aug 2021 12:18:35 +0000
Subject: CFV: New Project: CRaC
In-Reply-To: <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
Message-ID: <DEAB268D-D30F-4D12-862C-EB6FD136499E@oracle.com>

> 5 aug. 2021 kl. 13:56 skrev Alan Bateman <Alan.Bateman at oracle.com>:
> On 05/08/2021 10:27, Andrew Dinn wrote:
>> Vote: abstain
>> 
>> I don't want to stop this project being created by posting a veto. I think it is only right and proper that members should be allowed to investigate any important area for innovation uinder the aegis of a dedicated project. However, I am unhappy with this vote being called without a more clear conclusion to the prior discussion.
>> 
>> Specifically, I believe the summary below fails to highlight the critical need for a significant amount of code in the JDK runtime and JVM to be involved in receiving and handling checkpoint and restore events and, in direct consequence, being party to the the process that saves or constructs a restartable runtime state (obvious areas include network and file system i/o management, memory management, security management, providers of randomness -- i.e. the same areas where GraalVM has found it needs to enforce runtime initialization or runtime repair of build-time inited state). My concern is that without a close involvement of many existing JDK and JVM engineers in the project and a strong commitment from them to supporting it the project is very likely to fail. I don't believe we have met either of those two requirements yet.
> 
> I didn't get time to reply to the initial discussion but I share the concern that the changes are potentially invasive and will require auditing and work in many areas. There was discussion about this at FOSDEM and at least one OCW where concerns about security and other areas came up. For example, I remember at FOSDEM (I think after Christine Flood presented on CRIU) there was discussion about session keys and needing to have those to be invalidated in the checkpoint on disk and a complete re-initialization at restore. There was also discussion about the implications of adjusting the clock and the impact of re-connecting or invalidating file descriptors. I don't doubt that all challenges are solvable with effort but it does require a lot of components and areas to cooperate. So I think your comment on trying to get a wider set of contributors (those working on core and security libraries for example) is important.

I agree that this project could have seen a longer time for discussion to collect more contributors - especially given the time of the year. We have an ongoing research project together with two local universities in Sweden in which we have been exploring this area. I would expect that some of the researchers involved would have been interested in joining the discussion and maybe even the project, but they have been on vacation in July and are just starting to get back to work next week and have therefore missed the entire discussion.

/Jesper


From volker.simonis at gmail.com  Thu Aug  5 15:21:13 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 5 Aug 2021 17:21:13 +0200
Subject: CFV: New Project: CRaC
In-Reply-To: <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
Message-ID: <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>

On Thu, Aug 5, 2021 at 1:58 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 05/08/2021 10:27, Andrew Dinn wrote:
> > Vote: abstain
> >
> > I don't want to stop this project being created by posting a veto. I
> > think it is only right and proper that members should be allowed to
> > investigate any important area for innovation uinder the aegis of a
> > dedicated project. However, I am unhappy with this vote being called
> > without a more clear conclusion to the prior discussion.
> >
> > Specifically, I believe the summary below fails to highlight the
> > critical need for a significant amount of code in the JDK runtime and
> > JVM to be involved in receiving and handling checkpoint and restore
> > events and, in direct consequence, being party to the the process that
> > saves or constructs a restartable runtime state (obvious areas include
> > network and file system i/o management, memory management, security
> > management, providers of randomness -- i.e. the same areas where
> > GraalVM has found it needs to enforce runtime initialization or
> > runtime repair of build-time inited state). My concern is that without
> > a close involvement of many existing JDK and JVM engineers in the
> > project and a strong commitment from them to supporting it the project
> > is very likely to fail. I don't believe we have met either of those
> > two requirements yet.
>
> I didn't get time to reply to the initial discussion but I share the
> concern that the changes are potentially invasive and will require
> auditing and work in many areas. There was discussion about this at
> FOSDEM and at least one OCW where concerns about security and other
> areas came up. For example, I remember at FOSDEM (I think after
> Christine Flood presented on CRIU) there was discussion about session
> keys and needing to have those to be invalidated in the checkpoint on
> disk and a complete re-initialization at restore. There was also
> discussion about the implications of adjusting the clock and the impact
> of re-connecting or invalidating file descriptors. I don't doubt that
> all challenges are solvable with effort but it does require a lot of
> components and areas to cooperate. So I think your comment on trying to
> get a wider set of contributors (those working on core and security
> libraries for example) is important.
>

I totally agree, but is aren't this good arguments for having a
project to investigate all these questions?

Establishing this project doesn't mean that we will deliver something
within the next month but rather that we'll have a common
infrastructure for experimenting and a central place for discussions.
Obviously, the larger the set of contributors will grow, the better
for the project. Needless to say that everybody is highly welcome to
share his experience and thoughts.

Best regards,
Volker

> -Alan

From volker.simonis at gmail.com  Thu Aug  5 15:28:32 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 5 Aug 2021 17:28:32 +0200
Subject: CFV: New Project: CRaC
In-Reply-To: <DEAB268D-D30F-4D12-862C-EB6FD136499E@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <DEAB268D-D30F-4D12-862C-EB6FD136499E@oracle.com>
Message-ID: <CA+3eh10oE2+h+Wj0nf-A72iPYaubOHbpPEXYam-9x70cfz6e9g@mail.gmail.com>

On Thu, Aug 5, 2021 at 2:19 PM Jesper Wilhelmsson
<jesper.wilhelmsson at oracle.com> wrote:
>
> > 5 aug. 2021 kl. 13:56 skrev Alan Bateman <Alan.Bateman at oracle.com>:
> > On 05/08/2021 10:27, Andrew Dinn wrote:
> >> Vote: abstain
> >>
> >> I don't want to stop this project being created by posting a veto. I think it is only right and proper that members should be allowed to investigate any important area for innovation uinder the aegis of a dedicated project. However, I am unhappy with this vote being called without a more clear conclusion to the prior discussion.
> >>
> >> Specifically, I believe the summary below fails to highlight the critical need for a significant amount of code in the JDK runtime and JVM to be involved in receiving and handling checkpoint and restore events and, in direct consequence, being party to the the process that saves or constructs a restartable runtime state (obvious areas include network and file system i/o management, memory management, security management, providers of randomness -- i.e. the same areas where GraalVM has found it needs to enforce runtime initialization or runtime repair of build-time inited state). My concern is that without a close involvement of many existing JDK and JVM engineers in the project and a strong commitment from them to supporting it the project is very likely to fail. I don't believe we have met either of those two requirements yet.
> >
> > I didn't get time to reply to the initial discussion but I share the concern that the changes are potentially invasive and will require auditing and work in many areas. There was discussion about this at FOSDEM and at least one OCW where concerns about security and other areas came up. For example, I remember at FOSDEM (I think after Christine Flood presented on CRIU) there was discussion about session keys and needing to have those to be invalidated in the checkpoint on disk and a complete re-initialization at restore. There was also discussion about the implications of adjusting the clock and the impact of re-connecting or invalidating file descriptors. I don't doubt that all challenges are solvable with effort but it does require a lot of components and areas to cooperate. So I think your comment on trying to get a wider set of contributors (those working on core and security libraries for example) is important.
>
> I agree that this project could have seen a longer time for discussion to collect more contributors - especially given the time of the year. We have an ongoing research project together with two local universities in Sweden in which we have been exploring this area. I would expect that some of the researchers involved would have been interested in joining the discussion and maybe even the project, but they have been on vacation in July and are just starting to get back to work next week and have therefore missed the entire discussion.

Well, from my point of view, the fact that apparently many other are
already working on similar topics only confirms the need for a project
to collect all the various ideas and efforts in a central place. No
irrevocable decisions have been taken until now and everybody is still
highly welcome to join the project.

Looking forward hearing more details from the mentioned research projects,
Volker

>
> /Jesper
>

From aph-open at littlepinkcloud.com  Thu Aug  5 15:42:43 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Thu, 5 Aug 2021 16:42:43 +0100
Subject: CFV: New Project: CRaC
In-Reply-To: <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
Message-ID: <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>

On 8/5/21 4:21 PM, Volker Simonis wrote:
> I totally agree, but is aren't this good arguments for having a
> project to investigate all these questions?
>
> Establishing this project doesn't mean that we will deliver something
> within the next month but rather that we'll have a common
> infrastructure for experimenting and a central place for discussions.

We-ell, yes. Sort of.

An API to notify Java programs about checkpoint and restore events
seems to me like a weird place to start such a project: it
concentrates on the "how" but not the "what" or the "why".

This project proposal starts with an existing proof-of-concept
implementation. Andrew Dinn's point, I believe, was that solving the
snapshot-and-restore problem in a way that is compatible with the Java
Specification requires thinking about a lot of other things as well.
In order for the API to be meaningful and portable we'd have to
specify a lot of things about what happens when. I don't think that
such an API could be a part of Java before these deep questions were
addressed, as they must be for Project Leyden.


-- 
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 volker.simonis at gmail.com  Thu Aug  5 15:59:46 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 5 Aug 2021 17:59:46 +0200
Subject: CFV: New Project: CRaC
In-Reply-To: <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
Message-ID: <CA+3eh13Bvr8FrwueNFuO04P0njdd-KsMwPM2a5Lp=kOVfKP2OA@mail.gmail.com>

On Thu, Aug 5, 2021 at 11:28 AM Andrew Dinn <adinn at redhat.com> wrote:
>
> Vote: abstain
>
> I don't want to stop this project being created by posting a veto. I
> think it is only right and proper that members should be allowed to
> investigate any important area for innovation uinder the aegis of a
> dedicated project. However, I am unhappy with this vote being called
> without a more clear conclusion to the prior discussion.
>
> Specifically, I believe the summary below fails to highlight the
> critical need for a significant amount of code in the JDK runtime and
> JVM to be involved in receiving and handling checkpoint and restore
> events and, in direct consequence, being party to the the process that
> saves or constructs a restartable runtime state (obvious areas include
> network and file system i/o management, memory management, security
> management, providers of randomness -- i.e. the same areas where GraalVM
> has found it needs to enforce runtime initialization or runtime repair
> of build-time inited state). My concern is that without a close
> involvement of many existing JDK and JVM engineers in the project and a
> strong commitment from them to supporting it the project is very likely
> to fail. I don't believe we have met either of those two requirements yet.
>

Creating an OpenJDK project by itself does by no means guarantee any
success as we can see from the large number of existing long running
or abandoned projects :) But that doesn't mean that we shouldn't be
allowed to try new ones.

While I can see some connections between the proposed project and
GraalVM/StaticJava/Leyden I still think the two topics are distinct
enough to justify a new project. From my understanding
Leyden/StaticJava has a much broader and more general scope in the
sense that it tries to define a new subset of the Java language and
API which is suitable for static compilation. However, at least from
my understanding, it doesn't cover the use case of snapshotting,
cloning and restoring. This project is more narrow in scope in that it
tries to define a simple interface which will allow applications to
react on snapshot/restore events, no matter if they are running in a
full blown JDK or in a static image. I think snapshot/restore
technologies on a level below the JDK/JVM (i.e. on  container/OS
level) are getting increasing traction and it would be nice if the
JVM/JDK as well as the applications could be made aware of these
technologies (in the same way the JDK has already been made, at least
a little bit, container/virtualization aware).

Best regards,
Volker

> On 30/07/2021 20:17, Anton Kozlov wrote:
> > I hereby propose the creation of the CRaC Project with myself, Anton
> > Kozlov,
> > as the Lead and the HotSpot Group as the sponsoring Group.
> >
> > The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> > coordination of Java programs with mechanisms to checkpoint (make an
> > image of,
> > snapshot) a Java instance while it is executing.  Restoring from the image
> > could be a solution to some of the problems with the start-up and warm-up
> > times.  The primary aim of the project is to develop a new standard
> > mechanism-agnostic API to notify Java programs about the checkpoint and
> > restore
> > events.  Other research activities will include, but will not be limited
> > to,
> > integration with existing checkpoint/restore mechanisms and development
> > of new
> > ones, changes to JVM and JDK to make images smaller and ensure they are
> > correct.
> >
> > The existing proof-of-concept implementation based on the OpenJDK [2]
> > will be a
> > starting point of the project.
> >
> > I work at Azul developing JVM and JDK, focusing on bug fixing, support
> > of new
> > platforms, and start-up/warm-up optimizations.  I'm a co-author of
> > JEP-391 and
> > author of the CRaC proof-of-concept implementation.
> >
> > Initial Committers and Reviewers are:
> > Volker Simonis (Committer)
> > Anton Kozlov (Reviewer)
> >
> > Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
> >
> > Only current OpenJDK Members [3] 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 [4].
> >
> > Anton Kozlov
> >
> > [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> > [2] https://github.com/CRaC/jdk
> > [3] https://openjdk.java.net/census#members
> > [4] https://openjdk.java.net/projects/#new-project-vote
> >
>
> --
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>

From volker.simonis at gmail.com  Thu Aug  5 16:08:28 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 5 Aug 2021 18:08:28 +0200
Subject: CFV: New Project: CRaC
In-Reply-To: <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
Message-ID: <CA+3eh10f+RDadgnzKAmABsx0Cz-BCyZgvdF2R4UN-2o8mVYjpA@mail.gmail.com>

On Thu, Aug 5, 2021 at 5:44 PM Andrew Haley
<aph-open at littlepinkcloud.com> wrote:
>
> On 8/5/21 4:21 PM, Volker Simonis wrote:
> > I totally agree, but is aren't this good arguments for having a
> > project to investigate all these questions?
> >
> > Establishing this project doesn't mean that we will deliver something
> > within the next month but rather that we'll have a common
> > infrastructure for experimenting and a central place for discussions.
>
> We-ell, yes. Sort of.
>
> An API to notify Java programs about checkpoint and restore events
> seems to me like a weird place to start such a project: it
> concentrates on the "how" but not the "what" or the "why".
>
> This project proposal starts with an existing proof-of-concept
> implementation. Andrew Dinn's point, I believe, was that solving the
> snapshot-and-restore problem in a way that is compatible with the Java
> Specification requires thinking about a lot of other things as well.
> In order for the API to be meaningful and portable we'd have to
> specify a lot of things about what happens when. I don't think that
> such an API could be a part of Java before these deep questions were
> addressed, as they must be for Project Leyden.
>

I think your point of view is a little too much JVM centric. As I
wrote in the other mail, snapshotting on OS and process level is
already happening and can work remarkably well even without the JVM
being aware of it. I don't think we necessarily need a new Java
specification to further improve that use case.

>
> --
> 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 chf at redhat.com  Thu Aug  5 16:36:17 2021
From: chf at redhat.com (Christine Flood)
Date: Thu, 5 Aug 2021 12:36:17 -0400
Subject: CFV: New Project: CRaC
In-Reply-To: <CA+3eh10f+RDadgnzKAmABsx0Cz-BCyZgvdF2R4UN-2o8mVYjpA@mail.gmail.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
 <CA+3eh10f+RDadgnzKAmABsx0Cz-BCyZgvdF2R4UN-2o8mVYjpA@mail.gmail.com>
Message-ID: <CALKUemzKNwxNeFsxtaSPW8kBSp7=hid34Yyq3oGo7aX2O1HGJQ@mail.gmail.com>

The proposed CRAC project is a much needed enhancement to the Java
ecosystem.

Seeing this work go upstream would be very valuable to the community.

However,  I'm uncomfortable with the vagueness of this proposed project.
 I'd be much happier with a more tightly constrained project proposal that
specifies goals, success metrics, and testing methodologies.



Christine

On Thu, Aug 5, 2021 at 12:09 PM Volker Simonis <volker.simonis at gmail.com>
wrote:

> On Thu, Aug 5, 2021 at 5:44 PM Andrew Haley
> <aph-open at littlepinkcloud.com> wrote:
> >
> > On 8/5/21 4:21 PM, Volker Simonis wrote:
> > > I totally agree, but is aren't this good arguments for having a
> > > project to investigate all these questions?
> > >
> > > Establishing this project doesn't mean that we will deliver something
> > > within the next month but rather that we'll have a common
> > > infrastructure for experimenting and a central place for discussions.
> >
> > We-ell, yes. Sort of.
> >
> > An API to notify Java programs about checkpoint and restore events
> > seems to me like a weird place to start such a project: it
> > concentrates on the "how" but not the "what" or the "why".
> >
> > This project proposal starts with an existing proof-of-concept
> > implementation. Andrew Dinn's point, I believe, was that solving the
> > snapshot-and-restore problem in a way that is compatible with the Java
> > Specification requires thinking about a lot of other things as well.
> > In order for the API to be meaningful and portable we'd have to
> > specify a lot of things about what happens when. I don't think that
> > such an API could be a part of Java before these deep questions were
> > addressed, as they must be for Project Leyden.
> >
>
> I think your point of view is a little too much JVM centric. As I
> wrote in the other mail, snapshotting on OS and process level is
> already happening and can work remarkably well even without the JVM
> being aware of it. I don't think we necessarily need a new Java
> specification to further improve that use case.
>
> >
> > --
> > 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 neugens.limasoftware at gmail.com  Thu Aug  5 18:33:19 2021
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 5 Aug 2021 20:33:19 +0200
Subject: CFV: New Project: CRaC
In-Reply-To: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
Message-ID: <A4CEA677-2A5D-4260-86C1-F84156BEEE84@gmail.com>

Vote: Abstain.

I do think any OpenJDK contributor should have the rights to request a space for experimentation, and I really like Anton?s work and the initiative, in principle, seems extremely interesting if executed properly.

However, like others I feel that there was not enough engagement and not enough discussion to put the basis for a project just yet. It has been mentioned that there are others exploring this problem space and this highlights the need to have a common infrastructure, however some of the comments coming from developers of said projects were largely ignored or dismissed even if they did offer some good points of discussion, so that doesn?t seem consequential.

Also, as was again mentioned already, some more people could contribute to the discussion, but the timing has bee so short, especially considering we're at the end of July/beginning of August, and many of us had noticed the project discussion only while on vacation (including me) without much chance to contribute.

I think this project has the opportunity to be extremely promising, but it needs to go beyond the small set of original committers and include more groups, and engage in a bit more discussion to better define its premises. In my opinion, but apparently also in the opinion of others here, the overlapping with other groups is significant, and it's a concern for me that this is not recognised, for this reason I suggest to take a little extra time to reflect back on the problems we're trying to solve before requesting a formal project, and maintain the goal to commit to have an inclusive and wider audience of JVM and core JDK developers, including the security group.

Also, I really, really encourage you to change the name :) but that?s probably just me being pedantic.

Cheers,
Mario


> On 30. Jul 2021, at 21:17, Anton Kozlov <akozlov at azul.com> wrote:
> 
> I hereby propose the creation of the CRaC Project with myself, Anton Kozlov,
> as the Lead and the HotSpot Group as the sponsoring Group.
> 
> The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> coordination of Java programs with mechanisms to checkpoint (make an image of,
> snapshot) a Java instance while it is executing.  Restoring from the image
> could be a solution to some of the problems with the start-up and warm-up
> times.  The primary aim of the project is to develop a new standard
> mechanism-agnostic API to notify Java programs about the checkpoint and restore
> events.  Other research activities will include, but will not be limited to,
> integration with existing checkpoint/restore mechanisms and development of new
> ones, changes to JVM and JDK to make images smaller and ensure they are
> correct.
> 
> The existing proof-of-concept implementation based on the OpenJDK [2] will be a
> starting point of the project.
> 
> I work at Azul developing JVM and JDK, focusing on bug fixing, support of new
> platforms, and start-up/warm-up optimizations.  I'm a co-author of JEP-391 and
> author of the CRaC proof-of-concept implementation.
> 
> Initial Committers and Reviewers are:
> Volker Simonis (Committer)
> Anton Kozlov (Reviewer)
> 
> Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
> 
> Only current OpenJDK Members [3] 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 [4].
> 
> Anton Kozlov
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> [2] https://github.com/CRaC/jdk
> [3] https://openjdk.java.net/census#members
> [4] https://openjdk.java.net/projects/#new-project-vote
> 

?
Mario Torre
Java Champion and OpenJDK contributor

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

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




From akozlov at azul.com  Thu Aug  5 19:31:55 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Thu, 5 Aug 2021 22:31:55 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
Message-ID: <73a03447-3881-2c56-84c9-4b8661e20bb4@azul.com>



On 8/5/21 2:56 PM, Alan Bateman wrote:
> On 05/08/2021 10:27, Andrew Dinn wrote:
>>
>> Specifically, I believe the summary below fails to highlight the critical need for a significant amount of code in the JDK runtime and JVM to be involved in receiving and handling checkpoint and restore events and, in direct consequence, being party to the the process that saves or constructs a restartable runtime state (obvious areas include network and file system i/o management, memory management, security management, providers of randomness -- i.e. the same areas where GraalVM has found it needs to enforce runtime initialization or runtime repair of build-time inited state). My concern is that without a close involvement of many existing JDK and JVM engineers in the project and a strong commitment from them to supporting it the project is very likely to fail. I don't believe we have met either of those two requirements yet.
> 
> I didn't get time to reply to the initial discussion but I share the concern that the changes are potentially invasive and will require auditing and work in many areas. There was discussion about this at FOSDEM and at least one OCW where concerns about security and other areas came up. For example, I remember at FOSDEM (I think after Christine Flood presented on CRIU) there was discussion about session keys and needing to have those to be invalidated in the checkpoint on disk and a complete re-initialization at restore. There was also discussion about the implications of adjusting the clock and the impact of re-connecting or invalidating file descriptors. I don't doubt that all challenges are solvable with effort but it does require a lot of components and areas to cooperate. So I think your comment on trying to get a wider set of contributors (those working on core and security libraries for example) is important.


The current proof-of-concept implementation has a rather low footprint.   Now
we do not require too much from the rest of the OpenJDK.  Although PoC may be
rewritten completely, it can serve for the estimation of the amount of code
needed.  Some parts of the state (networking and files) intentionally are not
saved by the implementation and for now, it is going to be this way: it's the
external state that may change -- applications are forced to handle it by
themselves.  For a Random instance, it is required to know its semantic, so we
also cannot handle them completely automatically.

For the security keys use case, it is important to understand who "owns" keys.
If it is the JDK standard library, then proper handling should be implemented
there.

 From my experience, fixing a stale application state is rather easy and needs
only a bare refactoring (a reinitializing function based on the existing
initializing function).  So I understand the main concern about auditing
OpenJDK code is that some parts could be just overlooked.  I think proper
testing should help here (while the code is still in the Project).

Unlikely the project is going to be integrated once and completely.  So the
plan was to provide the best implementation for various areas in OpenJDK by the
efforts of people enthusiastic about the Project.  On important milestones, the
project will seek for review of the corresponding parts of the implementation
from experts.  Without a base implementation, it will be hard to discuss the
details.

Thanks,
Anton

From akozlov at azul.com  Thu Aug  5 19:40:18 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Thu, 5 Aug 2021 22:40:18 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <CA+3eh10oE2+h+Wj0nf-A72iPYaubOHbpPEXYam-9x70cfz6e9g@mail.gmail.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <DEAB268D-D30F-4D12-862C-EB6FD136499E@oracle.com>
 <CA+3eh10oE2+h+Wj0nf-A72iPYaubOHbpPEXYam-9x70cfz6e9g@mail.gmail.com>
Message-ID: <1953cc04-404c-c20f-ec1c-143b5fcfa932@azul.com>



On 8/5/21 6:28 PM, Volker Simonis wrote:
> On Thu, Aug 5, 2021 at 2:19 PM Jesper Wilhelmsson
>> I agree that this project could have seen a longer time for discussion to collect more contributors - especially given the time of the year. We have an ongoing research project together with two local universities in Sweden in which we have been exploring this area. I would expect that some of the researchers involved would have been interested in joining the discussion and maybe even the project, but they have been on vacation in July and are just starting to get back to work next week and have therefore missed the entire discussion.
> 
> No
> irrevocable decisions have been taken until now and everybody is still
> highly welcome to join the project.

Right, the set of contributors is not limited to the initial set. It will be
possible to add more contributors, and we'll welcome them!

Sorry, I realized too late it's the vacation season.

Thanks,
Anton

From akozlov at azul.com  Thu Aug  5 20:06:57 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Thu, 5 Aug 2021 23:06:57 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
Message-ID: <39388697-1f29-4d1f-c508-0590194591f1@azul.com>



On 8/5/21 6:42 PM, Andrew Haley wrote:
> An API to notify Java programs about checkpoint and restore events
> seems to me like a weird place to start such a project: it
> concentrates on the "how" but not the "what" or the "why".

Why and what are still to reduce start-up/warm-up and save the state, to avoid
doing same computations again and again on both Java lang level and JVM level
doing JIT compilations.

> This project proposal starts with an existing proof-of-concept
> implementation. Andrew Dinn's point, I believe, was that solving the
> snapshot-and-restore problem in a way that is compatible with the Java
> Specification requires thinking about a lot of other things as well.
> In order for the API to be meaningful and portable we'd have to
> specify a lot of things about what happens when. I don't think that
> such an API could be a part of Java before these deep questions were
> addressed, as they must be for Project Leyden.
> 

The checkpoint/restore concept does not require that big changes to the Java
lang.  Two (or more) phases of the Java application life-cycle are implicit.
The execution of a Java program is the same, but it may just pause for a while.
It's much different from compile-time/run-time separation for static images.

Thanks,
Anton

From akozlov at azul.com  Thu Aug  5 20:56:20 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Thu, 5 Aug 2021 23:56:20 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <CALKUemzKNwxNeFsxtaSPW8kBSp7=hid34Yyq3oGo7aX2O1HGJQ@mail.gmail.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
 <CA+3eh10f+RDadgnzKAmABsx0Cz-BCyZgvdF2R4UN-2o8mVYjpA@mail.gmail.com>
 <CALKUemzKNwxNeFsxtaSPW8kBSp7=hid34Yyq3oGo7aX2O1HGJQ@mail.gmail.com>
Message-ID: <01c85331-37ca-f4c2-c662-63fa9ffc6e88@azul.com>



On 8/5/21 7:36 PM, Christine Flood wrote:
> I'd be much happier with a more tightly constrained project proposal that
> specifies goals, success metrics, and testing methodologies.
The proposal is about a research project, so it would constrain the project as
well.  The high-level goals are best described by developing the set of
discussed deliverables and researching new use-cases like the one with
Firecracker.  Likely, they will change over time.  Therefore, it will be too
early to specify success metrics.  For example, we'd want to reach start-up and
warm-up time similar to what the prototype implementation provides.

Thanks,
Anton

From philip.race at oracle.com  Thu Aug  5 21:39:16 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 5 Aug 2021 14:39:16 -0700
Subject: CFV: New Project: CRaC
In-Reply-To: <01c85331-37ca-f4c2-c662-63fa9ffc6e88@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
 <CA+3eh10f+RDadgnzKAmABsx0Cz-BCyZgvdF2R4UN-2o8mVYjpA@mail.gmail.com>
 <CALKUemzKNwxNeFsxtaSPW8kBSp7=hid34Yyq3oGo7aX2O1HGJQ@mail.gmail.com>
 <01c85331-37ca-f4c2-c662-63fa9ffc6e88@azul.com>
Message-ID: <678f952a-0e81-e9aa-570c-151e3b238975@oracle.com>

I'm very curious to know if the project intends to even investigate this 
for desktop applications.
The proposal? and prior discussion seem to be completely silent on this.
Restoring the state of a running desktop application opens new 
complications.

-phil.

On 8/5/21 1:56 PM, Anton Kozlov wrote:
>
>
> On 8/5/21 7:36 PM, Christine Flood wrote:
>> I'd be much happier with a more tightly constrained project proposal 
>> that
>> specifies goals, success metrics, and testing methodologies.
> The proposal is about a research project, so it would constrain the 
> project as
> well.? The high-level goals are best described by developing the set of
> discussed deliverables and researching new use-cases like the one with
> Firecracker.? Likely, they will change over time.? Therefore, it will 
> be too
> early to specify success metrics.? For example, we'd want to reach 
> start-up and
> warm-up time similar to what the prototype implementation provides.
>
> Thanks,
> Anton


From akozlov at azul.com  Fri Aug  6 08:04:20 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 6 Aug 2021 11:04:20 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <A4CEA677-2A5D-4260-86C1-F84156BEEE84@gmail.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <A4CEA677-2A5D-4260-86C1-F84156BEEE84@gmail.com>
Message-ID: <b0f4b12a-adbf-dec3-6b8b-8b98f05df816@azul.com>



On 8/5/21 9:33 PM, Mario Torre wrote:
> However, like others I feel that there was not enough engagement and not enough discussion to put the basis for a project just yet. It has been mentioned that there are others exploring this problem space and this highlights the need to have a common infrastructure, however some of the comments coming from developers of said projects were largely ignored or dismissed even if they did offer some good points of discussion, so that doesn?t seem consequential.

If that happened, it was not intentional. I'm asking a pardon in advance. If
you'd point to the comments I overlooked, that would be very helpful.

The Project is the first step to the common infrastructure, where at least we
start moving technical discussions and combining all different efforts.

> Also, as was again mentioned already, some more people could contribute to the discussion, but the timing has bee so short, especially considering we're at the end of July/beginning of August, and many of us had noticed the project discussion only while on vacation (including me) without much chance to contribute.

I'm sorry for this. There was enough traffic on the discuss maillist for me to
assume the timing was OK. But it is always possible to add more
committers/reviewers to the project. The proposed Project is a long-running
activity, so I hope the discussions will always keep going. As a result, the
specific goals, artifacts, contributors are going to change over time.

> I think this project has the opportunity to be extremely promising, but it needs to go beyond the small set of original committers and include more groups, and engage in a bit more discussion to better define its premises. In my opinion, but apparently also in the opinion of others here, the overlapping with other groups is significant, and it's a concern for me that this is not recognised, for this reason I suggest to take a little extra time to reflect back on the problems we're trying to solve before requesting a formal project, and maintain the goal to commit to have an inclusive and wider audience of JVM and core JDK developers, including the security group.

I acknowledge that the integration of some deliverables of the Project needs
close cooperation with the OpenJDK community.   But it will be crucial in the
later stages of the Project when pieces will become ready for integration (so
far they are not). At the current very early stage it is important to establish
a common place and bring all discussion there. It seems we don't completely
understand all requirements from different parties, so there is no point to ask
for a review of details, before they may change. And as usual, there is a
trade-off possible when some concerns can be outweighed by the usefulness of
the result. The edge between completely useless but flawless implementation and
a very useful one but with known limitations is moveable. The effects of some
decisions are best observed in practice and prototypes.

The Project can assure the contributions are done properly. So far, I'm not
sure enough people have looked at the prototype, as it is hosted in a
third-party repo, not covered by OCA for example, so I can imagine possible
concerns from the legal point of view. The Project will serve as a place where
collaboration can happen.

So I don't see how more discussion before creating the Project will help to get
the idea moving, but I see a benefit of having the Project.

> Also, I really, really encourage you to change the name :) but that?s probably just me being pedantic.

The abbreviation is short, pronounceable, and accidentally reflects what
happens with the execution (there are "cracks" in the timeline of the Java
lifecycle). The Project name has leaked into API, but this may be changed
later.

Thanks,
Anton

From akozlov at azul.com  Fri Aug  6 08:42:11 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 6 Aug 2021 11:42:11 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <678f952a-0e81-e9aa-570c-151e3b238975@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
 <CA+3eh10f+RDadgnzKAmABsx0Cz-BCyZgvdF2R4UN-2o8mVYjpA@mail.gmail.com>
 <CALKUemzKNwxNeFsxtaSPW8kBSp7=hid34Yyq3oGo7aX2O1HGJQ@mail.gmail.com>
 <01c85331-37ca-f4c2-c662-63fa9ffc6e88@azul.com>
 <678f952a-0e81-e9aa-570c-151e3b238975@oracle.com>
Message-ID: <6691a223-ed9c-48eb-1818-e4a35cacec5b@azul.com>



On 8/6/21 12:39 AM, Philip Race wrote:
> I'm very curious to know if the project intends to even investigate this for desktop applications.
> The proposal? and prior discussion seem to be completely silent on this.
> Restoring the state of a running desktop application opens new complications.

Desktop apps are unlikely to be supported soon. The primary use-case of the
prototype implementation is microservices and networking applications instances
that are scaled a lot. I played a bit with a saving simple graphical java app
on X11 on top of the CRaC prototype. For now, I don't plan to invest more time
in this topic, but I will be happy if someone will continue the investigation.

Few observations from the saving GUI app. The checkpoint is aborted as it
should because of connections with the external world. So the principle that
the image should be safe once created is satisfied. After some time changing
the code, it became clear that the amount of changes is going to be rather big
because of X11 protocol turned out to be very stateful and I needed to
reinitialize a lot of things.

I did not investigate more clever approaches like loading X11-related parts in
a separate class loader and unload/load them again. This probably could reduce
the amount of the required changes.

Thanks,
Anton

From adinn at redhat.com  Fri Aug  6 09:49:51 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 6 Aug 2021 10:49:51 +0100
Subject: CFV: New Project: CRaC
In-Reply-To: <39388697-1f29-4d1f-c508-0590194591f1@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
 <39388697-1f29-4d1f-c508-0590194591f1@azul.com>
Message-ID: <98187a85-c854-196d-17a8-9860db05e893@redhat.com>

On 05/08/2021 21:06, Anton Kozlov wrote:
> The checkpoint/restore concept does not require that big changes to
> the Java lang.  Two (or more) phases of the Java application
> life-cycle are implicit. The execution of a Java program is the same,
> but it may just pause for a while. It's much different from
> compile-time/run-time separation for static images.

My father had a good friend who frequently relied on the gambit "It's a 
well-known fact that ..." to sway an argument. Well, I am afraid that 
the above assertion about the limited room for things to go wrong thanks 
to a 'simple' save and restore does not self-evidently qualify as 
commonly agreed fact. It might well be true for /some/ apps, especially 
if they are saved and then restored on exactly the same host from the 
same parent process with little or no intervening change to the 
underlying operating and process system environment (and ignoring any 
effect the pause might have on timings). However, even in those limited, 
albeit rather vaguely defined, circumstances I don't think we can 
presume it will be true for all apps.

It's worse than that though. For the primary use case I think you are 
talking about -- running services in a container on cloud infrastructure 
-- I think it is quite possible that a deployment may fail even to meet 
those rather vaguely set out requirements.   Might a saved app state not 
be resumed many times, possibly concurrently? Might local OS resources 
conceivably change between restarts? Might the parent process env 
conceivably change between restarts? Indeed, might those effects not 
actually occur because of the very fact that the app is being restarted?

Unfortunately, the current operation of the JVM and JDK implicitly 
presumes a high degree of continuity in the process and OS env during 
execution. It has most definitely not been made 100% resilient to any 
sudden discontinuity from one point of execution to the next thanks to 
whatever change might happen in some intervening hiatus caused by a save 
and subsequent restore.

We could ignore that problem on the grounds that it is not a goal of the 
project to consider it and claim, in consequence, that anyone running 
into problems because of it has to look out for themselves. However, in 
doing so I believe we would run the risk of significantly lowering the 
value of whatever the project might come up with.

The alternative is to plan for and spend effort looking through the JDK 
runtime and JVM code to identify where it needs to be made resilient to 
save and restore and provide means for any potential disruption that it 
might cause to be detected and either repaired or, at least, managed 
with a graceful failure. I believe very firmly that this latter course 
is the one we should follow.

regards,


Andrew Dinn
-----------


From Alan.Bateman at oracle.com  Fri Aug  6 11:05:31 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Aug 2021 12:05:31 +0100
Subject: CFV: New Project: CRaC
In-Reply-To: <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
Message-ID: <0ca718f5-ebf9-90d1-7da2-993aede339ef@oracle.com>

On 05/08/2021 16:21, Volker Simonis wrote:
> :
> I totally agree, but is aren't this good arguments for having a
> project to investigate all these questions?
>
> Establishing this project doesn't mean that we will deliver something
> within the next month but rather that we'll have a common
> infrastructure for experimenting and a central place for discussions.
> Obviously, the larger the set of contributors will grow, the better
> for the project. Needless to say that everybody is highly welcome to
> share his experience and thoughts.
>
It would be good to try to expand the set of contributors as this 
project as it is likely that it will require prototyping invasive 
changes to many areas of the libraries.? It may be that the 
worse-is-better direction in Anton's mails is where it ends up but I do 
expect that it will have to deal with several issues around security and 
at least some API/spec changes to allow for behavior after restore/continue.

-Alan

From jesper.wilhelmsson at oracle.com  Fri Aug  6 11:53:23 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 11:53:23 +0000
Subject: CFV: New Project: CRaC
In-Reply-To: <b0f4b12a-adbf-dec3-6b8b-8b98f05df816@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <A4CEA677-2A5D-4260-86C1-F84156BEEE84@gmail.com>
 <b0f4b12a-adbf-dec3-6b8b-8b98f05df816@azul.com>
Message-ID: <F8072EA2-EE4A-47D1-A2A1-9E045A71FD85@oracle.com>

Obviously the discussion will continue after the project has been created and go on as long as the project is active, but the initial discussion that happens before the project is created has a different purpose than the discussion that follows the creation. It's a matter of determining what the actual goal is, and it's also a matter of making sure everyone who is expected to participate in the project later feels welcome and included already from start. Adding Committers later is obviously possible but there's a process around it that requires the potential Committer to prove her/himself worthy before being accepted into the group. This can be a quite large mental blocker for some people. Being included from the start will encourage people to be more active and devoted to the project.

Looking at the current project description and the initial set of Committers/Reviewers I can't help but wondering what the purpose of this project is. Is the goal to investigate a generic problem area, or is the goal to get your prototype productized and pushed? Both are perfectly valid goals of a project, but the project description should clearly state what the goal is. The interest from others to join and contribute to the project depends very much on which one of these two goals is the actual goal. How many different approaches are you prepared to investigate within this project? Are you prepared to throw your prototype away if some other team enters the project with a better suited solution? There are already several prototypes in this area trying different approaches but the project description clearly states that this project is about your prototype.

So far I haven't sen enough evidence that this project is about the generic research of a problem space. If I am to ask my friends at the university to look at this, I first want to make sure it's a research project, not just a finish someone else's implementation project.

/Jesper

> 6 aug. 2021 kl. 10:04 skrev Anton Kozlov <akozlov at azul.com>:
> 
> On 8/5/21 9:33 PM, Mario Torre wrote:
>> However, like others I feel that there was not enough engagement and not enough discussion to put the basis for a project just yet. It has been mentioned that there are others exploring this problem space and this highlights the need to have a common infrastructure, however some of the comments coming from developers of said projects were largely ignored or dismissed even if they did offer some good points of discussion, so that doesn?t seem consequential.
> 
> If that happened, it was not intentional. I'm asking a pardon in advance. If
> you'd point to the comments I overlooked, that would be very helpful.
> 
> The Project is the first step to the common infrastructure, where at least we
> start moving technical discussions and combining all different efforts.
> 
>> Also, as was again mentioned already, some more people could contribute to the discussion, but the timing has bee so short, especially considering we're at the end of July/beginning of August, and many of us had noticed the project discussion only while on vacation (including me) without much chance to contribute.
> 
> I'm sorry for this. There was enough traffic on the discuss maillist for me to
> assume the timing was OK. But it is always possible to add more
> committers/reviewers to the project. The proposed Project is a long-running
> activity, so I hope the discussions will always keep going. As a result, the
> specific goals, artifacts, contributors are going to change over time.
> 
>> I think this project has the opportunity to be extremely promising, but it needs to go beyond the small set of original committers and include more groups, and engage in a bit more discussion to better define its premises. In my opinion, but apparently also in the opinion of others here, the overlapping with other groups is significant, and it's a concern for me that this is not recognised, for this reason I suggest to take a little extra time to reflect back on the problems we're trying to solve before requesting a formal project, and maintain the goal to commit to have an inclusive and wider audience of JVM and core JDK developers, including the security group.
> 
> I acknowledge that the integration of some deliverables of the Project needs
> close cooperation with the OpenJDK community.   But it will be crucial in the
> later stages of the Project when pieces will become ready for integration (so
> far they are not). At the current very early stage it is important to establish
> a common place and bring all discussion there. It seems we don't completely
> understand all requirements from different parties, so there is no point to ask
> for a review of details, before they may change. And as usual, there is a
> trade-off possible when some concerns can be outweighed by the usefulness of
> the result. The edge between completely useless but flawless implementation and
> a very useful one but with known limitations is moveable. The effects of some
> decisions are best observed in practice and prototypes.
> 
> The Project can assure the contributions are done properly. So far, I'm not
> sure enough people have looked at the prototype, as it is hosted in a
> third-party repo, not covered by OCA for example, so I can imagine possible
> concerns from the legal point of view. The Project will serve as a place where
> collaboration can happen.
> 
> So I don't see how more discussion before creating the Project will help to get
> the idea moving, but I see a benefit of having the Project.
> 
>> Also, I really, really encourage you to change the name :) but that?s probably just me being pedantic.
> 
> The abbreviation is short, pronounceable, and accidentally reflects what
> happens with the execution (there are "cracks" in the timeline of the Java
> lifecycle). The Project name has leaked into API, but this may be changed
> later.
> 
> Thanks,
> Anton


From akozlov at azul.com  Fri Aug  6 15:37:37 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 6 Aug 2021 18:37:37 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <98187a85-c854-196d-17a8-9860db05e893@redhat.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <18f1a1d1-ad67-20ee-11c2-7b07ecef5a21@littlepinkcloud.com>
 <39388697-1f29-4d1f-c508-0590194591f1@azul.com>
 <98187a85-c854-196d-17a8-9860db05e893@redhat.com>
Message-ID: <19276db7-ca6b-8952-dd59-3c9dbac47532@azul.com>


On 8/6/21 12:49 PM, Andrew Dinn wrote:
> Well, I am afraid that the above assertion about the limited room for things to go wrong thanks to a 'simple' save and restore does not self-evidently qualify as commonly agreed fact. It might well be true for /some/ apps, especially if they are saved and then restored on exactly the same host from the same parent process with little or no intervening change to the underlying operating and process system environment (and ignoring any effect the pause might have on timings). However, even in those limited, albeit rather vaguely defined, circumstances I don't think we can presume it will be true for all apps.

My point was about Java Lang (JLS), I'm not aware of something that needs to be
fixed there.

It should be easy to construct an app that will be incompatible with CRaC.  But
handling such apps automatically by the platform is not something we are
looking for.  Instead, we propose a new mechanism for apps to coordinate,
something that was not possible before.  To coordinate or not is a choice of
the app programmer, so even if the mechanism presents in JDK, additional work
needs to be done by the programmer on the level of the application semantic.

> It's worse than that though. For the primary use case I think you are talking about -- running services in a container on cloud infrastructure -- I think it is quite possible that a deployment may fail even to meet those rather vaguely set out requirements.  (1) Might a saved app state not be resumed many times, possibly concurrently? (2) Might local OS resources conceivably change between restarts? (3) Might the parent process env conceivably change between restarts? (4) Indeed, might those effects not actually occur because of the very fact that the app is being restarted?

If points 1-4 relate to an application depending on them to work correctly, we
propose for the application to resolve these problems.  It is possible to
construct an application that is impossible to start multiple times
concurrently without CRaC involved.  For example, because of a fixed temp file
that would be used by all instances concurrently and therefore trashed.
Applications are coded in a special way to support multiple concurrent
instances.  So the same should be the case for apps that are saved and
restored.  Same reasoning could be applied to every point.

Points 2, 3, and partly 1 relate to JDK and JVM implementation, which are
discussed below.

> Unfortunately, the current operation of the JVM and JDK implicitly presumes a high degree of continuity in the process and OS env during execution. It has most definitely not been made 100% resilient to any sudden discontinuity from one point of execution to the next thanks to whatever change might happen in some intervening hiatus caused by a save and subsequent restore.

I completely agree with this fact.  But it is about their implementation,
something that may be adapted to new requirements.  For example, dropping
cached values on this checkpoint (and this will be possible with CRaC).

There is a trade-off between how useful the image is and how general it is.  On
one side there is a very similar execution environment after restore and the
state that can be slightly fixed.  On the other, completely another environment
(different OS and CPU), and much more abstracted state that won't have
JIT-compiled code and thus less useful.  I see the benefit of the former and
in-between values (same CPU with different flags).  Then, it will be useful to
have a set of flags to control how general the image is.  But, it will be a
deployment task and won't require changes from the conservatively written
applications.  It's similar to C compiler flags that control the target
microarch.  We cannot expect all values are good for all targets.

The current plan is to start with the most useful and optimized approach and
move to the more general, using common sense for what should be done and what
is required.  Such decisions are always can be re-thought and more steps could
be taken in the abstracting direction.

> We could ignore that problem on the grounds that it is not a goal of the project to consider it and claim, in consequence, that anyone running into problems because of it has to look out for themselves. However, in doing so I believe we would run the risk of significantly lowering the value of whatever the project might come up with.
>
> The alternative is to plan for and spend effort looking through the JDK runtime and JVM code to identify where it needs to be made resilient to save and restore and provide means for any potential disruption that it might cause to be detected and either repaired or, at least, managed with a graceful failure. I believe very firmly that this latter course is the one we should follow.

This sounds very reasonable to me.  It is aligned with existing checks for open
files and network connections.  Why this cannot and should not be done in
parallel?  Something runnable and testable, although unperfect, will greatly
help in finding the problems.

The API will be the way to repair the state or to gracefully fail (as it
supports now, by allowing to throw an exception)

Thanks,
Anton

From akozlov at azul.com  Fri Aug  6 19:36:00 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 6 Aug 2021 22:36:00 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <F8072EA2-EE4A-47D1-A2A1-9E045A71FD85@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <A4CEA677-2A5D-4260-86C1-F84156BEEE84@gmail.com>
 <b0f4b12a-adbf-dec3-6b8b-8b98f05df816@azul.com>
 <F8072EA2-EE4A-47D1-A2A1-9E045A71FD85@oracle.com>
Message-ID: <d5e1db82-e99c-b0c3-f393-59f55981d01a@azul.com>



On 8/6/21 2:53 PM, Jesper Wilhelmsson wrote:
> Obviously the discussion will continue after the project has been created and go on as long as the project is active, but the initial discussion that happens before the project is created has a different purpose than the discussion that follows the creation. It's a matter of determining what the actual goal is, and it's also a matter of making sure everyone who is expected to participate in the project later feels welcome and included already from start. Adding Committers later is obviously possible but there's a process around it that requires the potential Committer to prove her/himself worthy before being accepted into the group. This can be a quite large mental blocker for some people. Being included from the start will encourage people to be more active and devoted to the project.

The committer nomination process provides only a rough guide for the
prerequisites.  I think it won't be any problem for an experienced OpenJDK
developer to become a committer.

Other prototype implementations can be counted as sufficient significant
contributions.

There is no aim to introduce barriers for contributors.  If someone wants to be
included in committers, I ask to send a message.  So far, the initial set
includes everyone who explicitly expressed the desire.  Contributors are
welcome.

> Looking at the current project description and the initial set of Committers/Reviewers I can't help but wondering what the purpose of this project is. Is the goal to investigate a generic problem area, or is the goal to get your prototype productized and pushed? Both are perfectly valid goals of a project, but the project description should clearly state what the goal is. The interest from others to join and contribute to the project depends very much on which one of these two goals is the actual goal. How many different approaches are you prepared to investigate within this project? Are you prepared to throw your prototype away if some other team enters the project with a better suited solution? There are already several prototypes in this area trying different approaches but the project description clearly states that this project is about your prototype.
> 
> So far I haven't sen enough evidence that this project is about the generic research of a problem space. If I am to ask my friends at the university to look at this, I first want to make sure it's a research project, not just a finish someone else's implementation project.

The purpose of the project is to research the area.  The CRaC prototype is
rather small, so enhancing may mean rewriting it.  All approaches should be
considered.  I think the first step is so obvious that all prototypes are
similar and differ by names and code organization only :) If there is a better
prototype that covers what is done in CRaC and the another prototype does not
have drawbacks, then it's should be logical to take the better one.  But if two
prototypes have different properties, there should be a way to combine their
strong sides.

The CRaC prototype is only the starting point.  It will be great to have
different ones e.g. in separate branches right at the start.  Are there links
to the other prototypes?

Thanks,
Anton

From yan at azul.com  Sun Aug  8 17:01:44 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Sun, 8 Aug 2021 20:01:44 +0300
Subject: CFV: New Project: CRaC
Message-ID: <191218cd-125e-3f92-2b00-82b043bb9376@azul.com>

Vote: yes

On 30.07.2021 22:17, Anton Kozlov wrote:
 > I hereby propose the creation of the CRaC Project with myself, Anton 
Kozlov,
 > as the Lead and the HotSpot Group as the sponsoring Group.
 >
 > The CRaC (Coordinated Restore at Checkpoint) [1] project will research
 > coordination of Java programs with mechanisms to checkpoint (make an 
image of,
 > snapshot) a Java instance while it is executing.  Restoring from the 
image
 > could be a solution to some of the problems with the start-up and warm-up
 > times.  The primary aim of the project is to develop a new standard
 > mechanism-agnostic API to notify Java programs about the checkpoint 
and restore
 > events.  Other research activities will include, but will not be 
limited to,
 > integration with existing checkpoint/restore mechanisms and 
development of new
 > ones, changes to JVM and JDK to make images smaller and ensure they are
 > correct.
 >
 > The existing proof-of-concept implementation based on the OpenJDK [2] 
will be a
 > starting point of the project.
 >
 > I work at Azul developing JVM and JDK, focusing on bug fixing, 
support of new
 > platforms, and start-up/warm-up optimizations.  I'm a co-author of 
JEP-391 and
 > author of the CRaC proof-of-concept implementation.
 >
 > Initial Committers and Reviewers are:
 > Volker Simonis (Committer)
 > Anton Kozlov (Reviewer)
 >
 > Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
 >
 > Only current OpenJDK Members [3] 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 [4].
 >
 > Anton Kozlov
 >
 > [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
 > [2] https://github.com/CRaC/jdk
 > [3] https://openjdk.java.net/census#members
 > [4] https://openjdk.java.net/projects/#new-project-vote
 >


From abrygin at azul.com  Sun Aug  8 18:18:27 2021
From: abrygin at azul.com (Andrew Brygin)
Date: Sun, 8 Aug 2021 21:18:27 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
Message-ID: <b16f20b8-43a4-c32b-93ff-fb85d332fa48@azul.com>

Vote: yes

On 30/07/2021 22:17, Anton Kozlov wrote:
> I hereby propose the creation of the CRaC Project with myself, Anton
> Kozlov,
> as the Lead and the HotSpot Group as the sponsoring Group.
> 
> The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> coordination of Java programs with mechanisms to checkpoint (make an
> image of,
> snapshot) a Java instance while it is executing.? Restoring from the image
> could be a solution to some of the problems with the start-up and warm-up
> times.? The primary aim of the project is to develop a new standard
> mechanism-agnostic API to notify Java programs about the checkpoint and
> restore
> events.? Other research activities will include, but will not be limited
> to,
> integration with existing checkpoint/restore mechanisms and development
> of new
> ones, changes to JVM and JDK to make images smaller and ensure they are
> correct.
> 
> The existing proof-of-concept implementation based on the OpenJDK [2]
> will be a
> starting point of the project.
> 
> I work at Azul developing JVM and JDK, focusing on bug fixing, support
> of new
> platforms, and start-up/warm-up optimizations.? I'm a co-author of
> JEP-391 and
> author of the CRaC proof-of-concept implementation.
> 
> Initial Committers and Reviewers are:
> Volker Simonis (Committer)
> Anton Kozlov (Reviewer)
> 
> Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
> 
> Only current OpenJDK Members [3] 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 [4].
> 
> Anton Kozlov
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> [2] https://github.com/CRaC/jdk
> [3] https://openjdk.java.net/census#members
> [4] https://openjdk.java.net/projects/#new-project-vote
> 

From joe.darcy at oracle.com  Mon Aug  9 20:02:09 2021
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 9 Aug 2021 13:02:09 -0700
Subject: CFV: New Project: CRaC
In-Reply-To: <0ca718f5-ebf9-90d1-7da2-993aede339ef@oracle.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
 <3276cc4e-d9bb-584d-bcff-5586beb4f8c9@redhat.com>
 <f8a3cfd0-a07f-36fd-cba4-0c690a66cbf0@oracle.com>
 <CA+3eh13Fbeaj1bMnkUqz1q7G71SKscPHN_xRTzK90XUH1q_gHw@mail.gmail.com>
 <0ca718f5-ebf9-90d1-7da2-993aede339ef@oracle.com>
Message-ID: <001628ad-dae1-6c8a-4b53-0a1b98b63540@oracle.com>

On 8/6/2021 4:05 AM, Alan Bateman wrote:
> On 05/08/2021 16:21, Volker Simonis wrote:
>> :
>> I totally agree, but is aren't this good arguments for having a
>> project to investigate all these questions?
>>
>> Establishing this project doesn't mean that we will deliver something
>> within the next month but rather that we'll have a common
>> infrastructure for experimenting and a central place for discussions.
>> Obviously, the larger the set of contributors will grow, the better
>> for the project. Needless to say that everybody is highly welcome to
>> share his experience and thoughts.
>>
> It would be good to try to expand the set of contributors as this 
> project as it is likely that it will require prototyping invasive 
> changes to many areas of the libraries.? It may be that the 
> worse-is-better direction in Anton's mails is where it ends up but I 
> do expect that it will have to deal with several issues around 
> security and at least some API/spec changes to allow for behavior 
> after restore/continue.


An implicit corollary worth stating explicitly: the simple existence of 
successful prototype of a portion or a CRaC-like project in no way 
compels or obligates those with skills in other areas, like libraries, 
to explore the invasive changes needed to round-out the work.

-Joe


From thomas.stuefe at gmail.com  Wed Aug 11 16:50:14 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Aug 2021 18:50:14 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <CAA-vtUw_tj8+-vycJgJXzU2wX4izfqE1_p5DTU6ZYCxR3ECC2w@mail.gmail.com>

Vote: yes

On Wed, Aug 11, 2021 at 6:42 PM Philip Race <philip.race at oracle.com> wrote:

> I hereby propose the creation of the Wakefield Project to implement
> support in JDK for the Wayland [1] display server for Linux with Phil
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the
> Linux community has been working on a complete replacement for the
> 1980's era X11 desktop display server protocol  with new protocols and
> libraries that support client-side rendering and a compositing desktop
> windowing system.
>
> This is now the default desktop server technology on several Linux
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
> the only display server, with X11 applications supported only via a
> compatibility mode, in which certain critical Java SE desktop APIs as
> implemented for X11 will not function completely and therefore will not
> be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland
> client.
>
> The latter is the main goal but is significantly more work and will take
> years to fully complete and deliver, hence the need for the short term
> goal too.
>
> In due course, one or more JEPs will be submitted based on work from
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client Libraries
> Group [3] and the Lanai Project [4] and has worked on the JDK client
> technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote
>

From neugens at redhat.com  Wed Aug 11 16:52:47 2021
From: neugens at redhat.com (Mario Torre)
Date: Wed, 11 Aug 2021 18:52:47 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <CAJwKKmYisakYnLrTxZrmPgXt_pLBitsauMS-=Z7p2XSwKKh-Ng@mail.gmail.com>

Vote: Yes!

Cheers,
Mario

On Wed, Aug 11, 2021 at 6:42 PM Philip Race <philip.race at oracle.com> wrote:
>
> I hereby propose the creation of the Wakefield Project to implement
> support in JDK for the Wayland [1] display server for Linux with Phil
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the
> Linux community has been working on a complete replacement for the
> 1980's era X11 desktop display server protocol  with new protocols and
> libraries that support client-side rendering and a compositing desktop
> windowing system.
>
> This is now the default desktop server technology on several Linux
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
> the only display server, with X11 applications supported only via a
> compatibility mode, in which certain critical Java SE desktop APIs as
> implemented for X11 will not function completely and therefore will not
> be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland
> client.
>
> The latter is the main goal but is significantly more work and will take
> years to fully complete and deliver, hence the need for the short term
> goal too.
>
> In due course, one or more JEPs will be submitted based on work from
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client Libraries
> Group [3] and the Lanai Project [4] and has worked on the JDK client
> technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote
>


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


From kevin.rushforth at oracle.com  Wed Aug 11 16:58:57 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 11 Aug 2021 09:58:57 -0700
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <99943065-7828-a378-1f81-4d40a43e648f@oracle.com>

Vote: YES

-- Kevin

On 8/11/2021 6:41 AM, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>


From sgehwolf at redhat.com  Wed Aug 11 16:59:59 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Aug 2021 18:59:59 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <009bb246745df5249e4f01d2d0a538c3fc2956c2.camel@redhat.com>

Vote: yes

On Wed, 2021-08-11 at 06:41 -0700, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> Linux community has been working on a complete replacement for the 
> 1980's era X11 desktop display server protocol? with new protocols and 
> libraries that support client-side rendering and a compositing desktop 
> windowing system.
> 
> This is now the default desktop server technology on several Linux 
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be 
> the only display server, with X11 applications supported only via a 
> implemented for X11 will not function completely and therefore will not 
> be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client.
> 
> The latter is the main goal but is significantly more work and will take 
> years to fully complete and deliver, hence the need for the short term 
> goal too.
> 
> In due course, one or more JEPs will be submitted based on work from 
> this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries 
> Group [3] and the Lanai Project [4] and has worked on the JDK client 
> technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com?
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com?
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful 
> conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote
> 



From Alan.Bateman at oracle.com  Wed Aug 11 17:14:04 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Aug 2021 18:14:04 +0100
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <91f8f8ec-992e-807b-f13a-b943954efba9@oracle.com>

Vote: yes

From kusrinivasan at vmware.com  Wed Aug 11 17:25:41 2021
From: kusrinivasan at vmware.com (Kumar Srinivasan)
Date: Wed, 11 Aug 2021 17:25:41 +0000
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <E6279F31-FC76-4FBF-B56D-4055DB5833C0@vmware.com>

Vote: yes

> On Aug 11, 2021, at 6:41 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby propose the creation of the Wakefield Project to implement support in JDK for the Wayland [1] display server for Linux with Phil Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol  with new protocols and libraries that support client-side rendering and a compositing desktop windowing system.
> 
> This is now the default desktop server technology on several Linux distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be the only display server, with X11 applications supported only via a compatibility mode, in which certain critical Java SE desktop APIs as implemented for X11 will not function completely and therefore will not be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
> - a medium to long term solution for JDK running as a native Wayland client.
> 
> The latter is the main goal but is significantly more work and will take years to fully complete and deliver, hence the need for the short term goal too.
> 
> In due course, one or more JEPs will be submitted based on work from this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries Group [3] and the Lanai Project [4] and has worked on the JDK client technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwayland.freedesktop.org%2F&amp;data=04%7C01%7Ckusrinivasan%40vmware.com%7C8571b700ea884469b26308d95ce707ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637642969606452574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=GS%2FOTlmIYxfuVVilIg6g7iU5gY9iLH3o%2BqD3Ey2e49Y%3D&amp;reserved=0
> [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fdiscuss%2F2021-July%2F005846.html&amp;data=04%7C01%7Ckusrinivasan%40vmware.com%7C8571b700ea884469b26308d95ce707ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637642969606462571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cawCtZYFHmQksQ1rpgbj4JBwoUYvlPpsJXrDgKeGiXg%3D&amp;reserved=0
> [3] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcensus%23client-libs&amp;data=04%7C01%7Ckusrinivasan%40vmware.com%7C8571b700ea884469b26308d95ce707ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637642969606462571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mpzwHnuL9uFL%2FukPiNMLHf%2BkaywyNzs0EhmbNJIJHUQ%3D&amp;reserved=0
> [4] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcensus%23lanai&amp;data=04%7C01%7Ckusrinivasan%40vmware.com%7C8571b700ea884469b26308d95ce707ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637642969606462571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vhWfaHeSpMiEsW7ErbOJRBruo5dRvLrE%2BqQz%2BFzL4dE%3D&amp;reserved=0
> [5] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fcensus%23members&amp;data=04%7C01%7Ckusrinivasan%40vmware.com%7C8571b700ea884469b26308d95ce707ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637642969606462571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TUp0SOzMsPrQVJc3A6i0KCa3LkRPd7K4ZrTw7sdDVAw%3D&amp;reserved=0
> [6] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23new-project-vote&amp;data=04%7C01%7Ckusrinivasan%40vmware.com%7C8571b700ea884469b26308d95ce707ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637642969606462571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FWhCrnKh%2FG3SERI7IedDbNl6EUSKdwHR3%2FqHPtP0WCA%3D&amp;reserved=0


From maurizio.cimadamore at oracle.com  Wed Aug 11 17:27:19 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 11 Aug 2021 18:27:19 +0100
Subject: CFV: New Project: Wakefield
In-Reply-To: <CAA-vtUw_tj8+-vycJgJXzU2wX4izfqE1_p5DTU6ZYCxR3ECC2w@mail.gmail.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
 <CAA-vtUw_tj8+-vycJgJXzU2wX4izfqE1_p5DTU6ZYCxR3ECC2w@mail.gmail.com>
Message-ID: <b7b20aea-325d-e791-cde4-b48e5d108d72@oracle.com>

Vote: yes

Maurizio

On 11/08/2021 17:50, Thomas St?fe wrote:
> Vote: yes
>
> On Wed, Aug 11, 2021 at 6:42 PM Philip Race <philip.race at oracle.com> wrote:
>
>> I hereby propose the creation of the Wakefield Project to implement
>> support in JDK for the Wayland [1] display server for Linux with Phil
>> Race as the lead and the Client Libraries Group as the sponsoring Group.
>>
>> Background and Motivation:
>> As previously noted in the well received Call for Discussion [2], the
>> Linux community has been working on a complete replacement for the
>> 1980's era X11 desktop display server protocol  with new protocols and
>> libraries that support client-side rendering and a compositing desktop
>> windowing system.
>>
>> This is now the default desktop server technology on several Linux
>> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
>> the only display server, with X11 applications supported only via a
>> compatibility mode, in which certain critical Java SE desktop APIs as
>> implemented for X11 will not function completely and therefore will not
>> be TCK compliant.
>>
>> The Wakefield Project will pursue two goals:
>> - a short to medium term solution for JDK running on Wayland in X11
>> compatibility mode
>> - a medium to long term solution for JDK running as a native Wayland
>> client.
>>
>> The latter is the main goal but is significantly more work and will take
>> years to fully complete and deliver, hence the need for the short term
>> goal too.
>>
>> In due course, one or more JEPs will be submitted based on work from
>> this Project.
>>
>> The proposed Project lead, Phil Race is the lead of the Client Libraries
>> Group [3] and the Lanai Project [4] and has worked on the JDK client
>> technologies for many years.
>>
>> Proposed Initial committers include
>> Phil Race (prr)
>> Alexander Zvegintsev (azvegint)
>> Alexander Zuev (kizune)
>> Sergey Bylokhov (serb)
>> Kevin Rushforth (kcr)
>> Pankaj Bansal (pbansal)
>> Alexey Ushakov (avu)
>> Dmitry Batrak (dbatrak)
>> Maxim Kartashev maxim.kartashev at jetbrains.com
>> <mailto:maxim.kartashev at jetbrains.com>
>> Nikita Gubarkov nikita.gubarkov at jetbrains.com
>> <mailto:nikita.gubarkov at jetbrains.com>
>> Mario Torre (neugens)
>> Roman Kennke (rkennke)
>> Zdenek Zambersky <zzambers at redhat.com>
>>
>> A complete list will be provided to the registrar on the successful
>> conclusion of this CFV.
>>
>> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>>
>> Only current OpenJDK Members [5] 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 [6].
>>
>> -Phil Race.
>>
>> [1] https://wayland.freedesktop.org/
>> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
>> [3] https://openjdk.java.net/census#client-libs
>> [4] https://openjdk.java.net/census#lanai
>> [5] http://openjdk.java.net/census#members
>> [6] http://openjdk.java.net/projects/#new-project-vote
>>

From jesper.wilhelmsson at oracle.com  Wed Aug 11 17:37:15 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 11 Aug 2021 17:37:15 +0000
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <E84FC85D-3E19-43EF-87F2-29C74E6CE11F@oracle.com>

Vote: Yes
/Jesper

> 11 aug. 2021 kl. 15:41 skrev Philip Race <philip.race at oracle.com>:
> 
> I hereby propose the creation of the Wakefield Project to implement support in JDK for the Wayland [1] display server for Linux with Phil Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol  with new protocols and libraries that support client-side rendering and a compositing desktop windowing system.
> 
> This is now the default desktop server technology on several Linux distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be the only display server, with X11 applications supported only via a compatibility mode, in which certain critical Java SE desktop APIs as implemented for X11 will not function completely and therefore will not be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
> - a medium to long term solution for JDK running as a native Wayland client.
> 
> The latter is the main goal but is significantly more work and will take years to fully complete and deliver, hence the need for the short term goal too.
> 
> In due course, one or more JEPs will be submitted based on work from this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries Group [3] and the Lanai Project [4] and has worked on the JDK client technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote


From naoto.sato at oracle.com  Wed Aug 11 17:59:11 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Aug 2021 10:59:11 -0700
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <5b3f4497-6b8b-9e73-e3f3-1569e41d13af@oracle.com>

Vote: yes

Naoto

On 8/11/21 6:41 AM, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the 
> Linux community has been working on a complete replacement for the 
> 1980's era X11 desktop display server protocol? with new protocols and 
> libraries that support client-side rendering and a compositing desktop 
> windowing system.
> 
> This is now the default desktop server technology on several Linux 
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be 
> the only display server, with X11 applications supported only via a 
> compatibility mode, in which certain critical Java SE desktop APIs as 
> implemented for X11 will not function completely and therefore will not 
> be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client.
> 
> The latter is the main goal but is significantly more work and will take 
> years to fully complete and deliver, hence the need for the short term 
> goal too.
> 
> In due course, one or more JEPs will be submitted based on work from 
> this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries 
> Group [3] and the Lanai Project [4] and has worked on the JDK client 
> technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com 
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com 
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful 
> conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote

From joe.darcy at oracle.com  Wed Aug 11 18:02:09 2021
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 11 Aug 2021 11:02:09 -0700
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <04995d59-e925-f308-5b1f-97f31ce014dd@oracle.com>

Vote: yes

-Joe

On 8/11/2021 6:41 AM, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the 
> Linux community has been working on a complete replacement for the 
> 1980's era X11 desktop display server protocol? with new protocols and 
> libraries that support client-side rendering and a compositing desktop 
> windowing system.
>
> This is now the default desktop server technology on several Linux 
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be 
> the only display server, with X11 applications supported only via a 
> compatibility mode, in which certain critical Java SE desktop APIs as 
> implemented for X11 will not function completely and therefore will 
> not be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client.
>
> The latter is the main goal but is significantly more work and will 
> take years to fully complete and deliver, hence the need for the short 
> term goal too.
>
> In due course, one or more JEPs will be submitted based on work from 
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client 
> Libraries Group [3] and the Lanai Project [4] and has worked on the 
> JDK client technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com 
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com 
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful 
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote

From james.laskey at oracle.com  Wed Aug 11 18:14:19 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 11 Aug 2021 18:14:19 +0000
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <51D51FB8-7A98-455E-90EC-B6D91720EBF4@oracle.com>


Vote: yes
??

> On Aug 11, 2021, at 1:41 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> ?I hereby propose the creation of the Wakefield Project to implement support in JDK for the Wayland [1] display server for Linux with Phil Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol  with new protocols and libraries that support client-side rendering and a compositing desktop windowing system.
> 
> This is now the default desktop server technology on several Linux distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be the only display server, with X11 applications supported only via a compatibility mode, in which certain critical Java SE desktop APIs as implemented for X11 will not function completely and therefore will not be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
> - a medium to long term solution for JDK running as a native Wayland client.
> 
> The latter is the main goal but is significantly more work and will take years to fully complete and deliver, hence the need for the short term goal too.
> 
> In due course, one or more JEPs will be submitted based on work from this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries Group [3] and the Lanai Project [4] and has worked on the JDK client technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote

From mbalao at redhat.com  Wed Aug 11 18:43:29 2021
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 11 Aug 2021 14:43:29 -0400
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <CAKZz+gfPZp0460UyrsG7fHuNzB4ggO6ns6oA0aiYfVZd6mfFRw@mail.gmail.com>

Vote: Yes

On Wed, Aug 11, 2021 at 12:45 PM Philip Race <philip.race at oracle.com> wrote:
>
> I hereby propose the creation of the Wakefield Project to implement
> support in JDK for the Wayland [1] display server for Linux with Phil
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the
> Linux community has been working on a complete replacement for the
> 1980's era X11 desktop display server protocol  with new protocols and
> libraries that support client-side rendering and a compositing desktop
> windowing system.
>
> This is now the default desktop server technology on several Linux
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
> the only display server, with X11 applications supported only via a
> compatibility mode, in which certain critical Java SE desktop APIs as
> implemented for X11 will not function completely and therefore will not
> be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland
> client.
>
> The latter is the main goal but is significantly more work and will take
> years to fully complete and deliver, hence the need for the short term
> goal too.
>
> In due course, one or more JEPs will be submitted based on work from
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client Libraries
> Group [3] and the Lanai Project [4] and has worked on the JDK client
> technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote
>


From peter.levart at gmail.com  Thu Aug 12 05:15:04 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Aug 2021 07:15:04 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <CAJUsCJAYeGjUCuW9Tzxg2CFdzyFeZySE8iFVii6EmBT_GnjiSw@mail.gmail.com>

Vote: yes

On Wed, 11 Aug 2021, 18:42 Philip Race, <philip.race at oracle.com> wrote:

> I hereby propose the creation of the Wakefield Project to implement
> support in JDK for the Wayland [1] display server for Linux with Phil
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the
> Linux community has been working on a complete replacement for the
> 1980's era X11 desktop display server protocol  with new protocols and
> libraries that support client-side rendering and a compositing desktop
> windowing system.
>
> This is now the default desktop server technology on several Linux
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
> the only display server, with X11 applications supported only via a
> compatibility mode, in which certain critical Java SE desktop APIs as
> implemented for X11 will not function completely and therefore will not
> be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland
> client.
>
> The latter is the main goal but is significantly more work and will take
> years to fully complete and deliver, hence the need for the short term
> goal too.
>
> In due course, one or more JEPs will be submitted based on work from
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client Libraries
> Group [3] and the Lanai Project [4] and has worked on the JDK client
> technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote
>

From dalibor.topic at oracle.com  Thu Aug 12 16:33:50 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 12 Aug 2021 18:33:50 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <7993cf1e-6577-e6fc-4ef6-38a0cd4243c2@oracle.com>

Vote: Yes.

On 11.08.2021 15:41, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.

cheers,
dalibor topic

-- 
<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 abrygin at azul.com  Thu Aug 12 17:07:21 2021
From: abrygin at azul.com (Andrew Brygin)
Date: Thu, 12 Aug 2021 20:07:21 +0300
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <fdc8fb59-5cc8-a4f7-39a2-56fc229d4668@azul.com>

Vote: yes

On 11/08/2021 16:41, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement
> support in JDK for the Wayland [1] display server for Linux with Phil
> Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the
> Linux community has been working on a complete replacement for the
> 1980's era X11 desktop display server protocol? with new protocols and
> libraries that support client-side rendering and a compositing desktop
> windowing system.
> 
> This is now the default desktop server technology on several Linux
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
> the only display server, with X11 applications supported only via a
> compatibility mode, in which certain critical Java SE desktop APIs as
> implemented for X11 will not function completely and therefore will not
> be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland
> client.
> 
> The latter is the main goal but is significantly more work and will take
> years to fully complete and deliver, hence the need for the short term
> goal too.
> 
> In due course, one or more JEPs will be submitted based on work from
> this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries
> Group [3] and the Lanai Project [4] and has worked on the JDK client
> technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful
> conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote

From philip.race at oracle.com  Thu Aug 12 17:22:14 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 12 Aug 2021 10:22:14 -0700
Subject: CFV: New Project: Wakefield
In-Reply-To: <99943065-7828-a378-1f81-4d40a43e648f@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
 <99943065-7828-a378-1f81-4d40a43e648f@oracle.com>
Message-ID: <28cc3073-b79a-a21c-ef69-f5ad4cdec2b9@oracle.com>

Vote: yes

-phil.

From bylokhov at amazon.com  Thu Aug 12 17:49:35 2021
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 10:49:35 -0700
Subject: CFV: New Project: Wakefield
In-Reply-To: <CAA-vtUw_tj8+-vycJgJXzU2wX4izfqE1_p5DTU6ZYCxR3ECC2w@mail.gmail.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
 <CAA-vtUw_tj8+-vycJgJXzU2wX4izfqE1_p5DTU6ZYCxR3ECC2w@mail.gmail.com>
Message-ID: <1a566dd2-1b62-0f66-bfa2-e0d145230ca4@amazon.com>

Vote: yes

-- 
Best regards, Sergey.

From mikael.vidstedt at oracle.com  Thu Aug 12 18:30:42 2021
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 12 Aug 2021 18:30:42 +0000
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <9786BC95-DA76-4CCF-8797-A758CDB7E4BD@oracle.com>


Vote: yes

Cheers,
Mikael

> On Aug 11, 2021, at 6:41 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby propose the creation of the Wakefield Project to implement support in JDK for the Wayland [1] display server for Linux with Phil Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol  with new protocols and libraries that support client-side rendering and a compositing desktop windowing system.
> 
> This is now the default desktop server technology on several Linux distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be the only display server, with X11 applications supported only via a compatibility mode, in which certain critical Java SE desktop APIs as implemented for X11 will not function completely and therefore will not be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
> - a medium to long term solution for JDK running as a native Wayland client.
> 
> The latter is the main goal but is significantly more work and will take years to fully complete and deliver, hence the need for the short term goal too.
> 
> In due course, one or more JEPs will be submitted based on work from this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries Group [3] and the Lanai Project [4] and has worked on the JDK client technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote


From magnus.ihse.bursie at oracle.com  Tue Aug 17 09:33:22 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 17 Aug 2021 11:33:22 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <c216790f-a96d-f939-b18e-a6f894c43066@oracle.com>

Vote: yes

/Magnus

On 2021-08-11 15:41, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the 
> Linux community has been working on a complete replacement for the 
> 1980's era X11 desktop display server protocol? with new protocols and 
> libraries that support client-side rendering and a compositing desktop 
> windowing system.
>
> This is now the default desktop server technology on several Linux 
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be 
> the only display server, with X11 applications supported only via a 
> compatibility mode, in which certain critical Java SE desktop APIs as 
> implemented for X11 will not function completely and therefore will 
> not be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client.
>
> The latter is the main goal but is significantly more work and will 
> take years to fully complete and deliver, hence the need for the short 
> term goal too.
>
> In due course, one or more JEPs will be submitted based on work from 
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client 
> Libraries Group [3] and the Lanai Project [4] and has worked on the 
> JDK client technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com 
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com 
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful 
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote


From roger.riggs at oracle.com  Tue Aug 17 15:00:58 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 17 Aug 2021 11:00:58 -0400
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <f2a14cc9-db13-cdf1-3113-77687e416240@oracle.com>

Vote: Yes

On 8/11/21 9:41 AM, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.


From volker.simonis at gmail.com  Tue Aug 17 15:14:01 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 17 Aug 2021 17:14:01 +0200
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <CA+3eh10hxNgAQGkcKnX4ZoAR2A0v7SnrzaPdnxjtSPEHGYgUzw@mail.gmail.com>

Vote: yes

On Wed, Aug 11, 2021 at 6:42 PM Philip Race <philip.race at oracle.com> wrote:
>
> I hereby propose the creation of the Wakefield Project to implement
> support in JDK for the Wayland [1] display server for Linux with Phil
> Race as the lead and the Client Libraries Group as the sponsoring Group.
>
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the
> Linux community has been working on a complete replacement for the
> 1980's era X11 desktop display server protocol  with new protocols and
> libraries that support client-side rendering and a compositing desktop
> windowing system.
>
> This is now the default desktop server technology on several Linux
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be
> the only display server, with X11 applications supported only via a
> compatibility mode, in which certain critical Java SE desktop APIs as
> implemented for X11 will not function completely and therefore will not
> be TCK compliant.
>
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland
> client.
>
> The latter is the main goal but is significantly more work and will take
> years to fully complete and deliver, hence the need for the short term
> goal too.
>
> In due course, one or more JEPs will be submitted based on work from
> this Project.
>
> The proposed Project lead, Phil Race is the lead of the Client Libraries
> Group [3] and the Lanai Project [4] and has worked on the JDK client
> technologies for many years.
>
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
>
> A complete list will be provided to the registrar on the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
>
> Only current OpenJDK Members [5] 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 [6].
>
> -Phil Race.
>
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote

From yan at azul.com  Thu Aug 19 07:09:03 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Thu, 19 Aug 2021 10:09:03 +0300
Subject: CFV: New Project: Wakefield
In-Reply-To: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
References: <c10add2f-b17c-c12f-f303-9655d65bfa23@oracle.com>
Message-ID: <c138cf1a-e589-5dba-dc57-b8ca2f59d955@azul.com>

Vote: yes

On 11.08.2021 16:41, Philip Race wrote:
> I hereby propose the creation of the Wakefield Project to implement 
> support in JDK for the Wayland [1] display server for Linux with Phil 
> Race as the lead and the Client Libraries Group as the sponsoring Group.
> 
> Background and Motivation:
> As previously noted in the well received Call for Discussion [2], the 
> Linux community has been working on a complete replacement for the 
> 1980's era X11 desktop display server protocol? with new protocols and 
> libraries that support client-side rendering and a compositing desktop 
> windowing system.
> 
> This is now the default desktop server technology on several Linux 
> distros, including RHEL 8, OL 8, and Ubuntu 21.04, and some day may be 
> the only display server, with X11 applications supported only via a 
> compatibility mode, in which certain critical Java SE desktop APIs as 
> implemented for X11 will not function completely and therefore will not 
> be TCK compliant.
> 
> The Wakefield Project will pursue two goals:
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client.
> 
> The latter is the main goal but is significantly more work and will take 
> years to fully complete and deliver, hence the need for the short term 
> goal too.
> 
> In due course, one or more JEPs will be submitted based on work from 
> this Project.
> 
> The proposed Project lead, Phil Race is the lead of the Client Libraries 
> Group [3] and the Lanai Project [4] and has worked on the JDK client 
> technologies for many years.
> 
> Proposed Initial committers include
> Phil Race (prr)
> Alexander Zvegintsev (azvegint)
> Alexander Zuev (kizune)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Pankaj Bansal (pbansal)
> Alexey Ushakov (avu)
> Dmitry Batrak (dbatrak)
> Maxim Kartashev maxim.kartashev at jetbrains.com 
> <mailto:maxim.kartashev at jetbrains.com>
> Nikita Gubarkov nikita.gubarkov at jetbrains.com 
> <mailto:nikita.gubarkov at jetbrains.com>
> Mario Torre (neugens)
> Roman Kennke (rkennke)
> Zdenek Zambersky <zzambers at redhat.com>
> 
> A complete list will be provided to the registrar on the successful 
> conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Wednesday August 25th 2021.
> 
> Only current OpenJDK Members [5] 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 [6].
> 
> -Phil Race.
> 
> [1] https://wayland.freedesktop.org/
> [2] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> [3] https://openjdk.java.net/census#client-libs
> [4] https://openjdk.java.net/census#lanai
> [5] http://openjdk.java.net/census#members
> [6] http://openjdk.java.net/projects/#new-project-vote

From akozlov at azul.com  Fri Aug 20 18:24:55 2021
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 20 Aug 2021 21:24:55 +0300
Subject: CFV: New Project: CRaC
In-Reply-To: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
References: <4f4ac477-e574-5c96-0d95-f8a050f30d84@azul.com>
Message-ID: <cd6c6ba1-6bc3-25ce-f39b-ba86c1465f45@azul.com>

The voting period is over. Looking back, I understand concerns that are
associated with the project, technical and organizational ones. I hope my
answers on those were clear, and I'll do my best to align actions with them.

The CRaC Project is a research project without defined success metrics, at
least for now. The proposed initial implementation is just the
proof-of-concept, and likely it will change. If you have another related work,
please bring it, and we'll see how to combine the best of them.

I have underestimated the interest of the community in the project. I hoped
that people would like to contribute. But I have not expected the initial set
of contributors would be very important since it always can grow. We are
welcome anyone willing to contribute, by a code, review, or advice, now or in
the future. For the status, a record in the JDK project looks to be a good
enough qualification for the CRaC project for a person willing to contribute.
Another CRaC-like or related implementation too.

If I'd be composing the CFV now, I would end up with the same result. I would
add more initial contributors, but I don't have names. So the most
straightforward action now is to announce voting results. Meanwhile, I'll look
at what I can do to involve more people.

Thanks,
Anton

On 7/30/21 10:17 PM, Anton Kozlov wrote:
> I hereby propose the creation of the CRaC Project with myself, Anton Kozlov,
> as the Lead and the HotSpot Group as the sponsoring Group.
> 
> The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> coordination of Java programs with mechanisms to checkpoint (make an image of,
> snapshot) a Java instance while it is executing.? Restoring from the image
> could be a solution to some of the problems with the start-up and warm-up
> times.? The primary aim of the project is to develop a new standard
> mechanism-agnostic API to notify Java programs about the checkpoint and restore
> events.? Other research activities will include, but will not be limited to,
> integration with existing checkpoint/restore mechanisms and development of new
> ones, changes to JVM and JDK to make images smaller and ensure they are
> correct.
> 
> The existing proof-of-concept implementation based on the OpenJDK [2] will be a
> starting point of the project.
> 
> I work at Azul developing JVM and JDK, focusing on bug fixing, support of new
> platforms, and start-up/warm-up optimizations.? I'm a co-author of JEP-391 and
> author of the CRaC proof-of-concept implementation.
> 
> Initial Committers and Reviewers are:
> Volker Simonis (Committer)
> Anton Kozlov (Reviewer)
> 
> Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
> 
> Only current OpenJDK Members [3] 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 [4].
> 
> Anton Kozlov
> 
> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> [2] https://github.com/CRaC/jdk
> [3] https://openjdk.java.net/census#members
> [4] https://openjdk.java.net/projects/#new-project-vote
> 

From volker.simonis at gmail.com  Tue Aug 31 09:08:12 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 31 Aug 2021 11:08:12 +0200
Subject: Result: New Project: CRaC
In-Reply-To: <d0ff1991-f5e4-e115-40c0-d06eb9c479fe@azul.com>
References: <d0ff1991-f5e4-e115-40c0-d06eb9c479fe@azul.com>
Message-ID: <CA+3eh10tEsxxUQuVV=Z0NupLCYV6rNrTgaSDJe-Fx+oGwGsRNw@mail.gmail.com>

Hi,

any estimation when we will have a mailing list and a repository with
the initial implementation?

Thank you and best regards,
Volker

On Fri, Aug 20, 2021 at 9:23 PM Anton Kozlov <akozlov at azul.com> wrote:
>
> Voting on the CRaC Project with initial Lead Anton Kozlov [1]
> is now closed.
>
> Yes: 4
> Veto: 0
> Abstain: 2
>
> According to the Bylaws definition of Lazy Consensus, this is
> sufficient to approve the new Project and its initial Lead.
>
> Anton Kozlov
>
> [1] https://mail.openjdk.java.net/pipermail/announce/2021-July/000304.html

From iris.clark at oracle.com  Tue Aug 31 15:09:06 2021
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 31 Aug 2021 15:09:06 +0000
Subject: Result: New Project: CRaC
In-Reply-To: <CA+3eh10tEsxxUQuVV=Z0NupLCYV6rNrTgaSDJe-Fx+oGwGsRNw@mail.gmail.com>
References: <d0ff1991-f5e4-e115-40c0-d06eb9c479fe@azul.com>
 <CA+3eh10tEsxxUQuVV=Z0NupLCYV6rNrTgaSDJe-Fx+oGwGsRNw@mail.gmail.com>
Message-ID: <MN2PR10MB436658A838C788A27FB88453FBCC9@MN2PR10MB4366.namprd10.prod.outlook.com>

Hi, Volker.

The initial repo creation is scheduled for this Thu 2 Sep.  I hope to have the mailing list and other resources up by that time.

Thanks,
Iris

________________________________
From: Volker Simonis <volker.simonis at gmail.com>
Sent: Tuesday, August 31, 2021 2:08 AM
To: discuss at openjdk.java.net <discuss at openjdk.java.net>
Cc: announce at openjdk.java.net <announce at openjdk.java.net>; registrar at openjdk.java.net <registrar at openjdk.java.net>
Subject: Re: Result: New Project: CRaC

Hi,

any estimation when we will have a mailing list and a repository with
the initial implementation?

Thank you and best regards,
Volker

On Fri, Aug 20, 2021 at 9:23 PM Anton Kozlov <akozlov at azul.com> wrote:
>
> Voting on the CRaC Project with initial Lead Anton Kozlov [1]
> is now closed.
>
> Yes: 4
> Veto: 0
> Abstain: 2
>
> According to the Bylaws definition of Lazy Consensus, this is
> sufficient to approve the new Project and its initial Lead.
>
> Anton Kozlov
>
> [1] https://mail.openjdk.java.net/pipermail/announce/2021-July/000304.html

From volker.simonis at gmail.com  Tue Aug 31 15:41:01 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 31 Aug 2021 17:41:01 +0200
Subject: Result: New Project: CRaC
In-Reply-To: <MN2PR10MB436658A838C788A27FB88453FBCC9@MN2PR10MB4366.namprd10.prod.outlook.com>
References: <d0ff1991-f5e4-e115-40c0-d06eb9c479fe@azul.com>
 <CA+3eh10tEsxxUQuVV=Z0NupLCYV6rNrTgaSDJe-Fx+oGwGsRNw@mail.gmail.com>
 <MN2PR10MB436658A838C788A27FB88453FBCC9@MN2PR10MB4366.namprd10.prod.outlook.com>
Message-ID: <CA+3eh12afvwjON5gTFy4wtmQ32YGog4S9hBQu-bG2xnje_s0xA@mail.gmail.com>

Hi Iris,

thanks for the information. That sounds perfect!

Best regards,
Volker

On Tue, Aug 31, 2021 at 5:09 PM Iris Clark <iris.clark at oracle.com> wrote:
>
> Hi, Volker.
>
> The initial repo creation is scheduled for this Thu 2 Sep.  I hope to have the mailing list and other resources up by that time.
>
> Thanks,
> Iris
>
> ________________________________
> From: Volker Simonis <volker.simonis at gmail.com>
> Sent: Tuesday, August 31, 2021 2:08 AM
> To: discuss at openjdk.java.net <discuss at openjdk.java.net>
> Cc: announce at openjdk.java.net <announce at openjdk.java.net>; registrar at openjdk.java.net <registrar at openjdk.java.net>
> Subject: Re: Result: New Project: CRaC
>
> Hi,
>
> any estimation when we will have a mailing list and a repository with
> the initial implementation?
>
> Thank you and best regards,
> Volker
>
> On Fri, Aug 20, 2021 at 9:23 PM Anton Kozlov <akozlov at azul.com> wrote:
> >
> > Voting on the CRaC Project with initial Lead Anton Kozlov [1]
> > is now closed.
> >
> > Yes: 4
> > Veto: 0
> > Abstain: 2
> >
> > According to the Bylaws definition of Lazy Consensus, this is
> > sufficient to approve the new Project and its initial Lead.
> >
> > Anton Kozlov
> >
> > [1] https://mail.openjdk.java.net/pipermail/announce/2021-July/000304.html