I had a agent JVM crash during the take of a memory snapshot. The JVM had a few hours of heavy duty. It happened twice, in the same conditions.
If its your code, maybe you can avoid the crash of the JVM in this case and just fail to take the snapshot.
Note: it's the server version of HotSpot, I did not try with the client version.
Regards,
Loïc
[root@active4 Log]# uname -a (RedHat EL 4 WS)
Linux active4 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 GNU/Linux
[root@active4 Log]# java -server -version
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode)
[YourKit Java Profiler 4.5 EAP build 628] Using JVMTI
[YourKit Java Profiler 4.5 EAP build 628] Listening on port 10001...
[...]
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
agent JVM crash during memory snapshot
-
Anton Katilin
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Hi,
Thank you for the report.
This is indeed a crash inside the JVM. I have recently contacted SUN engineer regarding the behaviour of JVM on low resource conditions. He said there probably will be, in next versions of JVM, an error code returned if such an operation fails, but, unfortunately, currently existing JVMs does not return error codes to profiler agent - the JVM simply terminates. So until corresponding support is added to JVM, a profiler cannot handle these situations because it simply does not get access to them...
The only suggestion I may think of is to try to provide the JVM process with more native resources: increase available virtual memory, maybe use 64-bit Java.
Best regards,
Anton
Thank you for the report.
This is indeed a crash inside the JVM. I have recently contacted SUN engineer regarding the behaviour of JVM on low resource conditions. He said there probably will be, in next versions of JVM, an error code returned if such an operation fails, but, unfortunately, currently existing JVMs does not return error codes to profiler agent - the JVM simply terminates. So until corresponding support is added to JVM, a profiler cannot handle these situations because it simply does not get access to them...
The only suggestion I may think of is to try to provide the JVM process with more native resources: increase available virtual memory, maybe use 64-bit Java.
Best regards,
Anton