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).

jvisualvm profiler version error

I'm trying to profile some wildfly based application. CPU and memory sampling is working fine, but not profiling. After clicking Profiler -> Memory I get:
"Warning: The profiler agent you are connecting to is a different version than this profiler. You may encounter errors and unexpected behavior"
And then:
"Unexpected problem when trying to start target application: Target VM terminated or does not respond"
Visual VM version 1.3.8 and java version "1.8.0_20" on Windows 7 64-bit

running java 5/6 with JNI on java 7 gives stack guard warning

A java program built with 1.5 (or 1.6 with 1.5 comparability mode on) gives this warning:
Java HotSpot(TM) Server VM warning: You have loaded library
mynativelib.so which might have disabled stack guard.
The VM will try to fix the stack guard now. It's highly recommended that you fix the
library with 'execstack -c ', or link it with '-z
noexecstack'.
It doesn't seem to cause a problem but obviously would look a bit scary to our customers.
I don't think building the java bits in 7 would fix this issue but I'm struggling to see where the docs say how to build JNI libs for Java 7, which is what the warning implies I should be doing differently.
So where should I be looking?

Found the answer here
disabled stack guard warning (ACF9, JVM 1.7, Linux)
He said
This is a feature in Java 7’s HotSpot compiler on Linux which tries to stop code written in C and linked into Java (the so-called Java Native Interface - JNI) from halting the whole VM if it’s written badly or maliciously.

Another possibility is that the Java+JNI application that you are trying to run was compiled for Linux 32bit.
In such a case, two solutions:
If you have the source code of the application, port it to Linux 64bit
If not, download the Linux 64bit version of the application.

Java 7 trigger heap dump without having JDK installed

How can I trigger a heap dump for a Java 7 VM running on Linux without having a JDK installed?
In earlier versions of Java it was possible to set the -XX:+HeapDumpOnCtrlBreak JVM option and then trigger a heap dump by using kill -QUIT <pid>. I have been unable to get this to work with Java 7. Is there an equivalent to this without needing the JDK installed to get JVisualVM or jmap.

VM option -XX:+HeapDumpOnCtrlBreak is no longer listed at http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html. So, I conclude that it's no longer supported.
From http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html:
Options that are specified with -XX are not stable and are subject to
change without notice.

You can generate a core dump with gcore, move it to another machine, and attach jmap to generate hprof file as described in Core dump taken with gcore, jmap conversion to hprof file format fails with Error message
See also accepted answer.

Eclipse Indigo 64-bit severe memory leaks

I'm working with Eclipse Indigo, 64-bit version in 64-bit Windows 7 and the most recent version of 64-bit Java SDK. Using standard Java and XML as well as Pydev plugins. My machine has 4 GB of RAM.
When I try to open, edit, and search large XML files (42,000 lines or so) in either the XML perspective or the plaintext editor of Eclipse, the program locks up. The heap monitor in Eclipse becomes fully consumed. Waiting to see if the deadlock will halt doesn't help, and I have to restart Eclipse to get it functional again.
Any ideas what the problem is here? Bad version of Java? Eclipse Indigo or 64-bit version not road-ready to go yet?

42K is a really big file for the poor XML editor. It's likely that it's just taking a really long time to deal with this. I would file a bug against the webtools project in Eclipse and attach your file (if you don't mind sharing).
I would capture the thread dump (google "java thread dump" if you don't know how to do this) a few times while it's working so that you can get a stack trace of what's happening which might be useful to the Eclipse folks.
There is nothing wrong with Eclipse Indigo or 64 bit Eclipse (I and many others use those just fine for normal work).