[crac] RFR: Fix ordering of invocation on Resources [v13]

Anton Kozlov akozlov at openjdk.org
Fri May 12 11:24:17 UTC 2023


On Wed, 10 May 2023 12:49:03 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> * keeps the original handling of exceptions: afterRestore is called even if beforeCheckpoint throws
>> * allows to register a resource in a context that did not start beforeCheckpoint invocations yet
>> * registering resource in previous/running context fails the checkpoint but does not trigger exception immediately
>>    * instead this will be one of the recorded exceptions and the resource has a chance to fire next time
>> * allowed registration of resources can be invoked from other thread without deadlock; illegal registration can deadlock, though
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removing the logging configuration

Stack trace after merging #66 => the jdk.crac code also cannot use lambdas:


"main" #1 prio=5 os_prio=0 cpu=89.78ms elapsed=16.55s tid=0x00007f0a68025160 nid=0x28513b in Object.wait()  [0x00007f0a6d9fd000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(java.base at 17-internal/Native Method)
	- waiting on <0x000000041a802088> (a jdk.internal.crac.JDKContext)
	at java.lang.Object.wait(java.base at 17-internal/Object.java:338)
	at jdk.crac.impl.AbstractContextImpl.waitWhileCheckpointIsInProgress(java.base at 17-internal/AbstractContextImpl.java:102)
	at jdk.crac.impl.PriorityContext.register(java.base at 17-internal/PriorityContext.java:44)
	- locked <0x000000041a802088> (a jdk.internal.crac.JDKContext)
	at jdk.internal.crac.JDKContext.register(java.base at 17-internal/JDKContext.java:97)
	at jdk.internal.ref.CleanerImpl$PhantomCleanableRef.<init>(java.base at 17-internal/CleanerImpl.java:173)
	at java.lang.invoke.MethodHandleNatives$CallSiteContext.make(java.base at 17-internal/MethodHandleNatives.java:93)
	at java.lang.invoke.CallSite.<init>(java.base at 17-internal/CallSite.java:144)
	at java.lang.invoke.ConstantCallSite.<init>(java.base at 17-internal/ConstantCallSite.java:50)
	at java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(java.base at 17-internal/InnerClassLambdaMetafactory.java:262)
	at java.lang.invoke.LambdaMetafactory.metafactory(java.base at 17-internal/LambdaMetafactory.java:341)
	at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base at 17-internal/DirectMethodHandle$Holder)
	at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 17-internal/Invokers$Holder)
	at java.lang.invoke.BootstrapMethodInvoker.invoke(java.base at 17-internal/BootstrapMethodInvoker.java:134)
	at java.lang.invoke.CallSite.makeSite(java.base at 17-internal/CallSite.java:315)
	at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base at 17-internal/MethodHandleNatives.java:285)
	at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base at 17-internal/MethodHandleNatives.java:275)
	at jdk.internal.crac.JDKContext.getClaimedFds(java.base at 17-internal/JDKContext.java:102)
	at jdk.crac.Core.checkpointRestore1(java.base at 17-internal/Core.java:125)
	at jdk.crac.Core.checkpointRestore(java.base at 17-internal/Core.java:256)
	- locked <0x000000041a802118> (a java.lang.Object)
	at jdk.crac.Core.checkpointRestore(java.base at 17-internal/Core.java:241)
	at CheckpointWithOpenFdsTest.exec(CheckpointWithOpenFdsTest.java:49)
	at jdk.test.lib.crac.CracTest.run(CracTest.java:157)
	at jdk.test.lib.crac.CracTest.main(CracTest.java:89)

-------------

PR Comment: https://git.openjdk.org/crac/pull/60#issuecomment-1545588281


More information about the crac-dev mailing list