We Keep Coding

java.lang.OutOfMemoryError: PermGen space with Mule mmc and Tomcat 7

We're getting the java.lang.OutOfMemoryError: PermGen space in our environment:
Windows Server 2012 R2 64-bit 8GB RAM
JRE 1.7 u80
Tomcat 7.0.73
ActiveMQ 5.9.0
Mule runtime 3.5.4
Mule management console 3.5.3 deployed over Tomcat 7
webservice war file that uses PhantomJS 1.9.8 deployed over Tomcat 7
setenv.bat file under Tomcat/bin folder with below settings:
setenv JAVA_OPTS=-Xms512M -Xmx2048m -XX:PermSize=1024m -XX:MaxPermSize=1024m
Also, registry settings for JVM as under tomcat7w.exe:
initial memory pool: 256 MB
maximum memory pool: 1536 MB
Could any explain which takes precedence, setenv.bat file settings or tomcat7w.exe settings for memory pool?
Also, what should be the ideal settings for this environment as these settings are currently running on windows server 2008 R2 64-bit with 16GB RAM?

It depends how you start your Tomcat, whether you start it as windows service or via the catalina.bat.
You can check the following post: [question]: Configure Tomcat as a service (no catalina.bat)

As #GKGeorgiev says, it will depend on how you are launching Tomcat.
I suggest you do a little experiment:
Change the max heap size settings in setenv.bat to a value that is small enough to trigger an immediate failure.
Start Tomcat.
If this causes the behavior to change (e.g. to fail immediately) you know that the setenv.bat file is the one that is taking precedence. If not, then not.
Then do the experiment the other way around; i.e. change the equivalent registry setting and see if that has any effect.
Also, check the Tomcat documentation that applies to the launch method you are using.
Finally, it would be advisable to upgrade to Java 8. Java 7 is well beyond its EOL, and running a Java version that is not getting security patches is risky.

for ideal memory setting
Xms and Xmx should be equal ,
Inside catalina.bat JAVA_OPTS variable your should define the memory parameters.
while starting this will take the precedence.
take care

"Picked up _JAVA_OPTIONS" when no such environment variable exists

This issue pertains specifically to Minecraft, but it is affecting all Java programs that run on my computer.
It would seem that something is forcibly setting a _JAVA_OPTIONS environment variable. When I run my server, I have specified to allocate 4 GB of RAM to it with
-Xms4G -Xmx4G
in the startup batch file. However, when the server runs, It prints "Picked up _JAVA_OPTIONS: -Xms2048M -Xmx2048M" to the console, only allocating 2 GB. I have checked my system settings and there is no _JAVA_OPTIONS environment variable in the list. I do not want to add one, since that will also try to allocate 4 GB to Minecraft itself, which is unnecessary and uses too much RAM.
What could be causing this variable to be set? (Windows 8.1 64-bit, Java 7)

You probably have a Razer device. Their god-forsaken software secretly adds _JAVA_OPTIONS, but only when launching games, so you won't even see it from CMD. Ideally uninstall the software, and maybe splash some holy water on your PC. Failing that, you can probably get by with shutting down Synapse and restarting minecraft.exe
Found (eventually) here: http://www.minecraftforum.net/forums/support/unmodified-minecraft-client/2183431-_java_options-picked-up-without-existing#reply

This error occurs actually when you run an android application after compiling a java program. Eclipse uses java's compiler to execute android application. So run your android application as an android application. Just right click on project and click on run as->android application instead of run configurations.

Jenkins is failing to start a 32-bit JVM for a job

I'm running Jenkins 1.557. I have a job that I need to be built with a 32-bit version of JDK 1.6_u45. I have that version properly configured in my job's JDK setting. However, when I attempt to run the job, I get the following error.
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
If I switch the job's JDK setting to a 64-bit version, the JVM is able to be created and it runs as normal. The server has 8GB of RAM available, and I've even attempted to pass in a string parameters of JAVA_OPTS=-Xms512m -Xmx1024m & ANT_OPTS=-Xms512m -Xmx1024m to the build, but to no avail.
Please note this is not a duplicate of Could not reserve enough space for object heap. If I attempt to build the project at a regular command line (Windows environment variable JAVA_HOME pointing to the same 32-bit JDK installation as the Jenkins attempt), the project builds. This is seemingly a Jenkins specific issue.
My guess is somewhere in Jenkins (or in some hidden Jenkins config file) the JVM heap size is being set too large for the 32-bit JVM, but I can't seem to pinpoint where that is being set. I've checked the jenkins.xml in JENKINS_HOME but the heap size is not being set in the arguments tag.

Answer
Try a lower max heap (-Xmx) value, such as -Xmx900m or -Xmx800m and see if this solves the problem.
From my experience, Jenkins honors your ANT_OPTS environment variable and does not mess with it. I use Jenkins Freestyle Jobs that launch Ant personally and I've always set ANT_OPTS, MAVEN_OPTS, ... separate from Jenkins and it has never changed anything. Make
Better yet, start with a much lower value like -Xmx512m (I would use ANT_OPTS, which Ant uses for this and not bother with JAVA_OPTS). If it still fails to initialize, OK, then maybe I'll entertain that Jenkins is doing something. If not, there's your answer.
At the root, I believe this is the same problem as the duplicate question you linked, it just reproduces in more limited circumstances. More details below.
Background
Just yesterday, on a coworker's machine I saw -Xmx1024m fail in a standard command window with the same message with 32-bit Java. Just because it works in one situation does not mean it will always work.
On Windows, 2GB max address space per 32-bit process severely limits the maximum heap size you can set in Java since Java requires that the entire object heap be allocated in one contiguous block. Especially in modern versions of Windows that use ASLR (Address Space Layout Randomization), you simply can't be guaranteed large heap sizes for 32-bit processes...even 1024m can sometimes be too large since in Java the heap must be contiguous. Picture a horizontal line from 0 to 2GB, and then a [1GB] chunk taking up 50% of the width. Now insert 50 random DLLs into that 2GB horizontal line in random locations...now try to fit your [1GB] chunk without hitting a dot.
Not exact, here's my poor man's diagram of the address space:
0 [________________________________________] 2GB
_ is unallocated, available, | is occupied
Now with DLLs:
0 [__|_______|___________________|___|_____] 2GB
You need to fit this (including edges) into that address space:
[__________________]
Maybe it barely squeeks in...now let's add one more blip
0 [__|_______|_____________|_____|___|_____] 2GB
[__________________]
Suddenly it won't fit.
It's possible there is an extra DLL being loaded by Jenkins that is fragmenting your address space just slightly more so that 1024m fails under Jenkins but not in a standalone window. Since your goal is to run it under Jenkins, I don't see a clear solution to that other than to reduce your max heap size since your goal is to run a 32-bit build. In the Windows XP days, it was common to get -Xmx1300m or so to work, but apparently even -Xmx1024m is a stretch on Windows 7 and Windows 8 (in some cases, anyway). It really seems like the most likely case is...you're trying to set the heap too big for 32-bit.
Verification
If this really isn't the problem, or if you don't believe me, you can verify what Java memory settings your 64-bit version of the build is actually using (namely because it has to actually start to see the settings while it's running). Since your other build is failing to even start, I'm not sure you can use this method there. Whether Jenkins is doing something or not, whether you tell your job to use a 32-bit JDK or 64-bit JDK, if it's reading ANT_OPTS it should be the getting the same end result -Xmx value from that environment variable for both builds (the one that works (64-bit), and the one that fails). You can use a utility included with the JDK to do this called jconsole. From the bin directory of your JDK installation, run 'jconsole'. Or, if you have %JAVA_HOME%\bin in your PATH, you should be able to directly launch jconsole.
This will start a graphical client allowing you to select from any Process IDs (PIDs) that have a JVM running in them, this list should be pretty short in most cases. Select your Ant process and connect to it. Switch to the VM Information tab, and you will see the heap settings and other VM arguments that the JVM is using.
You will see a "VM Arguments" section, which should include your -Xms and -Xmx settings, but also "Maximum Heap Size", which will probably display in kilobytes.
Bonus knowledge, but not directly relevant since you've stated Java 6. If this were Java 7 or later, you could use:
jcmd
to obtain the PID, then:
jcmd <PID> VM.arguments
to see the VM arguments for the Java process with the PID you specified. jcmd being another utility that comes with the JDK. This, for me at least, displays the raw bytes value so you'll need to translate in your head. (it won't show -Xmx1024m it will show -XX:MaxHeapSize=1073741824)

“Error occurred during initialization of VM; Could not reserve enough space for object heap” using -Xmx3G

First of all, I have a box with 8gb of ram, so I doubt total memory is the issue.
This application is running fine on machines with 6gb or less.
I am trying to reserve 3GB of space using -Xmx3G under "VM Arguments" in Run Configurations in Eclipse.
Every time I try to reserve more than 1500mb, I get this error:
“Error occurred during initialization of VM; Could not reserve enough space for object heap” using -Xmx3G
What is going on here?

Could it be that you're using a 32-bit jvm on that machine?

Here is how to fix it:
Go to Start->Control Panel->System->Advanced(tab)->Environment Variables->System
Variables->New:
Variable name: _JAVA_OPTIONS
Variable value: -Xmx512M
Variable name: Path
Variable value: ;C:\Program Files\Java\jre6\bin;F:\JDK\bin;
Change this to your appropriate path.

This is actually not an Eclipse-specific issue; it's a general
Java-on-Windows issue. It's because of how the JVM allocates memory on
Windows; it insists on allocating a contiguous chunk of memory, which
often Windows can't provide, even if there are enough separate chunks to
satisfy the allocation request.
There are utilities that will try to help Windows "defrag" its memory,
which would, in theory, help this situation; but I've not really tried
them in earnest so can't speak to their effectiveness.
One thing that I've heard sometimes that might help is to reboot Windows
and, before starting any other apps, launch the Java app that needs the
big chunk of memory. If you're lucky, Windows won't have fragmented its
memory space yet and Java will get the contiguous block that is asks for.
Somewhere out on the interwebs there are more technical explanations and
analyses of this issue, but I don't have any references handy.
I did find this, though, which looks helpful: https://stackoverflow.com/a/497757/639520

First the JRE of 32bits can't use more ~1.5Gb of ram. So if you want more, use a 64bits JRE.
Second, When a new JVM starts, this sum the -Xmx property of the all JVM that are running, and check if there is enough memory left on the system to run at their own -Xmx, if is not enough then the error occurs.

I was using Liferay with Tomcat server from eclipse IDE.
I was stuck with this same error on click on server start up.
Double click on server from eclipse.
it open up Server Overview page. Updated memory arguments from -Xmx1024m -XX:MaxPermSize=256m to -Xmx512m -XX:MaxPermSize=256m.
Then it was working for me.

Make sure that Eclipse is actually running the same JVM you think it's running. If you use java in your web browser ever, you likely have a 32-bit version floating around too that might be taking precedence if it installed or updated lately.
To be absolutely sure, I recommend adding these two lines to your eclipse.ini file at the top:
-vm
C:/Java/jdk1.6.0_27/bin
...where on my machine C:/Java/jdk1.6.0_27/bin where the JVM I know is 64-bit is located. Be sure to have the bin folder there.
(As a bonus, on Windows 7, this also allows you to actually "pin the tab" which is why I had to do this for my own usage)

This is the issue of Heap size. Edit your .bat (Batch file). It might be showing Heap size 1024. Change it to 512 Then it should work.

Just put # symbol in front of org.gradle.jvmargs=-Xmx1536m in gradle.properties
# org.gradle.jvmargs=-Xmx1536m

I also had the same problem while using Eclipse which was 32 bit and the JVM used by it was 64 bit.
When I routed the Eclipse to 32 bit JVM then it worked

I know that i am a bit late, but here my answer comes:
I just installed the Java online Version from Oracle(not the offline 64-Bit one).
After having added the JAVA_HOME ENV variable, it just worked!
Hope I could help :)

Probably you are trying wrong options anyways.
I got a similar error with supporting error log:
Java HotSpot(TM) Client VM warning: ignoring option PermSize=32M; support was removed in 8.0
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=128M; support was removed in 8.0
Im my case, the software did not support java 8 yet(script was using old JVM arguments) but I had had java 8 by default.

One of the reason for this issue is no memory available for Tomcat to start. Try to delete the unwanted running software from windows and restart the eclipse and tomcat.

Solution is simple. No need to go deep into this issue.
If you are running on 64bit machine then follow below steps:
Unistall 32 bit java first (check in C:\Program Files (x86) for its existence)
Install the newer version JDK kit 64 bit (includes JRE)
Set the environment path (To avoid conflict error if you have two different 64bit JRE)
Check in command prompt by typing javac command.
Restart / Done
You can have two different Java installed but don't forgot to set path.

Please set JAVA_OPTS=-Xms256m -Xmx512m in environment variables, it should solve the issue, it worked for me.

Find out if you are using a 32bit version or 64bit version of Java. To know that use the command
java -version
The 3rd line of the output should give you if it 32bit or 64bit.
If it is 32bit uninstall and install a 64bit version.

VisualVM "not supported for this JVM" on all local applications?

I have already spent a long time to load and test my application, now I need to profile it. But unluckily, the VisualVM always says "not supported for this JVM" on my local applications?
The applications were started on the same JVM with VisualVM.

I found out that (at least under Windows) one can easily write small batch files to run VisualVM in combination with specific JVMs, which is important for me, since I have installed the 32bit JDK alongside with the 64bit JDK (I need both, so this is sensible for me).
I have created two batch files in the folder "S:\applications\visualvm\bin\":
run_32.bat:
#echo off
START "VisualVM 32" visualvm.exe --jdkhome "C:\Program Files (x86)\Java\jdk1.7.0_07"
run_64.bat:
#echo off
START "VisualVM 64" visualvm.exe --jdkhome "C:\Program Files\Java\jdk1.7.0_07"
Obviously, all paths may differ on your system, but the general idea should still work correctly (on all 64bit versions of Windows). The benefit is that I can use the 32bit batch file when I want to use VisualVM in combination with Java applications that run on the 32bit JVM, and so on for 64bit.
The "start" command has the only benefit that the batch file launches the application without waiting for it to finish, so the command prompt window closes immediately. This is not a feature of VisualVM, but of the Windows batch file interpreter.

In my case, even with the JVMs matching (both 64-Bit), the only way to get things working was sending the argument -Dcom.sun.management.jmxremote to the JVM to be monitored. That also works if you are having problems to connect via Java Mission Control (JMC).
According to JMX's documentation, this what the argument does:
Setting this property registered the Java VM platform's MBeans and published the Remote Method Invocation (RMI) connector via a private interface to allow JMX client applications to monitor a local Java platform, that is, a Java VM running on the same machine as the JMX client.
This was supposed to be enabled automatically, but for some reason it wasn't on my Linux.

VisualVM needs to be run with the same JVM - at least Java 6 with the same 32-bit/64-bit size - as the program to be profiled. (You also need to be the same user, but then this message does not apply).
I would be triple-check that it was the exact same JVM in your situation.

On Linux:
Make sure that your /etc/hosts correctly references the effective ip address of your "hostname"
It appears that a discrepancy here totally confuses the poor jvisualvm and its programmers.

I too got the same problem for local tomcat, I search for solutions for stackoverflow. after some serious debugging, I figured out that VisualGC don't have permissions to get GC informations from tool.jar file.
by links
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html#SECURITY
https://stackoverflow.com/a/42107355/3876619
I following steps to solve the issue
1) Create a permission file
vim /tmp/tools.policy
Add
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
save it
2) Now add /tmp/tools.policy to JVM startup parameters
-Djava.security.policy=/tmp/tools.policy
3) Run jvisualVm with sudo

An issue that I just found, thanks to the hint from #user3356656, is that if you start the program while your machine is on one IP, and then try to connect while it is on a different IP, it will fail.

I also met this issue. My case is that on linux, I started tomcat with tomcat_user but I run jvisualvm with root user. It works after I start tomcat with root user.

I was having the problem having of visualvm detect my local tomcat installation on Windows 7. I could connect manually, but then things like memory snapshots and visualgc plugin were not enabled. I confirmed that I was using same JVM version, temp file permissions, etc. Didn't work. Then I found that starting visualvm first, and then tomcat, solved the problem.

As you can see, you are running VisualVM on 32bit JVM
You don't need to unistall 32bit JVM. Just tell VisualVM to use tour 64bit JVM.
If you want to change it permanently, you can edit
in visualvm_13\etc\visualvm.conf and specify the path of jvm here

My problem was JVM optimizations - -XX:+PerfDisableSharedMem flag will break VisualGC. This is apparent if jps will not show your app in the listing.

I can reproduce next behaviour.
I have a java application with right-click menu item to open jvisualvm.
I'm running this java application as standalone setup from a bat file.
It means I modify %path% and other needed environment variables like JDK
accordingly to form my environment.
The BAT that starts application is marked running as non-admin. Environment points to a 64-bit JDK.
Then I start other java application as admin. VM lives from the to same 64-bit JDK-source.
Then I start jvisualvm from first app with the right click ie.as non-admin.
I can see the app in jvisualvm ‘Applications list’ but clickin ‘System properties’ gives error. Message is “Not supported for this JVM”.
JVM arguments are exposed.
Solution is like in some other previous comments:
Starting my right-click jvisualvm-starter as admin I can see also "system properties" .
Certainly if JDKs would be 32-bit and other 64-bit it would not work. been there.
I thought this notion needs to be added here.

In my case, the application was running with admin permissions. So, visualVM also need to be running as admin.

I have changed name to my Windows User and set it all lowercase, restarted my PC and it all works now.

For me, the reason is that I have run the "jstatd" with a different user with the JVM process. I have a special user in the linux to start the JVM thread(it is a tomcat), but I start the jstatd process with root. If you use root to run jps, you cannot see any information of the JVM threads belonging to other users. That is the trouble.
I killed the "jstatd" process started by root, su to the owner of the JVM process, and restart the "jstatd" process and everything wokrs fine now.