We Keep Coding

Error while installing Cassandra (Invalid initial heap size: -Xms4096M)

I am trying to run Cassandra on my windows, but I keep on getting this error.
Failed 64-bit check. Re-running to get version from 32-bit
Invalid initial heap size: -Xms4096M
The specified size exceeds the maximum representable size.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Can anyone explain why I am facing this and how to resolve this error.

So it sounds to me like your JAVA_HOME variable is pointing to a 32-bit JRE. Reverify/install your Java installation, making sure to use a 64-bit version.
If you're using Cassandra 3, Java 8 is the highest main version that it will work with. If you're on Cassandra 4, this is going to be difficult to run natively as Windows support was completely removed from that version.

Invalid maximum heap size?

I am running an grails application for my project in IntelliJ and I have set the vm options to :
-Dserver.port=8080 -Xms3g -Xmx3g -XX:-UseGCOverheadLimit -Xverify:none
The logs are :
Running Grails application
Invalid maximum heap size: -Xmx4096M
The specified size exceeds the maximum representable size.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Error | Forked Grails VM exited with error
Please help me with that ?

I have no chance to write comment, that's why I am writing answer directly.
If your JVM is 32bit, then heap size should lower than 4gb. Either you can install 64bit JVM, or set the maximum heapspace to 2GB with -Xmx2048M. I had similar problem and this worked for me, hope this helps you as well

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

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?

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.