[crac] RFR: Move more FD tracking to java layer [v2]
Anton Kozlov
akozlov at openjdk.org
Fri Jun 9 16:33:49 UTC 2023
> The PR develops the idea of file descriptors tracking in Java started in #43. In general, that PR had two purposes. First, it provides CheckpointExceptions in terms that are clear for Java developers, improving the experience of developing for CRac. So if a FileDescriptor causes an exception, it's possible to look at the heap dump and find references to the offending FD, or to look at the stack trace when FD was created. And second, Java FD tracking is independent of the platform, so that was the first step to bring CRaC to non-Linux platforms, but that is a bit longer road.
>
> We can eliminate manual heap inspection, and this is proposed in this PR. A FileDescriptor does not exist on its own but it is owned by some higher-level Java object implementation. So an object can "claim" a FileDescriptor and define how and if to report the FD to the user. E.g. Socket can describe the its port and address without deep inspection of the process internals. Turns out, Socket.toString() provides enough information (but the reporting can be extended later if required).
>
>
> Suppressed: jdk.crac.impl.CheckpointOpenSocketException: Socket[addr=localhost/127.0.0.1,port=39957,localport=41464]
> at java.base/java.net.SocketImpl$SocketResource.lambda$beforeCheckpoint$0(SocketImpl.java:123)
> at java.base/jdk.crac.Core.lambda$checkpointRestore1$0(Core.java:128)
> ... 7 more
>
>
> A FileDescriptor is claiming itself in case there is a bug in JDK that no higher-level object is claiming the FD. FD provides just a very short description just for debugging. With stack trace to FD (which is a very nice debugging aid!), that should be enough to find the containing object and implement claiming.
>
> I believe this overlaps with #69, which at first glance would benefit a lot from being able to define policies in the domain objects. I'll comment on this after a closer look at the other PR.
Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits:
- Merge remote-tracking branch 'jdk/crac/crac' into newfd
- Fix a bug in classPathMatching
- Remove misleading UnreachableSocket
- Merge remote-tracking branch 'jdk/crac/crac' into newfd
- Cleanup
- Remove AcceptingSocketResource
Does not need to exist
- Cleanup and extend FileDescriptor nativeDesc
- Update
- Workaround for the blocking context
- Claim closing socket
- ... and 85 more: https://git.openjdk.org/crac/compare/a282698d...bcfd07a4
-------------
Changes: https://git.openjdk.org/crac/pull/79/files
Webrev: https://webrevs.openjdk.org/?repo=crac&pr=79&range=01
Stats: 724 lines in 22 files changed: 370 ins; 277 del; 77 mod
Patch: https://git.openjdk.org/crac/pull/79.diff
Fetch: git fetch https://git.openjdk.org/crac.git pull/79/head:pull/79
PR: https://git.openjdk.org/crac/pull/79
More information about the crac-dev
mailing list