I've run into a situation where install4j v4.2.8 runs fine and generates installers when using the GUI and when invoking install4jc from the command line, but fails with the following message when invoked via the install4j ant task:
install4j: compilation failed. Reason: java.lang.OutOfMemoryError: PermGen space
Using visualvm, I determined that the ant task is forking a separate JVM, which appears to fail when the PermGen usage hits about 88MB. The install4j ant task docs don't say anything about being able to pass VM args (such as -XX:MaxPermSize=256MB) through to the forked JVM, but I'm wondering if that or something similar would be an option.
You can adjust the VM parameters for the command line compiler in the file [install4j installation directory]/bin/install4j.vmoptions. Just increase the -Xmx value there and add the -XX:MaxPermSize VM parameter.
Prior to install4j 5.0.7, there was a bug related to includes of relative files in .vmoptions files. For these older versions, remove the include to install4j.vmoptions in install4jc.vmoptions and add the VM parameters directly there.
Related
I tried setting the sys.version variable from the build script where I am also setting the other user created compiler variable while running the ./install4jc command for building the installer. It is not setting the variable and it's saying giving a warning message: [WARNING] The variable 'sys.version' is a system variable that cannot be overridden.
The requirement is the version number should not be hard coded in the Installer file. Please advise how can I achieve that.
On the command line, specify the version with
-r [version]
Ant task as well as gradle and maven plugins have corresponding parameters.
I've been working on a small set of command line programs in Scala. While
developing I used SBT, and tested the program with run within the console. At
this point the programs had a fast startup time (when re-run after initial compilation); nearly instant, even
with additional dependencies.
Now that I'm trying to actually utilize them on my system outside of sbt, the speeds have noticeable lag. I'm looking for ways to
reduce this, since the nature of these utilities requires little to no delay.
The best speeds I've achieved so far has been through utilizing Drip. I include all dependencies in a lib directory by utilizing Pack and then run by executing a shell script like this:
#!/bin/sh
SCRIPT=$(readlink -f "$0")
SCRIPT_PATH=$(dirname "$SCRIPT")
PROG_HOME=`cd "$SCRIPT_PATH/../" && pwd`
CLASSPATH_SUFFIX=""
# Path separator used in EXTRA_CLASSPATH
PSEP=":"
exec drip \
-cp "${PROG_HOME}/lib/*${CLASSPATH_SUFFIX}" \ # Add lib directory to classpath
TagWorkspace "$#" # TagWorkspace is the main class
This is still noticeably slower then invoking run from within SBT.
I'm curious as to why SBT is able to startup the application so much faster, and if there is someway for me to levarage its strategy, or SBT itself, even if that means keeping a long living process around to actually run a command through.
Unless you have forking turned on for your run task, this is likely due to VM startup time. When you run from inside an active SBT session, you have an already initialized VM pointing at your classes - all SBT needs to do is create a new ClassLoader and point it at your build output directory. This bypasses all of the other (not insignificant) stuff that happens when you fire up a new VM.
Have you tried using the client VM to start your utility from the command line? Sadly, this isn't an option with 64-bit Java, since Oracle apparently doesn't want to support it, but if you're using a 32-bit VM, try adding the -client argument to the list that you give the VM from the command line.
If you are using a 64-bit VM, some googling will find you some unofficial forks of OpenJDK that have the client VM re-enabled. It's really just a #define in the JVM build itself - it works fine once it's been compiled in.
The only slowness I have is launching SBT. Running a hello-word Scala app with java (no Drip) version 1.8 on a 7381 bogomips CPU takes only 0.2 seconds.
If you're not in that magnitude, I suspect your application startup requires loading thousands of classes, and creating instances of them.
I installed sbt 0.13.1 from http://www.scala-sbt.org through the msi package.
When I try to start it through a command prompt i get this error
C:\Users\megatron>sbt
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
So I followed the recommendation in the setup notes
and added/changed this in the C:\Program Files (x86)\sbt\conf\sbtconfig.txt file.
-Xmx1536M
-XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=128m
-Xss1M
-XX:+CMSClassUnloadingEnabled
This doesn't help either and I still get the same error.
It seems you should not have white space characters in the installation path to sbt. You have one in Program Files. Try installing into a different location.
[EDITED, see below]
workaround for me: first try rebooting Windows
I've seen this problem in the past on Windows. Now again with sbt-0.13.5 on Windows 8.1.
By default the sbt installer installs to C:/Program Files (x86)/sbt. I also tried C:/sbt and got the same error while my system appeared to have almost 2G RAM still available. Next, without changing anything else I rebooted and sbt worked from C:/sbt. Then I re-installed using the default C:/Program Files (x86)/sbt path and still sbt works. Of course rebooting isn't a solution.
See related answer. The problem may be that when you are running sbt you are picking up 32-bit JRE (probably via C:/Windows/System32) instead of 64-bit in your path (check with java -version). Apparently the problem is then that although there may be enough memory overall it might not be contiguous that the JVM is requesting.
I am executing a groovy script with run-script and running out of memory. I have found instructions for configuring ones GRAILS_OPTS on the command line, however I am not on the command line. How do I make sure that the grails command prompt in GGTS(Eclipse) is configured to provide enough memory for a script?
Just to be clear - this is a problem with run-script from the groovy command prompt inside The GGTS 3.4.0 release (Eclipse).
You can try setting the JAVA_OPTS system variable instead of the specific GRAILS_OPTS variable. It seems to work for me.
e.g
JAVA_OPTS="-Xms1024m -Xmx2024m -XX:MaxPermSize=512m"
For reference from grails docs - http://grails.org/doc/2.3.x/guide/commandLine.html, search for JAVA_OPTS. Depending on what OS you are on the syntax may be different.
When I try to run
processBuilder = new ProcessBuilder("scala", "-classpath", CLASSPATH, CLASSNAME);
process = processBuilder.start;
process.waitFor;
within an Scala application on Eclipse Helios IDE, it yields the
java.io.IOException: Cannot run program "scala": CreateProcess error=2, The system cannot find the file specified.
I've already configured the Windows system environment variable Path and scala runs OK on Windows command line. I've also added the variable Path into Eclipse run configuration.
I suspect the problem here is that you need to pass scala.bat, not scala. To narrow down the problem, you should try running other programs, to see what you can or cannot run.