RFR: 8364281: Reduce JNI usage in Linux attach provider

[Philippe Marschall]

On Sat, 9 Aug 2025 19:50:14 GMT, Philippe Marschall <duke at openjdk.org> wrote:

> Reduce the usage of JNI in the Linux attach provider by making more use of the `Path` API.
> 
> - use the `Path` API to read file permissions
> - use the `Path` API  to write to and read from Unix domain sockets
> - use JDK internal APIs to access the euid and eguid
> 
> After this the sole usage of JNI in the Linux attach provider will be to send a signal using `kill`.
> 
> I ran the tier1 and serviceability test suites and they both pass. I verified I can attach to and attach using a locally built JDK. I didn't do any Docker related tests.
> 
> I split the changes into two commits:
> 
> - The first commit ports the permission check code more or less directly from C to Java using integer based checks.
> - The second commit changes the permission check code to use higher level Java abstractions (`UserPrincipal`, `Set`, ...)
> 
> I hope this makes it easier to review and verify the changes preserve the semantics.
> 
> To the best of my knowledge `uid_t` is an unsigned 32 bit integer. `VM#geteuid()` returns it as `long`, unsigned. However `UnixUserPrincipals#fromUid` expects an `int`, I believe casting is the correct way to convert in this case.
> 
> I tried to keep unrelated changes to `VirtualMachineImpl` to a minimum. I did however replace all usages of `java.io.File` with `java.nio.file.Path` and made two methods `static`. We could get rid of the `socket_path` instance variable if we instead use `socket_address` to flag a disconnect.
> 
> Ultimately the same changes can be applied to the macOS an AIX implementations.

> Thanks for the work so far, nice to get rid of JNI. 🙂
> 
> There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) related to this that could make sense to run manually (https://bugs.openjdk.org/browse/JDK-8341518, it's failing in Oracle's CI but I have not been able to reproduce the failure myself, discussed a bit in #21331 too).
> 
> I'll see if I can find time to check out this change locally and run some tests, otherwise, feel free to run it yourself.

TestJcmdWithSideCar fails with

    java.nio.file.NoSuchFileException: /proc/7/cwd/.attach_pid7
	  at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	  at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	  at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	  at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:856)
	  at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:106)
	  at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
	  at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
	  at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	  at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)

I must confess I'm quite confused by this as this ultimately means that

    Files.createFile(path).toRealPath()

Fails with NoSuchFileException on the Path returned by createFile.

Is there a better way to run TestJcmdWithSideCar other than removing it from ProblemList?

As for the issue on Oralce CI, is there I way I ran run TestJcmdWithSideCar on a feature branch of mine on Oralce CI without opening a PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/26712#issuecomment-3185276826