Is there a way to increase the memory during assembly (the plugin)? I notice that adding more memory to sbt through SBT_OPTS does't really help. I suspect that assembly is forking a separate JVM that doesn't inherit the JVM configurations from sbt.
Here is the error:
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space
Here is what I tried without much luck:
javaOptions in assembly += "-Xmx2g"
I suspect that assembly is forking a separate JVM that doesn't inherit the JVM configurations from sbt.
I'm the author of sbt-assembly. assembly does not fork a separate JVM.
You can see the code here and check - https://github.com/sbt/sbt-assembly/blob/0.13.0/src/main/scala/sbtassembly/Assembly.scala#L239-L246
Make sure to export SBT_OPTS. Mine is "-Xmx2G -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=2G -Xss2M"
I met the same issue before, Please do it as below for windows. The issue could be gone.
set SBT_OPTS="-Xmx2G"
sbt assembly
You can increase heap size by using below mentioned command in linux environment:-
sbt -J-Xms2048m -J-Xmx2048m assembly
Related
I am working on a Scala project that has been in existence for a few years but is new to me. My task is to upgrade it from Scala 2.9.3 to 2.11.7, along with its dependencies. I have gotten past the errors and warnings, but I cannot get the project to compile successfully in SBT. I always get a StackOverflowError in pretty much the same place. The stacktrace looks like this, but details vary with the Xss setting (currently 4M, but have tried as high as 24M):
java.lang.StackOverflowError
at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698)
at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5395)
at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5422)
at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5369)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5373)
at scala.tools.nsc.typechecker.Typers$Typer.typedQualifier(Typers.scala:5471)
at scala.tools.nsc.typechecker.Typers$Typer.typedQualifier(Typers.scala:5479)
at scala.tools.nsc.transform.Erasure$Eraser.adaptMember(Erasure.scala:644)
at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698)
at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5395)
at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5422)
SBT_OPTS looks like this:
-Xmx2G -Xss4M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
I can 'make' the project successfully in Intellij, and others can pull my changes from GitHub and compile the project in sbt, so the issue seems to be local to my machine (a recent quad-core Macbook Pro with 16GB RAM). Other Scala/sbt projects compile successfully for me on this machine.
Here are other relevant details:
Scala version: 2.11.7
Java version: java version "1.8.0_66" (build 1.8.0_66-b17)
sbt version: 0.13.7 (have also tried 0.13.9)
I have completely rebuilt the ivy2 cache and cleared the lib_managed directory. The version of the scala-compiler.jar is the same as is used on at least one machine that can 'sbt compile' the code successfully. I did a clean reinstall of sbt (via brew remove sbt, manual removal of ~/.sbt directory, then brew install sbt).
I have not tried to isolate the line of source code being compiled when the error occurs. I have assumed it would be more productive to look for a configuration issue or dependency conflict somewhere.
Any suggestions for further troubleshooting will be appreciated.
[Added...] It may be helpful to add that, as an experiment, I downloaded the Scala language source code from https://github.com/scala/scala and got the following very similar error trying to sbt compile it:
java.lang.StackOverflowError
at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.outerValue(ExplicitOuter.scala:229)
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:441)
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:352)
at scala.reflect.internal.Trees$class.itransform(Trees.scala:1345)
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:44)
at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.scala$reflect$internal$Trees$UnderConstructionTransformer$$super$transform(ExplicitOuter.scala:219)
at scala.reflect.internal.Trees$UnderConstructionTransformer$class.transform(Trees.scala:1693)
at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.transform(ExplicitOuter.scala:291)
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:459)
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:352)
at scala.reflect.internal.Trees$class.itransform(Trees.scala:1347)
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
Here is something interesting. From this post I found out about launching sbt with a -d flag for debugging info. Got the following output:
Kevins-MacBook-Pro:scala kdoherty$ sbt -d
[process_args] java_version = '1.8.0_66'
# Executing command line:
java
-Xmx2G
-Xss4M
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-Xmx384m
-Xss512k
-XX:+UseCompressedOops
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
-jar
/usr/local/Cellar/sbt/0.13.9/libexec/sbt-launch.jar
So somewhere my SBT_OPTS settings are being overridden (by defaults, I guess). Now I need to find where those defaults are coming from.
I figured it out. Once I knew that the -d flag would tell me what settings SBT was actually using, I saw that the values in my SBT_OPTS environment variable were being clobbered by other, lower settings. Where were those coming from? From my JAVA_OPTS env variable! I should have noticed them sooner, but now I know I can keep those Java options as they are and override them by adding the SBT-specific settings to my /usr/local/etc/sbtopts file, using the somewhat awkward format of
-J-Xmx2G
-J-Xss2M
Using the values shown I was able to run sbt compile successfully on my project.
I hope someone finds this useful.
Add to the bottom of /usr/local/etc/sbtopts
-J-Xmx4G
-J-Xss4M
All set.
I just added -Xss in my Intellij sbt properties and the issue is resolved.
Intellij SBT properties
Relevant parts from the output of sbt -h:
# jvm options and output control
JAVA_OPTS environment variable, if unset uses ""
.jvmopts if this file exists in the current directory, its contents
are appended to JAVA_OPTS
SBT_OPTS environment variable, if unset uses ""
.sbtopts if this file exists in the current directory, its contents
are prepended to the runner args
Thus, in my case I solved the problem by creating a file .sbtopts with content
-J-Xmx4G
-J-Xss4M
in the project directory.
Note: Running sbt -d shows what settings have been used, for instance:
$ sbt -d
[addSbt] arg = '-debug'
[process_args] java_version = '8'
# Executing command line:
java
-Xms1024m
-XX:ReservedCodeCacheSize=128m
-XX:MaxMetaspaceSize=256m
-Xmx2G
-Xss2M
-jar
/path/to/sbt-launch.jar
-debug
I was unable to get this to work via the provided answers. build.sbt settings and the sbtopts file both failed to solve this error for me. What I had to do was run sbt with the -mem flag, for example:
sbt -mem 2048 compile
and now my projects built. If using IntelliJ you can also go to
Preferences > Build, Execution, Deployment > Build Tools > sbt
and set Maximum heap size, MB to whatever target you need.
I discovered the SBT_OPT setting in the bin/sbt file of my sbt install was affecting the memory values set in my projects build.sbt
updating the existing -Xss value in this file from 1M to 8M raised the memory size of the Scalac stack to a point I stopped getting StackOverflow exceptions in the sbt-invoked compiler. This seemed odd because the sbt documented approach to setting stack size in the compiler is to do this is with the -J-Xss setting.
Sbt doesn't seem to actually enable you to set the compiler's stack memory. While a build.sbt accepts the following configuration as a valid setting, it doesn't seem to apply the value in the compiler:
scalacOptions in ThisBuild ++= Seq(-J-Xss8M)
I suspect that is a bug or non-implemented functionality
I too run into this problem recently and I discovered a working solution for it with sbt 1.3.13.
create a .sbtopts file under project root
add -J-Xss100M (or any thread stack size you think suitable) to the .sbtopts file
There are multiple Correct Answers already. But what worked for me is below,
// Created and Added a File: .jvmopts in the Project Root Folder with below Parameters.
-Xms3022m
-Xmx4048m
-Xss124m
-XX:MaxPermSize=4048m
-XX:MaxMetaspaceSize=512m
-XX:+CMSClassUnloadingEnabled
-XX:ReservedCodeCacheSize=128m
how can i change jvm configuration i.e. heap and stack size in a Play framework2 application with Scala
activator run -Xms1G -Xmx2G -server
i have tried this command but jconsole shows that heap size has not changed
please help me
These are Java switches; in Scala prefix them with -J, namely -J-Xms1G and -J-Xmx2G.
Edit
For setting such options in build.sbt you must enable a new jvm forking ,
fork in run := true
and specify the options for instance like this,
javaOptions in run ++= Seq("-Xms1G", "-Xmx2G")
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.
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
My application does large data arrays processing and needs more memory than JVM gives by default. I know in Java it's specified by "-Xmx" option. How do I set SBT up to use particular "-Xmx" value to run an application with "run" action?
For forked processes you should look at Build.scala
To modify the java options for forked processes you need to specify them in the Build.scala (or whatever you've named your build) like this:
val buildSettings = Defaults.defaultSettings ++ Seq(
//…
javaOptions += "-Xmx1G",
//…
)
This will give you the proper options without modifying JAVA_OPTS globally, and it will put custom JAVA_OPTS in an sbt generated start-script
For non forked processes it's most convenient to set the config via sbtopts or sbtconfig depending on your sbt version.
Since sbt 0.13.6 .sbtconfig is deprecated. Modify /usr/local/etc/sbtopts along these lines:
-J-Xms512M
-J-Xmx3536M
-J-Xss1M
-J-XX:+CMSClassUnloadingEnabled
-J-XX:+UseConcMarkSweepGC
-J-XX:MaxPermSize=724M
-J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
You can also create an .sbtopts file in the root of your SBT project using the same syntax as in the /usr/local/etc/sbtopts file. This makes the project self-contained.
Before sbt 0.13.6 you could set the options in .sbtconfig for non forked processes:
Check where sbt is:
$ which sbt
/usr/local/bin/sbt
Look at the contents:
$ cat /usr/local/bin/sbt
#!/bin/sh
test -f ~/.sbtconfig && . ~/.sbtconfig
exec java ${SBT_OPTS} -jar /usr/local/Cellar/sbt/0.12.1/libexec/sbt-launch.jar "$#"
Set the correct jvm options to prevent OOM (both regular and PermGen):
$ cat ~/.sbtconfig
SBT_OPTS="-Xms512M -Xmx3536M -Xss1M
-XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC -XX:MaxPermSize=724M"
If you want to set SBT_OPTS only for the current run of sbt you can use env SBT_OPTS=".." sbt as suggested by Googol Shan. Or you can use the option added in Sbt 12: sbt -mem 2048. This gets unwieldy for longer lists of options, but it might help if you have different projects with different needs.
Note that CMSClassUnloadingEnabled in concert with UseConcMarkSweepGC helps keep the PermGen space clean, but depending on what frameworks you use you might have an actual leak on PermGen, which eventually forces a restart.
In sbt version 12 onwards there is an option for this:
$sbt -mem 2048
If you run sbt on linux shell, you can use:
env JAVA_OPTS="-Xmx512m" sbt run
This is my usually used command to run my sbt project.
.sbtconfig is deprecated starting with SBT 0.13.6. Instead, I configured these options in /usr/local/etc/sbtopts in the following way:
-J-Xms512M
-J-Xmx3536M
-J-Xss1M
-J-XX:+CMSClassUnloadingEnabled
-J-XX:+UseConcMarkSweepGC
-J-XX:MaxPermSize=724M
-J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Try this:
class ForkRun(info: ProjectInfo) extends DefaultProject(info) {
override def fork = Some(new ForkScalaRun {
override def runJVMOptions = super.runJVMOptions ++ Seq("-Xmx512m")
override def scalaJars = Seq(buildLibraryJar.asFile, buildCompilerJar.asFile)
})
}
There's one way I know of. Set the environment variable JAVA_OPTS.
JAVA_OPTS='-Xmx512m'
I have not found a way to do this as a command parameter.
Use JAVA_OPTS for setting with environment variable.
Use -J-X options to sbt for individual options, e.g. -J-Xmx2048 -J-XX:MaxPermSize=512
Newer versions of sbt have a "-mem" option.
The javaOptions += "-XX:MaxPermSize=1024" in our build.sbt as referenced by #iwein above worked for us when we were seeing a java.lang.OutOfMemoryError thrown while running Specs2 tests through sbt.
The environment variable is _JAVA_OPTIONS, which needs to be set.
Once you set _JAVA_OPTIONS, and when you sbt, sbt will show the message using JAVA_OPTIONS and the values.
Alternatively you could set javaOption in the sbt or .scala file
e.g
javaOptions += "-Xmx1G"
From sbt shell you could run show javaOptions to see the values that are set.
sbt lets you list the JVM options you need to run your project on a file named
.jvmopts
in the root of your project.
then add the java options that you want
cat .jvmopts
-Xms512M
-Xmx4096M
-Xss2M
-XX:MaxMetaspaceSize=1024M
it is tested and works in windows 10
https://www.lagomframework.com/documentation/1.4.x/scala/JVMMemoryOnDev.html
javaOptions in Test += "-Xmx1G"
This sets the JVM options for tests. Works also with jvm forking (fork in Test := true).