Develop Reference

Java exits abruptly on a Windows 11 VM (host is M1 Mac)

I'm having a very odd issue with Java exiting abruptly and randomly.
I have a Macbook with M1 system (2021 model), with 32GB RAM. I'm running a Windows 11 (ARM64 Insider Preview) VM with Parallels. I have 16GB of RAM allocated for the VM, and 6 cores. I have Liberica JDK 8 (full with JavaFX) installed both on the host and the VM. I'm developing a multi-module Maven project, same project on both the host side and the VM side (the project depends on some Windows side things for some tasks, which is the reason I'm running the Windows VM on the side).
Output from java -version:
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (build 25.332-b09, mixed mode)
I've also tried with Azul JDK and had the same issue with it.
On the host side everything works as it should. Maven and Java commands both run successfully with no interruption or issues. On the Windows VM side however, it seems that Java just randomly exits with no error logs or anything really. I noticed it just hangs for a few seconds, and then just exits abruptly. I noticed that it may happen while running a Maven command, or for example running a .jar package with java -jar. Here's a picture of what it looks like (same happens on the picture above though):
A couple weeks back I had no issues at all. But then I had to reinstall Parallels and the VM (reinstalled the whole W11 OS), and suddenly these issues started occurring. I've tried adding -XX:+HeapDumpOnOutOfMemoryError to MAVEN_OPTS environment variable to see if it's a OutOfMemoryError, but it did not seem to have any results.
Any ideas?

In case anyone runs into this issue: I was able to resolve this issue by installing the Windows 11 VM into Parallels from an image downloaded from UUP Dump.
I tried reinstalling the VM downloaded from the Microsoft's Insider Preview page, but the issue still persisted and nothing seemed to be able to fix it. Java still exited randomly pretty frequently.
I downloaded the latest Windows 11 image from UUP Dump and installed that one instead. Installed the exact same versions of Maven, Java, Groovy etc. and surprisingly, the issue vanished. I've been able to run Java on my VM for a day now without issues, whereas with the image downloaded from Microsoft I was able to reproduce the issue pretty much within minutes after configuring my environment and cloning the Git repo of the project I'm developing.

A lot improved for me after switching to ARM64 Java (Microsoft's was first one I found, there may be others).
Some background: not sure if I had exactly the same issue, but vscode compiling and code checking was slow and unreliable, and my Mendix Java application kept crashing or not even starting. Since that uses Java 11, that's what I installed the ARM64 version of. This is in Windows 11 ARM, from Microsoft's Preview page, updated (hang the first try, but worked the second).

VisualVM shows "Not supported for this JVM"

I am trying to profile a remote JVM with VisualVM 1.4. I am running macOS High Sierra 10.13.6 locally, with the following OpenJDK version:
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.181-b13, mixed mode)
The server runs Debian Stretch with the following OpenJDK:
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
When I monitor a JVM process locally, I see all these tabs and the profiling works just fine.
However, if I do that remotely, I see something like this:
Note the CPU window that says "Not supported for this JVM" and the reduced tabs, not including "Profiler". However, as you can see, I do see some data.
I am connecting via jstatd. On the server, following this article, I am running
jstatd -J-Djava.security.policy=/home/brandwatch/jstatd.all.policy -J-Djava.rmi.server.hostname=10.2.156.160 -Djava.rmi.server.logCalltrue
Answers like this indicate that this might be due to different JVM versions, however, mine appear to be the same, despite one of them running on MacOS and one of them on Debian.

Missing CPU usage information has nothing to do with with different JDK versions. You don't see CPU usage data because jvmstat (exported via jstatd) does not provide such information. If you want to see CPU usage, you need to use JMX connection. JMX will also allow you to do CPU and Memory sampling. Profiling is supported for local applications only.

Because, as Tomas Hurka's answer correctly indicates, remote profiling does not work with VisualVM, I have used a little hack to still make it work: I have installed VisualVM on the remote server and accessed it via X-forwarding. That way, VisualVM can access the process locally an thus profile it.
ssh into the server with the -X flag
ssh -C -X <user>#<host>
download [VisualVM 1.4][8]
wget https://github.com/visualvm/visualvm.src/releases/download/1.4/visualvm_14.zip
unzip the archive
unzip visualvm_14.zip
run VisualVM
./visualvm_14/bin/visualvm
After a few seconds you should see a VisualVM window pop up. It's not very fast (just because x-forwarding is not), but for my use case it was alright.
Another way of achieving this might be using VNC, but I haven't tried that. The downside would be that you have to install all the desktop packages, which one might not want on a server.

Prevent program from crashing when showing allocation stack traces

Question
Why does VisualVM terminate my program when attempting to view object allocation stack trace, and how do I fix it?
I'm cleaning up an application which has a few memory problems, the biggest being creating a bunch of short-lived int[] which causes GC to fire like crazy:
When I right click int[] and choose Take Snapshot and Show Allocation Stack Traces, my application closes and a warning box pops up saying Failed to obtain results snapshot. The application terminated:
The closest thing I found on the subject was a bug report which recommended running my profiled application with -Xnoclassgc. It didn't work, the results were the same.
Specs
VisualVM: 1.8.0_60 (Build 1380-140910); platform 20140910-unknown-revn
Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM (25.60-b23, mixed mode)
Eclipse: Luna Release (4.4.0) Build id: 20140612-0600
System: Windows 7 (6.1) Service Pack 1, amd64 64bit
Crash log
http://pastebin.com/a4YPWutj
The size of the crash log exceeded the character limit, so I had to place it elsewhere. Sorry.

Ok. So based on the crashlog obtained, it looks like you ran into a VisualVM bug already reported here:
JVM being profiled crashes
The submitter of the original bug narrowed this behavior down to Java8, so the best chance you have is running a VisualVM on an older (Java7) runtime. If this is an option for you, then you only need to download a Java7 JDK and run the VisualVM directly from there.

jvm monitor no provider installed/cannot attach to 64-bit process error despite jvm FAQ solution

So I can't get jvm monitor to run. I have set eclipse (Mars) to start with the -vm option for the jdk1.8.0_60, the same I set in jvm preferences.
However on 32-bit eclipse I get the error "cannot attach to a 64 bit process" (despite I downloaded x86 Java version), and on 64-bit eclipse I get the error message "no providers installed", which the jvm monitor FAQ says are both fixed by what I did (setting Eclipse to use same jdk and same 32/64-bit)...

Unable to set java heap space > 2GB on Win2008 64bit

Unable to set java heap space using -Xmx to 2GB or more even though the RAM size is 16GB.
I encounter an error saying "
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit"
This is seen while starting a Jenkins server on my Win2008 x64 machine.
Please let me know if I could change any system parameter which will allow me to allocate more memory.
Thanks

Run
java -version
and check you see
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
I expect you have a 32 bit version of java which is limited to 2 GB (as its not large address aware)

Found the fix with the help of clue given above by Neil.
Here is the full details:
Even though the machine is installed with JDK 1.7 x64 bit, Jenkins by default is not configured with this version available on the machine.
Jenkins has its own JRE bundled with the installer which is used by default.
To change it to a different JDK edit the Jenkins.xml file and modify the below value
<executable>jre\bin\java</executable>
to
<executable><jdk install path>\bin\java</executable>
This is now solved!!

Use "java -version" to ensure that your java hotspot is a 64-bit server vm.

theoretical limit for maximum heap size on 32 bit JVM is 4GB and for 64 bit JVM its 2^64
For more detail Click here