OpenJ9 tomcat won't start with high -Xmx heap option - java

I have a Spring app running in a Tomcat 9.0.6 on Linux 64. Because it needs a lot of memory, I would like to try the OpenJ9 JVM which is supposedly more efficient in that regard (current heap limit with Hotspot: -Xmx128G).
I installed the 64-bit adoptopenjdk-8-jdk-openj9:
/usr/lib/jvm/adoptopenjdk-8-jdk-openj9/bin/java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
Eclipse OpenJ9 VM (build openj9-0.14.2, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190521_315 (JIT enabled, AOT enable
OpenJ9 - 4b1df46fe
OMR - b56045d2
JCL - a8c217d402 based on jdk8u212-b04)
Starting the tomcat causes the following error:
This JVM package only includes the '-Xcompressedrefs' configuration. Please run the VM without specifying the '-Xnocompressedrefs' option or by specifying the '-Xcompressedrefs' option.
After I set this option I get the following error:
JVMJ9GC028E Option too large: '-Xmx'
JVMJ9VM015W Initialization error for library j9gc29(2): Failed to initialize
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Documentation isn't that clear, but I found this:
https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.vm.80.doc/docs/mm_gc_compressed_refs.html
Compressed references are used by default on a 64-bit IBM SDK when the value of -Xmx, which sets the maximum Java heap size, is in the correct range. Start of changes for service refresh 2 fix pack 10On AIX®, Linux and Windows systems, the default range is 0 - 57 GB. For larger heap sizes, you can try to use compressed references by explicitly setting -Xcompressedrefs.End of changes for service refresh 2 fix pack 10 However, larger heap sizes might result in an out of memory condition at run time because the VM requires some memory at low addresses. You might be able to resolve an out of memory condition in low addresses by using the -Xmcrs option.
So basically, at least this build of the JDK only supports compressedrefs, and in order to use that, I must set it manually since my Xmx is above the range where it is enabled by default, but that fails because my OS already allocated to much of <4GB memory ranges, but some is needed to use compressedrefs. Since I can never guarantee that that won't be the case, is there any way I can use OpenJ9 without compressedrefs? And will that even yield the benefits in terms of memory consumption? Or is there any way I can use compressedrefs with very high Xmx settings?
I also tried setting this option, but it didn't help: https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/openj9/xmcrs/index.html?view=embed
How do I find the correct size for it? 1G and 64m failed. Even if I find the correct setting, how would this value guarantee that the OS hasn't already allocated all the lower memory addresses?

The limit to use the compressed refs JVM is 57G and you can't run it if the -Xnocompressedrefs option is specified.
The 57G division is documented here: https://www.eclipse.org/openj9/docs/xcompressedrefs/
The -Xnocompressedrefs problem is mentioned in the release notes: https://github.com/eclipse/openj9/blob/master/doc/release-notes/0.15/0.15.md
With a reference to: https://github.com/eclipse/openj9/issues/479
Creating a single JVM that supports both is covered by: https://github.com/eclipse/openj9/issues/643
https://github.com/eclipse/openj9/pull/7505
(With thanks to the help from the Eclipse OpenJ9 slack community, especially to Peter Shipton)

I found this build which allows noncompressedrefs and thus solves my issues: https://adoptopenjdk.net/releases.html?variant=openjdk8&jvmVariant=openj9#linuxxl

Related

Maximum heap size using for Java process in Windows 10 64 bit running 64 bit JVM

What is maximum Heap size for Java process running on Windows 10 64 bits, with 64 bits JVM? My machine has 8 GB of RAM. And I am running Java 8.
I trying to run BFS on huge graph for experimental purposes. While running BFS I am monitoring Heap size being used in Java Visual VM. According to Visual VM heap utilization is always less than 2000 MB regardless of providing following JVM parameters
-Xms2048m
-Xmx3072m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
I did some research over internet but could not find any specific answer related to the system specification I am using. Can a java process use more than 2 GB on Windows 10 64 bit and 64 bit JVM? As Guidelines for Java Heap sizing the limit for Windows XP/2008/7 is 2 GB.
On a 64-bit machine, with 64-bit JVM you can work with multi gigabyte heaps (dozens and dozens of GBs). I'm not sure it's limited in any way except by the available memory (and the theoretical address space of a 64-bit pointer).
Of course if you're working with a huge heap, the GC has a lot more work to do and you may find that you need to scale horizontally instead of vertically, to maintain a good performance.
If VisualVM isn't showing you using more than 2GB (the initial heap size given with -Xms), then it probably just doesn't need more than that. You've given the permission to use up to 3GB (-Xmx), but the JVM won't allocate more memory just for the fun of it.
Maximum Heap can be allocated for 32bit JVM is 2^32 = 4G, Again 4gb will be devided into 1+ GB for VM to use for runtime classes. It varies windows it is ~2GB and linux it is ~3GB.
As you are using 64bit machine maximum heap available is 2^64 it will be big enough for you to run BFS easily.
You can monitor the available memory using vm flags "-XX+PrintFlagsFinal | grep -iE HeapSize" will tell you the maximum available heap size that can be used. Configure slightly less than that and start using...
There is no definite size you could specify for 64 bit architecture but simple test helps you find what is the maximum contiguous space available or could be allocated for a process. This could be tested as follow by using simple command.
Try as below
java -Xmx -version
If the above command gives result then your system could be allowed to have Xmx to that level, If it fails then you can't specify that value.
Few test from system.
I tested the value with 20G.40g,100G,160G,300G all these gave java -version output but tried with 1600G that throws the error.
Output of the test
C:\Users\mpalanis>java -Xmx300G -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
C:\Users\mpalanis>java -Xmx1600G -version
Error occurred during initialization of VM
Unable to allocate 52431424KB bitmaps for parallel garbage collection for the requested 1677805568KB heap.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Hope this explanation helps.
If you are using IntelliJ Idea as an IDE you can do this directly from it,
From the main menu, select Help | Change Memory Settings
Set the necessary amount of memory that you want to allocate and click Save and Restart.
This changes the value of the -Xmx option used by the JVM and restarts IntelliJ IDEA with the new setting.

JVM maximum memory allocation in Windows 2007

I am using a computer withe following specification:
OS-Windows7 professional
Installed Memory(RAM) :8Gb
System Type: 64 bit Operating System
JVM: Java version 8 update 91(jre1.8.0_91) 64 bit version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b15, mixed mode)
For using one desktop application I need large JVM memory allocation. With the above specification I can set the JVM at maximum 1.5gb(1536mb) using -Xmx command.
If I am increasing the value above 1.5 GB getting the following error:
"The JVM could not be started.The main method may have thrown out an exception."
Please let me know how can I allocate more memory to th e JVM.
The 1.5 GB limit means you are most likely using the Windows XP/32-bit version. When this question has come up before the OP has been sure they were using the 64-bit version but on investigation found they were not.
I suggest making sure there is only one version of Java installed, the 64-bit version you want to use.
In my opinion the best way of detecting your problem is to use JProfiler, it can detects if you're having a problem inside your vm and can monitor the status, it's simple to use and give a lot of debug. I saw at some articles that sometimes increasing too much the memory cause an error like this but I don't have a clue, try to look this too, hope it helps.

Eclipse won't start with Xmx set to 1024m anymore, though there is enough memory

My Eclipse (or, more specific, Spring Tool Suite) version is:
Version: 3.6.3.RELEASE
Build Id: 201411281415
Platform: Eclipse Luna SR1 (4.4.1)
It worked fine, until recently, when I started getting the following error after opening Eclipse:
Error: Could not create the Java Virtual Machine
Error: A fatal exception occured. Program will exit.
My start options include -vm <path to javaw> -vmargs -Xmx1024m -XX:MaxPermSize=256m, I am using jdk1.7.0_79, the 32 bit version, on a 64bit Windows.
I discovered, when setting -Xmx to 768m, Eclipse will start most of the time. I also noticed that starting eclipse began to fail when I installed the MySQL service; if I deactivate it, the Task Manager shows me I have roughly 4gb of 16gb of RAM consumed; with MySQL running, that value increases to 5gb.
What is the reason, when there are 5gb consumed and roughly 11gb of RAM left, that no JDK can be created, and is there a known workaround?
It is likely because of lack of virtual address space. Remember that 32-bit processes have only 2GB of virtual space, which is needed for:
application code
DLLs, both application DLLs and shared DLLs like hooks
java off-heap needs: code caches, buffers, etc.
java heap itself
So, physical RAM is unrelated.
What likely happened?
Eclipse grew heavier so JVM needs more off-heap to function
What you can do?
Uninstall unneeded plugins, shut down your antivirus or other software that could intervene with Eclipse, use 64bit java. 64bit apps are faster on modern processors + 64-bit java uses compressedOps so it could make sense.
In the past i had simlar issues, but no solution. I reached the limit with -Xmx1500m.
See also Maximum Java heap size of a 32-bit JVM on a 64-bit OS.
Is using the 64 bit Version of the JDK no option?

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: Could not create the Java Virtual Machine

I have visited all existing questions which are related to my question but I still have a problem. All installations are correctly installed. I am using the newest Netbeans version. After executing program I have this error:
Error: Could not create the Java Virtual Machine.
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: A fatal exception has occurred. Program will exit.
And my Netbeans.conf is:
# ${HOME} will be replaced by JVM user.home system property
netbeans_default_userdir="${HOME}/.netbeans/7.1.2"
# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xss2m -J-Xms16m -J-XX:PermSize=16m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.zip.disableMemoryMapping=true"
# Note that default -Xmx and -XX:MaxPermSize are selected for you automatically.
# You can find these values in var/log/messages.log file in your userdir.
# The automatically selected value can be overridden by specifying -J-Xmx or
# -J-XX:MaxPermSize= here or on the command line.
# If you specify the heap size (-Xmx) explicitly, you may also want to enable
# Concurrent Mark & Sweep garbage collector. In such case add the following
# options to the netbeans_default_options:
# -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled J-XX:+CMSPermGenSweepingEnabled
# (see http://wiki.netbeans.org/FaqGCPauses)
# Default location of JDK, can be overridden by using --jdkhome <dir>:
netbeans_jdkhome="C:\Arquivos de programas\Java\jdk1.7.0_07"
# Additional module clusters, using ${path.separator} (';' on Windows or ':' on Unix):
#netbeans_extraclusters="/absolute/path/to/cluster1:/absolute/path/to/cluster2"
# If you have some problems with detect of proxy settings, you may want to enable
# detect the proxy settings provided by JDK5 or higher.
# In such case add -J-Djava.net.useSystemProxies=true to the netbeans_default_options.
What do I have to do? I've been trying to resolve this error all day. My system Memory is 3Gb.
Could not reserve enough space for object heap
This almost always means that your -Xmx is too high for the machine. There is a message above:
# Note that default -Xmx and -XX:MaxPermSize are selected for you automatically
Try to provide explicit value, start small. Note that -Xms must be less then or equal to -Xmx
I got the same error while starting Netbeans
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I try to restart Netbeans many times. Same error was repeating. Later I found it was happening as some other application is already using JVM. So I looked for such an application which was Tomcat Server. I terminated Tomcat and tried starting Netbeans again and it was fine. So try looking for any application that uses JVM.
We have couple of solutions for the above Problem
Solution 1: You can re-install the all components. ie it means you have install the entire s/w.
for the Error: Could not create the Java Virtual Machine.
Solution 2: that maximum heap size varies based upon machine architecture e.g. 32 bit or 64 bit, JVM bit size e.g. 32 bit JVM or 64 bit JVM and operating system.
In 32 bit machine though theoretical limit of maximum heap size is 4GB, it varies on operating system to operating system e.g. on 32 bit windows XP maximum heap size limits upto 1.5G due to various reason while on 64 bit Solaris machine even with 32 bit JVM you can afford around 3.5GB. So when you run following java command in 32 bit Windows XP machine
Solution 3: One more worth noting syntax error while providing heap space is space between numeric literal and unit, as shown in below example:
Correct: ~/java java -Xmx1500 M
In-correct: ~/java java -Xmx1500MB
In-Correct: ~/java java -Xmx 1400M
-J-Xss2m -J-Xms16m -J-XX:PermSize=16m
Those are insufficient values. Try it increase from 16Mb to 512Mb (or 1Gb)

Categories