Self-started bloop server doesn't start

[kubukoz]

Version(s)

0.1.0, x86 mac binary downloaded from releases tab.

Describe the bug

scala-cli bloop start fails every time. However, trying to compile some sources successfully starts bloop.

Stack trace

java.lang.Exception: Server didn't start
  scala.build.blooprifle.internal.Operations$.$anonfun$startServer$2(Operations.scala:153)
  scala.build.blooprifle.BloopRifleLogger.$anonfun$runnable$1(BloopRifleLogger.scala:12)
  java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
  java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
  java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  java.lang.Thread.run(Thread.java:833)
  com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:597)
  com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:194)

To Reproduce

1. Install scala-cli
2. scala-cli bloop start
3. profit

Expected behaviour
A server starts just like when running a build :)

[alexarchambault]

I didn't check the Scala CLI sources yet, but it seems scala-cli bloop start tries to use the system JVM to start Bloop. Locally, with Java 11 as system JVM, it says:

$ java -version
openjdk version "11.0.9.1" 2020-11-04
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)

$ scala-cli bloop start -v -v -v -v
…
Error: VM option 'UseZGC' is experimental and must be enabled via -XX:+UnlockExperimentalVMOptions.
Error: The unlock option must precede 'UseZGC'.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
…

while the following works for me:

$ eval "$(cs java --env --jvm temurin:17)"
$ java -version
openjdk version "17" 2021-09-14
OpenJDK Runtime Environment Temurin-17+35 (build 17+35)
OpenJDK 64-Bit Server VM Temurin-17+35 (build 17+35, mixed mode, sharing)

$ scala-cli bloop start
Bloop server started.

I guess we should ensure that our JVM 17 is used by default by scala-cli bloop start too (as is the case when the other commands start Bloop).

@kubukoz What does java -version says on your system?

[kubukoz]

openjdk version "11.0.11" 2021-04-20 LTS
OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)

Ideally JAVA_HOME or whatever is in the PATH of the scala-cli binary would be used, this way I can scope the usage of a JVM 17 for scala-cli's usage only.

[keynmol]

I'm having the same problem on Apple M1.

And I agree with @kubukoz - I already run Java 17 natively built for arm64, and I wish scala-cli would just use that.

velvetbaldmime@Antons-Air /v/f/m/d/T/tmp.plBHFF7i> java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment Temurin-17.0.2+8 (build 17.0.2+8)
OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (build 17.0.2+8, mixed mode)

velvetbaldmime@Antons-Air /v/f/m/d/T/tmp.plBHFF7i> scala-cli --version
0.1.0
velvetbaldmime@Antons-Air /v/f/m/d/T/tmp.plBHFF7i> scala-cli test.scala
Bloop daemon status: not running
Starting Bloop 1.4.19 at /Users/velvetbaldmime/Library/Caches/ScalaCli/bloop/daemon using JVM /Users/velvetbaldmime/Library/Caches/Coursier/arc/https/github.com/adoptium/temurin17-binaries/releases/download/jdk-17%252B35/OpenJDK17-jdk_x64_mac_hotspot_17_35.tar.gz/jdk-17+35/Contents/Home/bin/java
Error: java.lang.Exception: Server didn't start
For more details, please see '/private/var/folders/my/drt5584s2w59ncgxgxpq7v040000gn/T/tmp.plBHFF7i/.scala-build/stacktraces/1643998345-954539311384192108.log

Currently I can't find a way to use 0.1.0 so I dropped it down to 0.0.9

It's particularly important on M1 because I don't want compilation to run through emulator - and scala-cli will see os.arch as x86 if the binary is running under rosetta.

[alexarchambault]

@keynmol When using standard commands, --bloop-jvm should work, so something like this should run fine on M1:

$ scala-cli --bloop-jvm system test.scala

[alexarchambault]

Seems we need to handle the architecture more carefully though… (and also default to the system JVM when it's at least Java 17)

[SethTisue]

Related: coursier/coursier#2335

[keynmol]

@alexarchambault nope, seems like the same issue:

velvetbaldmime@Antons-Air /v/f/m/d/T/tmp.YhCQZV6k [1]> scala-cli --bloop-jvm system test.scala
Bloop daemon status: not running
Starting Bloop 1.4.19 at /Users/velvetbaldmime/Library/Caches/ScalaCli/bloop/daemon using JVM /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java
Error: java.lang.Exception: Server didn't start
For more details, please see '/private/var/folders/my/drt5584s2w59ncgxgxpq7v040000gn/T/tmp.YhCQZV6k/.scala-build/stacktraces/1644836015-15645112221190994336.log'

[alexarchambault]

@keynmol At least it tries to use your JVM 😅

Can you run the same command with -v -v -v -v, and paste the output here?

[keynmol]

Haha, you are right! I didn't notice and was too quick to post a rebuttal :P

After a lot of jars:

Checking for a running Bloop server at /Users/velvetbaldmime/Library/Caches/ScalaCli/bloop/daemon ...
Attempting to connect to Bloop server /Users/velvetbaldmime/Library/Caches/ScalaCli/bloop/daemon ...
Connection attempt result: None
Error occurred during initialization of VM
Multiple garbage collectors selected
Exception in thread "main" java.lang.Exception: Server didn't start
	at scala.build.blooprifle.internal.Operations$.$anonfun$startServer$2(Operations.scala:153)
	at scala.build.blooprifle.BloopRifleLogger.$anonfun$runnable$1(BloopRifleLogger.scala:12)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.lang.Thread.run(Thread.java:833)
	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:597)
	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:194)

which led me to my custom bloop config in ~/.bloop/bloop.json:

...
"javaOptions": ["-Xmx4G", "-XX:+UseShenandoahGC"]
...

After I removed that option it ran fine.

I feel like when using "system" bloop scala-cli should respect user's GC settings.

[kubukoz]

--bloop-jvm system works for me, but it'd obviously be great if it wasn't required. Can scala-cli just check if there's a JDK17+ compatible jvm on its PATH and use just that?