I am running fortify static code scan.
main\Src>sourceanalyzer -64 -Xmx6500m -b project -scan -f project.fpr
The JDK is 1.8
java -version
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
After 20 hours, I got PermGen OOM error
[error]: Unexpected exception: java.lang.OutOfMemoryError: PermGen space
^Cendering results 99% [====================]
According to a lot of resource, PermGen is obsolete in Java8.
Any Ideas?
There is also the option to increase PermGen space
Increase permgen space
-XX:MaxPermSize=128m
There is also the option to enable garbage collection on PermGen space
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
Nevertheless you should check with HP whether it is actually needed to increase PermGen space, it could also be a bug in the software. PermGen space out of memory errors are often caused by memory leaks.
Fortify uses it's own JRE (look under [Fortify Install Root]\jre and [Fortify Install Root]\jre64).
If you use -debug-verbose -logfile Project_Scan.txt you can see if there are issues the scanning engine is having with memory pressure anywhere since it dumps memory usage every so often.
Be sure you are using the latest version of Fortify. If your scan is taking 20 hours, it could be that the latest version addresses the speed and memory issues. The latest is 4.20.
To speed up the scan, have you looked at the Parallel Analysis Mode? This was introduced in 4.00 and you can read about it in the User Guide, Appendix B.
I did some heavy memory tuning with the translation cycle at one point and the following worked well. It should also work for the scan cycle. Please note that this was an extreme memory usage case and this is not the best for all Fortify usage.
-XX:MaxPermSize=256m -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68
You can / should use JConsole to watch the process.
I think in Java 8 the PermGen space has been completely replaced with Metaspace. The JVM options
-XX:PermSize and -XX:MaxPermSize
have been replaced by
-XX:MetaSpaceSize and -XX:MaxMetaspaceSize respectively.
Try that.
Related
There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 1048576 bytes for AllocateHeap
# An error report file with more information is saved as:
# C:\jboss-eap-services-6.4.4\bin\hs_err_pid6632.log
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m;
support was removed in 8.0
With the problem above, I'm trying to start the jboss server. I tried some steps and I could not find the right solution.
Please use the following setting to allocate the memory for the permanent location -Xms1024m -Xmx1024m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:-UseGCOverheadLimit
You can try to increase eclipse memory, you can do this in le eclipse.ini file (near eclipse executable file) or in the command line arguments :
-Xms256m
-Xmx16348m
It is JBoss (not Eclipse) that is crashing. So increasing Eclipse's memory is futile! (It might make things worse, in fact.)
The second thing to note is that you are running out of space in a native allocation request, so increasing the regular heap's size will not help. Options like the following will probably NOT help! (They might make things worse, in fact.)
-Xms1024m -Xmx1024m -XX:-UseGCOverheadLimit # USELESS
The third thing to note is that your JVM doesn't have a PermGen space, so fiddling with the PermGen size via
-XX:PermSize=512m -XX:MaxPermSize=512m # USELESS
is futile. (That is what Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 is saying.)
So what is the real problem?
Well you are running a 64-bit JRE, so it is not an architectural problem. (On a 32-bit JRE, the JVM's address space has hard limits ...)
In fact, it is a problem outside of the JVM itself. Basically, the JVM has asked the OS for more memory, and the OS has said "Nope!". I can thing of two possible explanations:
There may be a per-process "ulimit" in place, that is restricting the process size. Your JVM has requested beyond that limit.
The OS may have run out of virtual address space or mappable virtual memory. The former is unlikely. The latter typically arises because your OS doesn't have enough RAM and/or swap space. This can also happen is you are running within a virtual machine that is ... less than generous endowed with memory resources.
Now it appears that this may be happening when the JVM is trying to grow the Java heap. But either way, the problem is not the size of the Java heap.
I have some memory leak issue in my web app which is deployed in tomcat. To find the root cause I enabled the HeapDumpOnOutOfMemory error by setting:
-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat/logs
and the memory settings in the tomcat is:
-Xms256m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m
When the out of memory issue happened, I see
java.lang.OutOfMemoryError: Java heap space
on the tomcat log file, but the .hprof file is not generated. Am I missing some settings here?
As #beny23 wrote you should use -XX:+HeapDumpOnOutOfMemoryError
and as is stated here:
The -XX:HeapDumpOnOutOfMemoryError Option This option tells the Java
HotSpot VM to generate a heap dump when an allocation from the Java
heap or the permanent generation cannot be satisfied. There is no
overhead in running with this option, so it can be useful for
production systems where the OutOfMemoryError exception takes a long
time to surface.
Check also your Java version since this option was introduced in 1.4.2 update 12, 5.0 update 7.
I am using Windows 8 Pro 64 bit, Java 1.6 64 bit. I am trying to start Weblogic with following memory args (setDomainEnv.cmd):
set USER_MEM_ARGS=-Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=1024m
But i'm getting an error:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
Those mermory args are required to deploy the app, so i can't lower it (physical mermory installed - 8 GB).
Combined with -Xmx512M use -d64 to make sure you're running 64-bit VM. On a 64-bit machine I thought for sure I was running 64-bit virtual machine, but no. After installing 64-bit Java the -d64 option works and -Xmx allows much larger memory sizes.
java -d64 -Xmx512M mypackage.Test
Please see the below link for more solutions...
Could not reserve enough space for object heap
I am running weblogic 81. I had min=1024 and max =1024m with 4gb or RAM. 64bit processor and 32 bit java. I tried to increase the min/max value, it did not work. So, I changed the min/max to 512m and 1024m respectively. Thn it started to work.
When i installed for first time, the SOA environment developed mode, needed to do that:set JAVA_OPTIONS=%JAVA_OPTIONS% set DEFAULT_MEM_ARGS=-Xms512m -Xmx768m set PORT_MEM_ARGS=-Xms768m -Xmx1536m But over time, it shows me the same error and tube to make the following change: set JAVA_OPTIONS=%JAVA_OPTIONS% set DEFAULT_MEM_ARGS=-Xms512m -Xmx512m set PORT_MEM_ARGS=-Xms512m -Xmx512m But I'm still not sure why this happens.
I want to increase heap java to avoid this error message
I have windows 7 64bit with java version
C:\Users\Rasha>java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode)
java -Xms1024m -Xmx1024m -XX:PermSize=512m -XX:MaxPermSize=512m
Error occurred during initialization of VM
Could not reserve enough space for object
Could not create the Java virtual machine.
Although I have already 6 Gigabyte memory, how to made the system to recognize them?
any suggestions for this problem?
Use the 64 bit JVM. The 32 bit JVM cannot allocate much beyond 1.5 gb (eg right about where you are having difficulties) due to need for contiguous address space. I KNOW you are using the 32 bit JVM because it says "Client VM" above, and there is no "Client VM" for 64 bit.
thank you, I found the problem, I have multi version of java which conflicts the configuration
the solution is to remove all versions and install the java 64 bit version and the space is allocated well
thank you every body
I am running server with 256MB RAM. Maximum heap size I can allocate for Java is 110MB. When I add those param to JAVA_OPTS I can run java -version. Problem is that I can not run Tomcat with these parameters. Maximum heap size for Tomcat to run is 40MB. I do not know why I can not allocate more memory?
Of course I get error:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
Set CATALINA_OPTS to -Xmx110m, JAVA_OPTS. I suppose you could set both, to be sure.
The Xmx flag may be ignored when you run the java executable with the -version flag. This depends on how you pass the version flag. The following are the results on my machine with 2GB RAM:
Version flag passed before Xmx
C:\Users\Reynolds>java -version -Xmx10240M
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)
which is weird considering that 10G is beyond the max addressable limit on memory in a 32-bit environment.
Version flag passed after Xmx
C:\Users\Reynolds>java -Xmx10240M -version
Invalid maximum heap size: -Xmx10240M
The specified size exceeds the maximum representable size.
Could not create the Java virtual machine.
C:\Users\Reynolds>java -Xmx1524M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
which is closer to reality.
You might want to verify how much contiguous memory is available to Java in reality, using the second approach, and then decide on an optimal value for the maximum heap size.
The error message suggests you do not have enough free RAM try closing other applications and seeing if you can allocate a larger heap then. You may need more RAM I am afraid.