Project epdm2 is using an application AutoVue (3rd party software from Cimmetry). AutoVue server
usually dies several hours after startup. After investigation from Cimmetry, it's concluded JVM garbage collection thread is crashing the JVM. Please see below for the detail information 

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (4652414D450E435050041F 01), pid=19732, tid=8
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_12-b04 mixed mode)

---------------  T H R E A D  ---------------

Current thread (0x000bda40):  GCTaskThread [id=8]

Stack: [0xc8a00000,0xc8a80000),  sp=0xc8a7f798,  free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x70c0dc]
V  [libjvm.so+0x438528]
V  [libjvm.so+0x180f8c]
V  [libjvm.so+0x1bab88]
V  [libjvm.so+0x1c18b8]
V  [libjvm.so+0x350a40]
V  [libjvm.so+0x67ce98]

One possible cause is that a thread stack is getting corrupted, and when the garbage collector thread tries to free that thread's memory it exits unexpectedly and crashes the JVM.

http://forum.java.sun.com/thread.jspa?threadID=5127524&tstart=0

The other jvue logs show this error 5448524541442C4F43414C33544F524147450E4350500058 01, which points to a bug in JVM

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219874

Without the hs_errpid.log for this last error we cannot know what thread is causing the crash, though. In order to confirm the root cause in either case, Sun would need to get a core dump of the JVM when it crashes. They would have to get in contact with Sun support to analyze it.

This does not point to Autovue, but a lower level problem on Sun's JVM.