We are seeing somewhat frequent crashes of JDK 6_18 running the appserver under load -- the crash always occurs in GCTask. We've seen the same problem on 6_16 and 6_19.
We have observed this only on x86 hardware, but both Intel (an X2270) and AMD (x6250) machines running Solaris 10 (but haven't done extensive tests elsewhere).
Here are the JVM arguments for the appserver:
-d64 -XX:NewRatio=2 -XX:+AggressiveOpts -XX:+UseLargePages -XX:LargePageSizeInBytes=4m -XX:+HeapDumpOnOutOfMemoryError -XX:-UseBiasedLocking -Xmx3072m -Xms3072m -Xss256k -XX:+DisableExplicitGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -XX:+UseCompressedOops
We typically run with a bigger heap, but I've been testing the smaller heap in order to get a more reasonably-sized core file. On the other hand, adding -XX:+AggressiveHeap to the command line makes the crash occur much, much less frequently (probably just luck...)
We have observed this only on x86 hardware, but both Intel (an X2270) and AMD (x6250) machines running Solaris 10 (but haven't done extensive tests elsewhere).
Here are the JVM arguments for the appserver:
-d64 -XX:NewRatio=2 -XX:+AggressiveOpts -XX:+UseLargePages -XX:LargePageSizeInBytes=4m -XX:+HeapDumpOnOutOfMemoryError -XX:-UseBiasedLocking -Xmx3072m -Xms3072m -Xss256k -XX:+DisableExplicitGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -XX:+UseCompressedOops
We typically run with a bigger heap, but I've been testing the smaller heap in order to get a more reasonably-sized core file. On the other hand, adding -XX:+AggressiveHeap to the command line makes the crash occur much, much less frequently (probably just luck...)
- duplicates
-
JDK-6896647 card marks can be deferred too long
- Closed