Hi, I updated from JDK 17 to JDK 21 (`[jvm] jdk = ...
# general
m
Hi, I updated from JDK 17 to JDK 21 (
[jvm] jdk = "temurin:1.21"
in
pants.toml
) and now I'm seeing what looks like a deadlock during the compilation of my project. The last 8 lines of the log are "Compile xyz/foo.scala with scalac", but the compile never finishes, and the time counter goes up indefinitely. Any ideas? Happens with pants 2.26 and 2.27. Reverting to JDK 17 fixes the issue.
a
I'm no one important but i'm curious using the JDK with pants. you've got a pants.toml + BUILD i can use to replicate this?
if you don't get back to me i'll try https://github.com/pantsbuild/example-jvm
You'll need to disable nailgun to start. https://github.com/pantsbuild/pants/issues/20603
Copy code
[GLOBAL]
process_execution_local_enable_nailgun = false
and insure you are on a compatible scala version
Copy code
~/example-jvm (main) > git diff 3rdparty/jvm/org/scala-lang/BUILD pants.toml 
diff --git a/3rdparty/jvm/org/scala-lang/BUILD b/3rdparty/jvm/org/scala-lang/BUILD
index 05df923..ca80fe2 100644
--- a/3rdparty/jvm/org/scala-lang/BUILD
+++ b/3rdparty/jvm/org/scala-lang/BUILD
@@ -2,6 +2,6 @@ jvm_artifact(
     name="scala-library",
     group="org.scala-lang",
     artifact="scala-library",
-    version="2.13.8",
+    version="2.13.11",
     packages=["scala.**"],
 )
diff --git a/pants.toml b/pants.toml
index 61cc0e6..666b770 100644
--- a/pants.toml
+++ b/pants.toml
@@ -15,6 +15,8 @@ backend_packages = [
   "pants.backend.experimental.scala",
   "pants.backend.experimental.scala.lint.scalafmt",
 ]
+process_execution_local_enable_nailgun = false
+
 
 [source]
 # Pants supports many layouts of sources: from Maven/SBT style project-centric layouts, to
@@ -36,7 +38,7 @@ args = [
 # Configure the specific Scala version to use for a resolve. This version must match the version used for the
 # `jvm_artifact` target providing the scala-library runtime jar.
 [scala.version_for_resolve]
-jvm-default = "2.13.8"
+jvm-default = "2.13.11"
 
 [scalac]
 args = [
@@ -60,6 +62,7 @@ jvm-default = "acyclic"
 force_add_siblings_as_dependencies = false
 
 [jvm]
+jdk = "temurin:1.21"
 # Configure remote debugging options that will be used with `test --debug`.
 debug_args = [
   "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005",
h
Can you run with
--keep-sandboxes=always
and look inside the sandbox that doesn’t finish (all the sandbox locations are logged to the console)
the
__run.sh
should contain the command that deadlocks
a
I was able to replicate it and the actual sandbox for nailgun doesn't have a __run.sh.
m
@adorable-psychiatrist-59834 glad you managed to replicate it. otherwise, the repo is https://gitlab.com/jberkel/digero
a
yeah I bet it's just nailgun. try disabling it?
m
yes, it does work with nailgun disabled.
is nailgun really that important with more recent JVMs, anyway?
a
meta has archived it. https://github.com/facebookarchive/nailgun . that means it's dead. and the version that ran on my local system with jdk 21 was actually the martiansoftware version which is even older.
m
ok, I'll keep it disabled then. it's resulted in a ton of hung processes anyway on my system. perhaps the pants docs should be updated, or the default changed to opt-in
@adorable-psychiatrist-59834 thanks for your help!
a
The PRs and issues have already been filed. It's the only reason I was able to help. Take care.
h
Thanks for helping out @adorable-psychiatrist-59834 !
For context, we’ve been discussing what could replace nailgun, and the answer appears to be “nothing”… grrr
JVM startup time improves from version to version, but it’s still a perf drag. I think other tools try not to have many short-lived JVM processes, and we may have to do the same.
a
There havent been any parties interested in taking up the mantle on it? I'd do it rn if I was at a Java shop
m
I'm happy to help with smaller tasks, such as updating docs or moving the PR forward
On my MacBook the change is not too noticeable, but the CI build time went from ~12 mins to ~40 mins after disabling nailgun.
h
Yeah, not totally surprising
I think the future is long-running single-purpose JVM processes, e.g., a compiler daemon
m