<div dir="ltr">Hi Radim,<div><br>(Unfortunately, the mailing list didn't deliver the original message nor the replay. So i'm reposting with Re instead) <div><br></div><div>The distributed process synchronization is a hard topic and, IMO, CRaC should at least offer some help with it. For example if the primary goal is to provide a functional warmed up clone of the application (as opposed to data replication), then perhaps we can relax the data consistency as long as the application and its components are up and running in the right order.</div><div><br></div><div>Then approaches such as:<br><br>> To avoid extra synchronization it could be technically possible to<br>> modify CRaC implementation to keep all other threads frozen during <br>> restore.</div><div>or</div>> Another solution could try to leverage existing JVM mechanics for code<br>> deoptimization, replacing the critical sections with a slower, blocking <br>> stub, and reverting back after restore. Or even independently requesting <br>> a safe-point and inspecting stack of threads until the synchronization <br>> is possible.<div><br>would be a workable solution, despite the inconsistencies they may introduce. </div></div><div><br></div>I agree with your observation that: <br>> unless we offer something that does not harm a no-CRaC use-case<br>> I am afraid that the adoption will be quite limited.<div><br>I wrongly assumed that CRaC provides some process synchronization mechanism, while in reality it imposes a new programming model that leaves the synchronization tasks to the end developers. <br>Then the complexity of using CRaC with existing applications would be an order of magnitude higher compared to making the same applications GraalVM compliant. </div><div><br></div><div>Cheers,</div><div>Christian</div><div><br></div></div>