CFV: New Project: CRaC

Christine Flood chf at redhat.com
Thu Aug 5 16:36:17 UTC 2021


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


More information about the discuss mailing list