use ProcessHandleinstead of graalvm substitutions

[oyvindberg]

Hey!

I'm trying to use bloop-rifle with GraalVM Native Image version graalvm-community:21.0.2, upgrading from the venerable 22.3.1. (confusingly, 21 is newer than 22)

There are a few changes, not all of them trivial to fix.

At some point I had things building, but failing at runtime like this (in a native image):

Exception in thread "main" java.lang.NoClassDefFoundError: com.oracle.svm.core.posix.headers.Signal
        at libdaemonjvm.internal.IsRunning.isRunning(IsRunning.java:16)
        at libdaemonjvm.internal.LockProcess$Default.isRunning(LockProcess.scala:15)
        at libdaemonjvm.client.Connect$.$anonfun$tryConnect$3(Connect.scala:34)
        at libdaemonjvm.client.Connect$.$anonfun$tryConnect$3$adapted(Connect.scala:33)
        at scala.Option.flatMap(Option.scala:283)
        at libdaemonjvm.client.Connect$.ifFiles$1(Connect.scala:33)
        at libdaemonjvm.client.Connect$.tryConnect(Connect.scala:44)
        at libdaemonjvm.client.Connect$.tryConnect(Connect.scala:13)
        at bloop.rifle.internal.Operations$.check(Operations.scala:82)

So it seems handling of the org.graalvm.nativeimage:svm dependency has changed, you're clearly not supposed to have it on the classpath at NI build time. You get a bunch of warnings like this:

Error: Class-path entry file:///Users/oyvind/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/graalvm/compiler/compiler/23.1.2/compiler-23.1.2.jar contains class org.graalvm.util.json.JSONParserException. This class is part of the image builder itself (in jrt:/jdk.internal.vm.compiler) and must not be passed via -cp. This can be caused by a fat-jar that illegally includes svm.jar (or graal-sdk.jar) due to its build-time dependency on it. As a workaround, -H:+AllowDeprecatedBuilderClassesOnImageClasspath allows turning this error into a warning. Note that this option is deprecated and will be removed in a future version.

Accepting it on the class path still doesn't make it work.

I see you've set it as a compile-time dependency in this project, maybe some breakage downstream also plays into this.

I'm sure there is a migration path somehow, but it's really incredibly hard to navigate this GraalVM landscape. Basically no docs, outdated google results.

So I did the easy thing and looked at the usage of svm in this project to see if I could remove it, and bingo. Java has APIs for working with pids now, in the form of ProcessHandle.

Preliminary testing shows that it works the same as before for me with Native Image.

[oyvindberg]

Note that this change likely means we could inline/remove the whole LockProcess trait, as well as change Int to Long. However, I choose to maintain bincompat instead and just do the minimum here

[oyvindberg]

note that this interface doesnt distinguish "no process with that pid" from "there is a process with that pid but it's not alive".

I wonder if there is a practical usecase for forcefully destroying the latter?

[tgodzik]

@alexarchambault what do you say about merging it, I see I have the same issue building locally when doing scalacenter/bloop#2355

We could fork it and release under scala center if Alexandre doesn't have time to look at it

[oyvindberg]

Thanks, I was waiting for this issue to show up for you as well :)

I shipped a vendored version of libdaemon-jvm with this patch for bleep 0.0.4, and it seems to work well.

However, I've been observing some failures to take down running bloop servers on windows. It can be related to any number of updates done at the same time (I haven't investigated), but it could be beneficial for you to build a native-image and verify that it still works well.

[tgodzik]

However, I've been observing some failures to take down running bloop servers on windows. It can be related to any number of updates done at the same time (I haven't investigated), but it could be beneficial for you to build a native-image and verify that it still works well.

Ach, do you mean with this patch or before it also?

[oyvindberg]

After. But I bumped all dependencies at the same time, including bloop, bloop-rifle, graalvm. So I cannot really say if it's related, though it does seem "close" to this change, codepath-wise

[tgodzik]

@alexarchambault do you mind if we fork into scalameta? That's probably the org I have most power in 😅

Or into coursier if you feel it's better.

[tgodzik]

Btw. for now I moved the repo into scala center org, hopefully this alright.

I merged your PR there https://github.com/scalacenter/libdaemon-jvm and will do some testing on windows