Description of problem: Starting EAP 6.1.0.ER5 with 32bit Oracle JVM can result in Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Problem is that heap settings are too big. Current memmory settings that we ship are: -Xms1303M -Xmx1303M -XX:MaxPermSize=256M if PermSize param is removed it starts. Same problem occurs with domain mode where failure is not immediate but at starting servers, domain controller has lower memory settings. Version-Release number of selected component (if applicable): How reproducible: use 32but JDK7 and start EAP Steps to Reproduce: 1. 2. 3. Actual results: JVM crashes Expected results: EAP startss Additional info:
Which OS platform does it fail on?
In my case it is Windows 8 64bit, with 32bit oracle jdk7
It seems more like an JVM issue. I've made some experiments on Windows Server 2008 R2 (amd64) machine in our lab. JDKs: 1. Oracle JDK 64-bit java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) 2. Oracle JDK 32-bit java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing) initial state (values taken from windows task manager): Physical memory (MB) | - Total = 8181 | - Cached = 3508 | - Available = 5867 | - Free = 2374 Scenarios: a) start standalone.bat with default JVM options (-Xms1303M -Xmx1303M -XX:MaxPermSize=256M) b) start standalone.bat with doubled JVM options (-Xms2606M -Xmx2606M -XX:MaxPermSize=512M) a1) default java_opts & 64b jdk Server started without any exception. Physical memory (MB) | - Cached = 3485 | - Available = 5601 | - Free = 2131 a2) default java_opts & 32b jdk Server started without any exception. Physical memory (MB) | - Cached = 3486 | - Available = 5611 | - Free = 2147 b1) doubled java_opts & 64b jdk Server started without any exception. Physical memory (MB) | - Cached = 3485 | - Available = 5576 | - Free = 2107 b1) doubled java_opts & 32b jdk Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. You can use easy test to determine, whether jvm should be able to start with given parametrs eg.: W:\pkremens>java -Xms1303M -Xmx1303M -XX:MaxPermSize=256 -version java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode) W:\pkremens>java -Xms2606M -Xmx2606M -XX:MaxPermSize=500 -version Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
Updated the doc text with the workaround.
pkremens checked 'java -Xms2606M -Xmx2606M -version' command without -XX:MaxPermSize=500 on testing machine used in comment 3 64b - OK 32b - Error occurred during initialization of VM
Those parameters will never start on a 32-bit JVM. The defaults at -Xms1303m -Xmx1303m, not -Xms2606m -Xmx2606m. So, this is not a valid test.
In our environment (Windows Server 2008 R2 (amd64) & Oracle JDK 32-bit) we are able to run both commands without any error > java -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -version > java -Xms1303M -Xmx1303M -version Tomaz approved in description that removing MaxPermSize argument solves this issue, so it is good to have this documented.
This should go in AS first so that EAP will inherit the fix, right? Brian, can you please reassign accordingly? Thanks!
Andy when documenting the removal of PermGen there should be extra warning about domain mode, where we ship(domain.xml) with 256M for permgen for both servers that start, but removing it still results in failure as removal has to be done also in host.xml (on what it defaults if not present in domain.xml) Also it looks like this problem only occurs on Windows8 and on Windows Server 2012. (They share same kernel) I need to reproduce this on clean machines which i will have done later today.
Permaine, AIUI this is not an upstream problem, as upstream does not use such a large heap as it's default. EAP uses its own heap configuration settings, different from upstream and tailored for different use cases. EAP should validate those every release. These settings shouldn't be coming from upstream, either in part or as a whole. Tomaz, if there is an appropriate change to make to upstream, please file a WildFly JIRA.
I have tested parameters on Windows Server 2008r2 64bit Windows Server 2012 64bit Windows 8 64bit (two different laptops) Windows 7 64bit And it fails only on Windows 8, even tried with different versions of jdk7. Strange thing is that Windows Server 2012 works given that it shares kernel with windows 8. The bizarre thing I found is that if run it with -Xms1303M -Xmx1303M -XX:MaxPermSize=126M (maximum amount I could run it with) it works in some cases and fails in some. so in 6 runs it would fail 2-3 times but work in other cases.
Added draft Release Notes text.
Adding NEEDINFO flag for verification of the Release Notes text above (since I forgot to when I initially added it)
Removed NEEDINFO and set Doc Text flag from inclusion in 6.1.0 Release Notes.
*for inclusion
I wonder you tested java -Xms1303M -Xmx1303M -XX:MaxPermSize=256 -version or java -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -version I don't think -XX:MaxPermSize=256 is valid, it's probably just ignored. With my Windows 7 64bit and JDK 32bit 1.7.0_21-b11, "java -Xms1303M -Xmx1303M -XX:MaxPermSize=187M -version" passed, but "java -Xms1303M -Xmx1303M -XX:MaxPermSize=188M -version" failed. So, not setting -XX:MaxPermSize is probably best hack so far. (In reply to pkremens from comment #3) > It seems more like an JVM issue. I've made some experiments on Windows > Server 2008 R2 (amd64) machine in our lab. > > JDKs: > 1. Oracle JDK 64-bit > java version "1.7.0_21" > Java(TM) SE Runtime Environment (build 1.7.0_21-b11) > Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) > > 2. Oracle JDK 32-bit > java version "1.7.0_21" > Java(TM) SE Runtime Environment (build 1.7.0_21-b11) > Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing) > > initial state (values taken from windows task manager): > Physical memory (MB) > | - Total = 8181 > | - Cached = 3508 > | - Available = 5867 > | - Free = 2374 > > Scenarios: > a) start standalone.bat with default JVM options (-Xms1303M -Xmx1303M > -XX:MaxPermSize=256M) > b) start standalone.bat with doubled JVM options (-Xms2606M -Xmx2606M > -XX:MaxPermSize=512M) > > a1) default java_opts & 64b jdk > Server started without any exception. > Physical memory (MB) > | - Cached = 3485 > | - Available = 5601 > | - Free = 2131 > > a2) default java_opts & 32b jdk > Server started without any exception. > Physical memory (MB) > | - Cached = 3486 > | - Available = 5611 > | - Free = 2147 > > b1) doubled java_opts & 64b jdk > Server started without any exception. > Physical memory (MB) > | - Cached = 3485 > | - Available = 5576 > | - Free = 2107 > > b1) doubled java_opts & 32b jdk > Error occurred during initialization of VM > Could not reserve enough space for object heap > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > You can use easy test to determine, whether jvm should be able to start with > given parametrs eg.: > W:\pkremens>java -Xms1303M -Xmx1303M -XX:MaxPermSize=256 -version > java version "1.7.0_21" > Java(TM) SE Runtime Environment (build 1.7.0_21-b11) > Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode) > > W:\pkremens>java -Xms2606M -Xmx2606M -XX:MaxPermSize=500 -version > Error occurred during initialization of VM > Could not reserve enough space for object heap > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit.
Hi Yukunix, I've tested > java -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -version
I would like to add what users on community forum confirmed that same problem can be reproduced on 64-bit Windows 7, 32-bit JDK 7u25, 8 gig RAM, JBoss EAP 6.1.
Yes it also works without PermGen attribute. so just having -Xmx1g -Xms1G also works in 6 scenarios I tested.
https://github.com/jbossas/jboss-eap/pull/440 There are several reason why PR 440 shouldn't be merged: - devel_ack is - - we are changing defaults because of unsupported platform - this is fix for Windows 8 which is not supported in EAP -- see comment 14 whre Tomaz confirms it's just issue in Windows 8 - there is inconsistency between JVM option for Windows and other platforms -- "-Xms1G -Xmx1G" vs. "-Xms1303M -Xmx1303M -XX:MaxPermSize=256M" Changing qa_ack to -. Please revert PR 440. I think this issue should be addressed in WildFly and this BZ should be closed as Won't fix.
Rostislav, WildFly does not have this issue, as it ships with much much lower memory settings. current setting in wildfly: set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M" It is issue only in EAP. I did change Devel_ack back to + but it was not recorded, setting it again.
qa_ack was granted before we knew it's Windows 8 only problem - Comment 14. I would prefer to document this as known issue - we are changing defaults because of unsupported platform from final product PoV and there is inconsistency between JVM option for Windows and other platforms. NOTE: I don't think 75% of devs are on Windows 8 64bit with 32bit JVM.
Hi, I can't speak for all users of EAP, but I can speak based on our usage statistics for JBoss Developer Studio. Afaic this issue is *not* limited to Windows 8, but to Windows JVM's. Thus it also affects Windows XP and Windows 7 users. That is ~73% of our users, of which half are using JDK 32-bit. Even if it is *just* Windows 8 then the number of users here exceeds Mac OSX users and is ~65% of what total Linux installation base is. Here are the numbers from last monday: Windows 327573 Linux 3955 Mac 1495 Of those 2559 was Windows 8 users. Thus please don't under estimate the bad impact it has by the defaults preventing startup of EAP.
p.s. we had similar issue with Windows XP in the past - yes, it is not a production supported runtime but it is a developer supported one thus it is relevant to fix it.
Does this pm_ack+ and devel_ack+ means it will be fixed in next update to EAP 6.1 ?
Those acks are for EAP 6.3.
https://github.com/jbossas/jboss-eap/pull/925
Verified on EAP 6.3.0.ER4.