sbt ignoring the commandline options? (windows) - scala

I am running
sbt compile
for a compiling a program. I am getting the
OutOfMemoryError: Java heap space
Exception. Instead I tried
sbt compile -J-Xms4G -J-Xmx6G
But I don't see any difference in memory usage of the program, like ignoring the command-line options, and I get the same exception (and when crashing it is barely using 0.8GB).

Related

Why is idea_rt.jar required for Scala but not for Java in IntelliJ?

I am new to Scala but and am trying to figure out how it actually works in IntellJ.
I keep seeing a -javaagent being added called idea_rt.jar whenever I run even a simple hello world Scala application through IntelliJ:
/Users/ng.newbie/.sdkman/candidates/java/11.0.2-open/bin/java -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=53564:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -classpath /Users/ng.newbie/Documents/DETraining/target/scala-2.12/classes:/Users/ng.newbie/.sbt/boot/scala-2.12.15/lib/scala-library.jar com.tw.Test
I get some idea about why the file is required from here.
If its communicating with the console and the running process then why don't I see it being added when I run pure Java apps ?

Scala Compiler doesn't terminate (programmatically invoked)

I am programmatically compiling Scala code with this piece of code:
val compiler = new Global(settings, reporter)
val run = new compiler.Run
run compile sourceFiles.map(_.fullPath).toList
The 2.10 RC1 compiler works for like three minutes then crashes, whereas 2.10 infinitely does something (full CPU usage). When I invoke the compiler via SBT (rather than programmatically) it works fine and compiles within less than a minute.
The shortened output looks like this (verbose - and running three minutes between the first line and the error):
[loaded class file C:\Program Files\scala\lib\scala-library.jar(scala/collection/mutable/StringBuilder.class) in 3ms]
Scala 2.10 stable
No further output. 100% CPU usage of 1 Core.
Scala 2.10 RC1
With RC1 I get this error after approximately 3 minutes:
error:
while compiling: Foo.scala
during phase: typer
library version: version 2.10.0-RC1
compiler version: version 2.10.0-RC1
reconstructed args:
Next piece of output (and final output before my application crashes) is an OutOfMemoryError. I'm not sure whether its cause is the code itself or the compile error. Both options appear strange to me, as it compiles on the SBT console and a compiler error should not consume that much memory, should it?
uncaught exception during compilation: java.lang.OutOfMemoryError
[error] (run-main) java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
at scala.reflect.internal.Symbols$Symbol.createRefinementClassSymbol(Symbols.scala:1068)
at scala.reflect.internal.Symbols$Symbol.newRefinementClass(Symbols.scala:406)
at scala.reflect.internal.Types$class.refinedType(Types.scala:3504)
at scala.reflect.internal.SymbolTable.refinedType(SymbolTable.scala:12)
at scala.reflect.internal.Types$Type.narrow(Types.scala:459)
at scala.reflect.internal.Types$class.specializedBy$1(Types.scala:6125)
at scala.reflect.internal.Types$class.specializesSym(Types.scala:6129)
at scala.reflect.internal.SymbolTable.specializesSym(SymbolTable.scala:12)
at scala.reflect.internal.Types$$anonfun$thirdTry$1$2.apply(Types.scala:6021)
at scala.reflect.internal.Types$$anonfun$thirdTry$1$2.apply(Types.scala:6021)
at scala.collection.Iterator$class.forall(Iterator.scala:739)
at scala.collection.AbstractIterator.forall(Iterator.scala:1156)
at scala.collection.IterableLike$class.forall(IterableLike.scala:75)
at scala.reflect.internal.Scopes$Scope.forall(Scopes.scala:44)
at scala.reflect.internal.Types$class.thirdTry$1(Types.scala:6021)
at scala.reflect.internal.Types$class.secondTry$1(Types.scala:5982)
at scala.reflect.internal.Types$class.firstTry$1(Types.scala:5958)
at scala.reflect.internal.Types$class.isSubType2(Types.scala:6101)
at scala.reflect.internal.Types$class.isSubType(Types.scala:5710)
at scala.reflect.internal.SymbolTable.isSubType(SymbolTable.scala:12)
at scala.reflect.internal.Types$class.thirdTry$1(Types.scala:6043)
at scala.reflect.internal.Types$class.secondTry$1(Types.scala:5982)
at scala.reflect.internal.Types$class.firstTry$1(Types.scala:5958)
at scala.reflect.internal.Types$class.isSubType2(Types.scala:6101)
at scala.reflect.internal.Types$class.isSubType(Types.scala:5710)
at scala.reflect.internal.SymbolTable.isSubType(SymbolTable.scala:12)
at scala.reflect.internal.Types$class.scala$reflect$internal$Types$$specializesSym(Types.scala:6142)
at scala.reflect.internal.Types$class.specializedBy$1(Types.scala:6125)
at scala.reflect.internal.Types$class.specializesSym(Types.scala:6129)
at scala.reflect.internal.SymbolTable.specializesSym(SymbolTable.scala:12)
at scala.reflect.internal.Types$$anonfun$thirdTry$1$2.apply(Types.scala:6021)
at scala.reflect.internal.Types$$anonfun$thirdTry$1$2.apply(Types.scala:6021)
[trace] Stack trace suppressed: run 'last compile:run' for the full output.
java.lang.RuntimeException: Nonzero exit code: 1
at scala.sys.package$.error(package.scala:27)
I stumbled across Why am I getting OutOfMemoryError compilation error in Scala?. I am, however, not sure whether I'm actually simply lacking heap space for the compilation. There is no Maven involved, it's only Scala code and some JARs on the local build path.
I'm looking for the cause of the OutOfMemory error or a tweak to fix the error.
Using jvisualvm.exe (in the JDK) we found out that the compiler was indeed running low on memory. The GC was working too hard freeing memory, so it looked like an infinite loop (to be precise: happened when a symbol table's HashSet was enlarged).
Increasing the heap size to 2GB fixed the issue here.

How to fix NoSuchMethodError?

I use Scala 2.10.0RC1 and sbt 0.12.1.
What causes and how can I fix this runtime error (runs fine on 2.9.2)?
The exact error message is:
java.lang.NoSuchMethodError: scala.Predef$ArrowAssoc$.extension$$minus$greater(Ljava/lang/Object;Ljava/lang/Object;)Lscala/Tuple2;
You're running the code with the wrong Scala version. This can have several causes:
misconfiguration of the project with sbt – search for 2.9.2 in config files
stale cache used by sbt – sbt reboot
something else?
If you meticulously check all your sbt configuration files for 2.9.2 and then wipe out all caches, things should run better. Dependencies usually have a version number in the name of the jar file, so running a find on your system will likely point you to the ones you missed.

typesafe stack scala error

I am using http://typesafe.com/stack/ for the first time, and I created simple akka project. My scala version is 2.9.2 I get the following error.
[info] Done updating.
[info] Compiling 1 Scala source to /Users/hrishikeshparanjape/git-public/web-service/target/scala-2.9.2/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.9.2. Compiling...
sbt appears to be exiting abnormally.
The log file for this session is at /var/folders/26/hqgjyf0j7192hmjdsz17f3v80000gn/T/sbt2587622650679130928.log
java.lang.OutOfMemoryError: PermGen space
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at sbt.CompletionService$$anon$1.take(CompletionService.scala:29)
at sbt.Execute.next$1(Execute.scala:74)
at sbt.Execute.processAll(Execute.scala:77)
at sbt.Execute.runKeep(Execute.scala:57)
at sbt.EvaluateTask$.run$1(EvaluateTask.scala:109)
at sbt.EvaluateTask$.runTask(EvaluateTask.scala:124)
at sbt.Aggregation$$anonfun$7.apply(Aggregation.scala:87)
at sbt.Aggregation$$anonfun$7.apply(Aggregation.scala:85)
at sbt.EvaluateTask$.withStreams(EvaluateTask.scala:87)
at sbt.Aggregation$.runTasks(Aggregation.scala:85)
at sbt.Aggregation$$anonfun$applyDynamicTasks$1.apply(Aggregation.scala:141)
at sbt.Aggregation$$anonfun$applyDynamicTasks$1.apply(Aggregation.scala:136)
at sbt.Command$$anonfun$applyEffect$2$$anonfun$apply$3.apply(Command.scala:64)
at sbt.Command$$anonfun$applyEffect$2$$anonfun$apply$3.apply(Command.scala:64)
at sbt.Command$.process(Command.scala:92)
at sbt.MainLoop$$anonfun$next$1$$anonfun$apply$1.apply(Main.scala:121)
at sbt.MainLoop$$anonfun$next$1$$anonfun$apply$1.apply(Main.scala:121)
at sbt.State$$anon$1.process(State.scala:154)
at sbt.MainLoop$$anonfun$next$1.apply(Main.scala:121)
at sbt.MainLoop$$anonfun$next$1.apply(Main.scala:121)
at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
at sbt.MainLoop$.next(Main.scala:121)
at sbt.MainLoop$.run(Main.scala:114)
at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(Main.scala:103)
at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(Main.scala:100)
at sbt.Using.apply(Using.scala:25)
at sbt.MainLoop$.runWithNewLog(Main.scala:100)
at sbt.MainLoop$.runAndClearLast(Main.scala:83)
at sbt.MainLoop$.runLoggedLoop(Main.scala:67)
at sbt.MainLoop$.runLogged(Main.scala:60)
Error during sbt execution: java.lang.OutOfMemoryError: PermGen space
Please help.
Your project needs more memory to be executed (that's what the java.lang.OutOfMemoryError: PermGen space tells you). I have never used the typesafe stack, thus I don't know if it is possible to configure memory parameters directly.
But if you run Linux you can type
env JAVA_OPTS="-Xms512m -Xmx1024m -Xss1M -XX:MaxPermSize=512" <command>
where command is the command to execute your project (probably it is sbt). Of course, you can change the size of the parameters if you need more/less space.

How to prevent java.lang.OutOfMemoryError: PermGen space at Scala compilation?

I have noticed a strange behavior of my scala compiler. It occasionally throws an OutOfMemoryError when compiling a class. Here's the error message:
[info] Compiling 1 Scala source to /Users/gruetter/Workspaces/scala/helloscala/target/scala-2.9.0/test-classes...
java.lang.OutOfMemoryError: PermGen space
Error during sbt execution: java.lang.OutOfMemoryError: PermGen space
It only happens once in a while and the error is usually not thrown on the subsequent compile run. I use Scala 2.9.0 and compile via SBT.
Does anybody have a clue as to what might be the cause for this error? Thanks in advance for your insights.
I use HomeBrew to install sbt on OS X. It supports a SBT_OPTS argument which can be put in ~/.sbtconfig file with export SBT_OPTS=-XX:MaxPermSize=256M.
The cause for OutOfMemoryError: PermGen space is that it doesn't have enough permanent generation space :) If you are using Oracle JVM, you need to add the -XX:MaxPermSize=256M (or some other amount of space) argument to your sbt script. For other JVMs, look at their documentation.
I assumed you're using sbt 0.13.6 or higher. Create .sbtopts file in your sbt project's root with the following content:
-J-Xmx4G
-J-XX:MaxMetaspaceSize=1G
-J-XX:MaxPermSize=1G
-J-XX:+CMSClassUnloadingEnabled
MaxMetaspaceSize is for Java 8 whereas MaxPermSize is for Java 7. They are critical to prevent out of memory errors related either to permgen or metaspace exhaustion. Of course, consider adapting flag values or adding any other flags required.
More details and alternative approaches can be found in this blog post.
I had this issue, played around with it for 10 minutes looking at sites trying to change the memory size.
Turns out i resolved it by,
user-profile$ sbt
Then,
sbt-project-name 0.1> clean
This cleared it up for me.
It looks like a memory leak in SBT for me as in my case the program compiles and runs successfully for about 3-5 times before hitting the exception which is fixed by SBT restart.
The most adequate solution indeed seems to be -XX:MaxPermSize= JVM parameter as Alexey Romanov suggests or to restart SBT periodically if it helps.
But there is another interesting way: try switching to Java 8. AFAIK it doesn't use PermGen any more and is probably immune to this exception this way.
I still hope SBT authors will address this issue in future versions.
I am building with the Jenkins sbt plugin and had the same problems. They were resolved after copying the SBT_OPTS from the sbt file to the Jenkins job config's JVM flags.
Originally using a command like:
java -jar /path/to/sbt-launch.jar test
I got first OutOfMemoryError: PermGen space which I solved using -XX:MaxPermSize, and then OutOfMemoryError: Java heap space, to which -Xmx was the remedy.
So in my case, a command like this worked:
java -XX:MaxPermSize=256M -Xmx2048M -jar /path/to/sbt-launch.jar test
change following code block in sbt.sh file and save its working fine.
get_mem_opts () {
local mem=${1:-1536}
local perm=$(( $mem / 4 ))
(( $perm > 256 )) || perm=1024 //256 to 1024
(( $perm < 1024 )) || perm=2048 // 1024 to 2048
local codecache=$(( $perm / 2 ))
echo "-Xms${mem}m -Xmx${mem}m -XX:MaxPermSize=${perm}m -XX:ReservedCodeCacheSize=${codecache}m"
}
or
using terminal to export sbt config
export SBT_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=1024M -XX:MaxPermSize=2048M"
You can also add a .jvmopts file in the root folder of your project, and write inside the file the following:
-Xms1g
-Xmx4g