On 01/02/2022 09:11, Anton Kozlov wrote:
Cross-posting RFR from CRaC Project. The change touches Reference
class, so I
would be glad to receive any feedback from core-libs-dev.
In CRaC project, java code participates in the preparation of the
platform
state that can be safely stored to the image. The image can be
attempted at any
time, so the image may capture unprocessed References. Recently I
found cases
when objects became unreachable during preparation for the checkpoint,
and
their associated clean-up actions to close external resources (which
we don't
allow open when the image is stored). So it's become necessary to
ensure as
many References as possible are processed before the image is created.
As a
nice additional feature, restored java instances won't start with the
same
Reference processing.
With the change, the image is not created until VM's queue of pending
j.l.References are drained, and then, as an example, each
j.l.ref.Cleaner queue
is drained, only then the VM is called to prepare the image. More
Reference
handling threads will be changed like Cleaner's ones. I'm looking for
possible
problems or general comments about this approach.
At a high level it should be okay to provide a JDK-internal way to await
quiescent. You've added it as a public API which might be okay for the
current exploration but I don't think it would be exposed in its current
form. Once the method returns then there is no guarantee that the number
of waiters hasn't changed, but I think you know that.
-Alan.
