The .jvmopts file prohibits sbt even starting

[propensive]

I have no idea how specific this problem is, but when trying to start sbt from a newly-cloned shapeless directory, I get the error message,

Conflicting collector combinations in option list; please refer to the release notes for the combinations allowed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

The problem appears to be the .jvmopts file, particularly the line,

-XX:+UseG1GC

removing which allows sbt to start. Someone more familiar with JVM options could undoubtedly give more insight.

Other potentially relevant details:

> java -version
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
> uname -a
Linux 4.12.1-gentoo #4 SMP Sat Jul 15 17:46:49 BST 2017 x86_64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz GenuineIntel GNU/Linux

[milessabin]

I can reproduce this if I have a conflicting GC configuration specified in the environment in JAVA_OPTS,

miles@tarski:shapeless (master)% export JAVA_OPTS=-XX:+UseParallelGC
miles@tarski:shapeless (master)% sbt
Conflicting collector combinations in option list; please refer to the release notes for the combinations allowed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
miles@tarski:shapeless (master)%

Do you have something similar? I don't think it's particularly good practice to have these sorts of configuration hanging around in your environment, but OTOH it's not great that it stops SBT from starting up.

@joroKr21 you added the garbage first collection option to .jvmopts ... do you have any strong feelings about this?

[propensive]

Ah, thanks for the diagnosis! I have a bunch of stuff in $JAVA_OPTS. The "bug" probably lies more with the sbt runner script, in that case (assuming that's where .jvmopts is read), would should know the compatibility of all the various flags it presumes to combine into the same java invocation... It seems a bit unreasonable to expect that, though.

If @joroKr21 has no strong feelings, I'd suggest we merge my PR, otherwise just document it. It didn't take me too long to work out that sbt worked everywhere apart from the shapeless directory, and it didn't take long to guess which of the files was causing the problem, given the origin of the error message.

[milessabin]

These days .jvmopts is handled by the SBT launcher directly.

Personally I think your environment is broken. Any Java application which specifies different GC options from the ones you've picked will break in the same way.

For me the question is: are the benefits of specifying the g1 collector big enough for us to not care about a broken environment.

[propensive]

I can certainly accept that! If I recall correctly, I added the JVM_OPTS to fix a particular sbt build problem anyway, at a time when I wasn't aware of .jvmopts.

[joroKr21]

I don't have strong feelings about the GC. I added it because it was the first combination of options that fixed some spurious errors due to scala/bug#10552 but now I am almost certain that the stack option is the important one. That means that the memory requirements could probably be reduced to their previous levels.