[crac] RFR: Draft: Move more FD tracking to java layer

[Radim Vansa]

On Thu, 8 Jun 2023 17:27:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Motiviation for the PR is described in the description. You're right that the change mostly a refactoring. To repeat, this continues non-Linux CRaC implementations with the semantic shared between them, and this is also a foundation for optional checkpoint-restore resource policies implemented in the Socket, File,.. classes.

So, this is to support implementation on other platforms where you can't read what is the FD/handle pointing to? What platform is lacking this info?

> A higher level object like Socket or File usually has more information regarding FD and the uses, thus it can provide more information or implement wider set of policies.

With Socket, you can get the IPs and ports. JVM is mostly providing API for accessing OS-level info. The same for files. But you can get that info quite easily on the FD level without a hierarchical claiming.

> The chain of ownership will become a real problem once on every other layer we have more information that we want to report. In your example, FileWriter will have to claim FD if it has more information about that. But immediatly this is not clear.

Maybe if the API allowed claiming ownership of any object, rather than just FD (that would be propagated), and you'd provide information from all chain elements (rather than just the topmost).

> Stack traces are a great addition to the debug workflow, they describe the state on the moment of creation. But heap dump describes the state at the checkpoint exception. They provide different aspects, one or another may suit better different conditions.

OK, I won't argue on the utility, there might be cases. But can you really present a real-world case where the changes that you're introducing get useful?

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

PR Comment: https://git.openjdk.org/crac/pull/79#issuecomment-1584281791