I'm using Install4j 7.0.12.
Installation process finished well, but when I have tried to run uninstall, I'm getting error:
"The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firewall tool could block the execution."
I have disabled firewall and antivirus, but without any success. Is there any way how to specify maximum heap size when the installer/uninstaller is already build? What is default size of this java argument?
Related
Currently I am using NetBeans-8.1 in 32-bit Windows 10. I'm getting the following error:
java.lang.OutOfMemoryError: Java heap space.
I already changed the memory size to -Xmx1024m in netbeans.conf file, added environment variables -Xms1024m -Xmx1024m -XX:PermSize=64M -XX:MaxPermSize=256m but still getting same error. Are there any problems with NetBeans on 32-bit operating systems? My system has 4GB of RAM.
Make sure that you have correctly set the flags for NetBeans, otherwise it will not be recognized: NetBeans requires the -J prefix for arguments to the JVM.
So you need to use
-J-Xms1024m -J-Xmx1024m
Also you should be aware that Oracle states that Windows 32 bit is capable only of about 1.4GB - 1.6GB of heap. See http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit
You should increase the -Xmx value, which is the maximum amount of memory the JVM can allocate for the heap. See this answer for details about the flags.
For example, you could use -Xmx4G to allow it to use up to 4GB of memory on your system.
I am using a .fxbuild-script to build a JavaFX Application. I used Packaging-Format all to include its own runtime. Now I am wondering, how I can define any runtime parameters?
Since we noticed, that we had far more OutOfMemory Issuses within the deployed version than with the local development version, we were monitioring it with Visual VM and noticed, that the embedded JVM (by default?) is only configured to use 256MB of RAM. How can I increase the Maximum available RAM for the included JVM?
The Application is launched by an .exe file after beeing installed on the system.
Update:
The Answer of Roland is correct. I just made the mistake, that I added the <fx:platform>-Tag at the Bottom of the Ant script and not within the appropriate <fx:deploy>-Tag which results in that the <fx:platform>-Tag will be ignored and the JVM is configured to use 256 MB max RAM on 32-Bit and 1/4th of available RAM on 64-Bit.
Please read the Packaging Basics, especially chapter "5.8.2 Customizing JVM Setup".
Excerpt of what you need:
<fx:platform javafx="2.1+">
<fx:jvmarg value="-Xmx400m"/>
...
</fx:platform>
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.
We are using ImageMagick launched by a JBoss EJB by the way of im4Java, to produce image files. im4Java is an Java interface to imagemagick, launching external process with java.lang.ProcessBuilder. After few successfull runs, we are blocked by a :
java.io.IOException: Cannot run program "/usr/local/bin/convert": java.io.IOException: error=12, Cannot allocate memory
It seems not to be an ImageMagick issue, because if we launch the same process from command line, it runs perfectly. But more a Jboss memory allocation for an external process.
Any idea ?
Finally solved, but maybe not the best way. Indeed , we have used the solution of the overcommit_memory variable in Linux indicated by Ivan, and no problem any more. But we are not sure changing that this memory global settings would not affect the whole behavior of the system later, as it seems to allocate a lot more memory. Hopefully we do not run so often imagemagick from java code, so memory is released once imagemagick did his job.
I am using a 32bit WinXP with no upgrade in sight, is there a way to limit how much memory Eclipse allocates throughout the day? I am also running Weblogic 10 server in debug mode inside eclipse. After a few hours I have an 700mb STS.exe (eclipse) and 400mb java.exe (server). Is there at least a way to force a GC on eclipse?
Here are the settings i surrently use, which seem to me are not being observed.
-vm
C:\bea\jdk160_05\bin\javaw.exe
-showsplash
--launcher.XXMaxPermSize
128M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m -Xmx512m
-Dsun.lang.ClassLoader.allowArraySyntax=true
EDIT: here's the monster of a project: Eclipse and Firefox 4.
is there a way to limit how much memory Eclipse allocates throughout the day?
The values of -Xmx and -XX:MaxPermSize place an upper bound on the memory that the JVM will use.
Is there at least a way to force a GC on eclipse?
AFAIK, no. Even if there was, it probably wouldn't help. The JVM is unlikely to give the memory back to the operating system.
Here are the settings i currently use, which seem to me are not being observed.
Based on what you've said (memory usage 700Mb for eclipse.exe), I'd say the settings ARE being observed.
What can you do to get Eclipse to use less memory?
Trim the values of -Xmx and -XX:MaxPermSize. However, if you do this too much you are liable to make Eclipse sluggish ('cos it has to GC more frequently) and ultimately flakey ('cos it will run out of memory and things will start failing with OOMEs)
Get rid of superfluous plugins.
Switch to a "smaller" Eclipse (e.g. the "Classic" distro) ... though you'll lose some of the J2EE support that you are probably using.
Close projects.
Close files.
Restart Eclipse more often.
But the best solution is to upgrade your platform:
Buy some more memory for your PC / laptop. You can probably max it out for a couple of hundred dollars. It is worth it.
Switch the OS to Linux. In my experience, Linux is a much better platform for doing Java software development than Windows XP. It seems to do a much better job in terms of both memory and file system management. The performance difference on identical hardware is significant.
You can always set up your machine to dual boot, so that you can still run XP for other things.
The 700MB of OS level process usuage is consistent with your memory settings. Take 512m for heap + 128m for permgen space + a bit of overhead for the JVM itself.
You cannot force GC. If memory was releasable, JVM would release it. Note that you cannot simply look at OS level process usage as that represents the point where the JVM memory usage peaked. JVM never releases heap or permgen space once it expands to a certain size. It is simply too expensive and not really necessary. The allocated space is in virtual address space of the JVM process. It doesn't represent actual physical memory usage. As physical memory gets tight, the OS will agressively swap out to disk memory pages that haven't been used recently.
So... You need specialized memory analysis tools to get accurate representation of Eclipse memory usage.
If you are seeing a lot of disk activity when there shouldn't be any, the OS may be indeed out of physical memory and doing a lot of swapping. Try closing a few projects or restarting Eclipse. It only takes one plugin with a memory leak to consume all of your available memory.
I'm assuming that you are running BEA JRockit judging by the path to javaw.exe. Note that the -X... options are JVM-specific, so they may not work the same way for JRockit as in Sun's JVM. This link seems to indicate that you should be using
... -Xms:40m -Xmx:512m ...
But setting a heap size limit will only cause Eclipse to fail once it reaches the limit, so you won't solve the real problem. Forcing a GC usually doesn't help; any sane VM will GC periodically or when needed.
Having a 700Mb Eclipse sounds like your Eclipse is either processing large amounts of data, or it is leaking memory. JRockit seems to have a memory leak detector which may be able to give you a hint of where the problem lies.
The ini file memory settings won't help for the Virtual machine. Change VM arguments, as here
Eclipse is very thirsty. Limiting it is most likely to crash it. You really need a new computer.