I got similar problem upgrading to JDK 1.6_18 and it seems solved using the following options:
-server
-Xms256m
-Xmx748m
-XX:MaxPermSize=128m
-verbose:gc
-XX:+PrintGCTimeStamps
-Xloggc:/tmp/gc.log
-XX:+PrintHeapAtGC
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
-XX:+UseParallelGC
-XX:-UseGCOverheadLimit
# Following options just to remote monitoring with jconsole, useful to see JVM behaviour at runtime
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=MyHost
I still didn’t double check (it is a production environment), but I think the error was due to two reasons:
1) Wrong setting about heap and/or Permanent space (I think JDK 1.6 needs more space in heap and permanent than previous JVM versions) caused an OutOfMemoryError, but
2) in the wrong original setting somebody wrote
-XX:+HeapDumpOnOutOfMemoryError="/tmp"
and not
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
so probably JVM was not able to write the heapdump and we got SIGSEGV only (previous versions wrote heap dump in the working directory).
Check -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit
options too. I think playing with VM parameters is not a workaround, but the right approach also because garbage collector (and not only) changed between 1.5 and 1.6.