On restore the "main" thread is started before the Resource's afterRestore has completed

[Radim Vansa]

Hi Christian,

comments inline...

On 05. 04. 23 14:05, Christian Tzolov wrote:
> Hi Radim,
>
> (Unfortunately, the mailing list didn't deliver the original message nor the replay. So i'm reposting with Re instead)
>
> The distributed process synchronization is a hard topic and, IMO, CRaC should at least offer some help with it.

I agree; what might be discussed is what portion of this 'help' should 
be a part of the API and its contracts, and what should be a part of the 
reference implementation.


> 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.
>
> Then approaches such as:
>
>> To avoid extra synchronization it could be technically possible to
>> modify CRaC implementation to keep all other threads frozen during
>> restore.
> or
>> Another solution could try to leverage existing JVM mechanics for code
>> deoptimization, replacing the critical sections with a slower, blocking
>> stub, and reverting back after restore. Or even independently requesting
>> a safe-point and inspecting stack of threads until the synchronization
>> is possible.
> would be a workable solution, despite the inconsistencies they may introduce.
>
> I agree with your observation that:
>> unless we offer something that does not harm a no-CRaC use-case
>> I am afraid that the adoption will be quite limited.
> 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.
> Then the complexity of using CRaC with existing applications would be an order of magnitude higher compared to making the same applications GraalVM compliant.


Personally I find the term 'new programming model' rather exaggerated. 
CRaC does not pretend to offer a silver bullet without any effort made 
on the user side. However when you speak about 'relaxing consistency' I 
hear obscure bugs. I think that CRaC tries to be more conservative than 
GraalVM and not introduce any limitations in the runtime. Hence 
GraalVM-compliant and 100%-proof on GraalVM might be a different thing. 
(Please take my opinion with a grain of salt since my experience with 
Graal is rather limited.) Both JDK and Graal are driven by very smart 
developers; it's about compromises that each project takes.

While we don't offer a perfect solution yet I hope that the number of 
'friction points' in adoption is quite limited. Wish you the best luck 
with that!

Cheers,

Radim Vansa