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

[Radim Vansa]

On Mon, 12 Jun 2023 12:09:59 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> The native FileDescriptor is not employed in this scenario, the native descriptor detection is done by JVM, that code is mostly unchanged.

I am not talking about the native *detection*, but rather about this 'minimal descriptor'. That's the part that has to know about FD types, and moving that to native does not make it any simpler.

> There should be no major drawback. Can you see something?

Let's keep the test with FileReader please. I hate removing tested scenarios; the outcome could change (accompanied with a comment) but it's rare where the behaviour does not make sense after the refactoring.

> I think rebasing https://github.com/openjdk/crac/pull/69 on top of this would benefit the implementations of the policies, it will make them cleaner and more roboust. E.g. policy implementaiton in File can also prevent access to FileDescriptor with CLOSE policy, during small time window between the point FD is closed, but checkpoint is not started yet.

The way you made `getPath` abstract, expecting the owner of FD to know it has several effects:
- You'd need to update every use of FD rather than having this in one place. 
- Some information (flags, offsets) could not be reproduced reliably, would be complicated or would have to be based on defaults, rather than the actual value. E.g. logical offset of reading differs from physical offset, there's buffering in place (in libc) - I ran into something like this in https://github.com/openjdk/crac/pull/69/files#diff-ac18cee51b4abf767b1ad66d127afe6e609aaef2e66349032ce23635efa6457aR59 (that's why the tested content is past 1MB - I don't remember what was the actual size of the buffer).

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

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