We Keep Coding

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

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

Segmentation Fault only on Ubuntu 10.04 32bit because of too small stack size

I have a Java application which uses several native libraries through JNA.
The application works fine on many different systems. However, on Ubuntu 10.04 LTS - 32bit when I close the application a segmentation fault occurs.
64bit works fine and the error does not occur on other 32bit distributions. Windows works fine too.
The segmentation fault occurs in the delete function of glibc within an empty destructor.
The problem is solved, if I increase the maximum stack size of the JVM to 32mb
(e.g. java -Xss32m ...)
Does anyone have an idea why this error only happens on Ubuntu 10.04 32bit?
I have tested several distribution within a VM.
I am using Java 8 and the default maximum stack size is 4MB.
I dont know if this is relevant to the JVM, but ulimit -s is 8MB.

Grails 2.3 could not create jvm error

I recently upgraded my grails application from grails 1.3.6 to grails 2.3. Up-gradation process completed successfully with required changes.
Now i'm facing a problem please see stack-trace:
| Running Grails application
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid maximum heap size: -Xmx4096m
The specified size exceeds the maximum representable size.
| Error Forked Grails VM exited with error`
Any help??
Thanks

It looks like you're running a 32bit version of the JVM, which will only support a max heap size of 2 gigabytes, not 4 gigabytes.
Find out what version of the JDK / JRE Grails is using. Then see whether you can change it to a 64 bit VM if you need 4 gigs of heap space. Otherwise, amend your startup parameters so that the JVM only requests a 2 gig heap size when Grails spawns it.

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)

It is failed to create Java Virtual Machine

I got "failed to create JVM" error when I tried to run a jnlp file.
But it works when I removed the max-heap-size="1100m" from Java/j2se tag in jnlp.
It seems something wrong with the max-heap-size. I did some experiments to change the heap size in eclipse.ini file. The biggest heap size I could set is "940M", otherwise I got "Could not create JVM..." error when start the eclipse.
I suspect this is a memory(hardware) problem on my PC. My laptop is pretty new. But for some reason, my admin change the OS from Windows 7 to Windows XP. They now want to change back to windows 7.
I am using JDK 1.6 update 29 and eclipse Version: 3.7.0 Build id: I20110613-1736. Windows xp sp3.

Java requires continuous memory for the heap space. Windows in particular tends to have a limited continuous region of memory available (which is smaller if other programs are running)
I would have thought you can have 1.2 GB heap, but this is far less than the 4 GB a 32-bit application can use in theory.
Switching to a 64-bit JVM on a 64-bit OS is the solution. This will allow you to create a heap space close to the physical memory size.