OPERATING SYSTEM
----------------
Solaris 10 Sparc

JDK VERSION
-----------
Problem appeared in 1.5.0_18 or 1.5.0_19.
Not reproducible with 1.5.0_17.
Reproducible with 1.5.0_23.

PROBLEM DESCRIPTION
-------------------
VM process crashes frequently in our customer's environment when compiling a Java method. The method being compiled varies, so method exclusion is not a feasible workaround - every time we exclude a method the crash occurs in another method. As this is a 64bit environment, the Client compiler is also not an option.

Here is an example stack trace:

=======================================================================
 ffffffff7f0ca124 _lwp_kill (6, 0, ffffffff7f0ad9d0, ffffffff7f1e0000, ffffffffffffffff, 1800) + 8
 ffffffff7f04620c abort (1, 1b8, ffffffff7e7d08e8, 199f00, 0, 0) + 118
 ffffffff7e7ca500 __1cCosFabort6Fi_v_ (1, fc00, e, ffffffff7ea34000, 269b54, b400) + 60
 ffffffff7e863528 __1cHVMErrorOreport_and_die6M_v_ (0, ffffffff7eae5c3c, ffffffff7eae5c08, ffffffff7e922144, ffffffff7ead9e50, 0) + c68
 ffffffff7e376038 JVM_handle_solaris_signal (b, 13078, ffffffff125fd2c0, 1002f7d60, ffffffff125fd5a0, 10800) + b08
 ffffffff7f0c9030 __sighndlr (b, ffffffff125fd5a0, ffffffff125fd2c0, ffffffff7e375500, 0, a) + c
 ffffffff7f0bd7a4 call_user_handler (ffffffff13101c00, ffffffff13101c00, ffffffff125fd2c0, c, 0, 0) + 3e0
 ffffffff7e1ef8ac __1cOPhaseIdealLoopUbuild_loop_late_post6MpnENode_pk0_v_ (ffffffff125fdec0, 0, 10057ee28, 0, ffffffff125fdee0, 100b6db18) + 384
 ffffffff7e310854 __1cOPhaseIdealLoopPbuild_loop_late6MrnJVectorSet_rnJNode_List_rnKNode_Stack_pk0_v_ (ffffffff125fdec0, ffffffff125fd950, ffffffff125fd8f0, ffffffff125fd910, 0, 101701980) + 28c
 ffffffff7e30d1bc __1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_ (ffffffff125fdec0, 0, 0, ffffffff125fdec8, ffffffff125fd8f0, ffffffff125fd950) + bb4
 ffffffff7e38d138 __1cHCompileIOptimize6M_v_ (ffffffff125fea40, 10022b7f0, 6a70c4, 0, f800, ffffffff7e8b69af) + 208
 ffffffff7e39025c __1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_ (ffffffff125fea40, 0, ffffffff125ff9a8, 1016c6ab8, 0, 9f8) + c3c
 ffffffff7e386864 __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_ (ffffffff125ff9a8, ffffffff7e89f010, 101df94b0, ffffffffffffffff, 1002e18f0, ffffffff125febe0) + b4
 ffffffff7e386e2c __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_ (101df94b0, 10022b7f0, 1002f7d60, 0, ffffffff7ead8520, ffffffff7ea34000) + 504
 ffffffff7e454740 __1cNCompileBrokerUcompiler_thread_loop6F_v_ (ffffffff7ead8520, 10022b700, 1002f7d60, 1002f8470, ffffffff7eac2c48, ffffffff7eac2c4c) + 450
 ffffffff7e3ed6c4 __1cKJavaThreadDrun6M_v_ (1002f7d60, f000, ffffffff7eacdbdc, 0, 0, ffffffff7ea34000) + 2ac
 ffffffff7e7c9f90 __1cG_start6Fpv_0_ (1002f7d60, b460, b000, b3f8, ffffffff7ead9674, ffffffff7ea34000) + 210
 ffffffff7f0c8f04 _lwp_start (0, 0, 0, 0, 0, 0)
=======================================================================

This crash did not occur in earlier 5.0 releases, and we've narrowed its introduction down to either 1.5.0_18 or 1.5.0_19. Therefore the prime suspects are the compiler fixes in 1.5.0_19:

6260293: fix set_ctrl() inconsistencies in loopopts
6394438: crash in C2 compiler in MachSpillCopyNode::implementation on 5.0_U4
6435614: code fails with impossible ArrayIndexOutOfBounds Exception
6754146: 1.5.0_15 C2 compiler crashes in PhaseChaitin::Split()
6788347: C2Compiler crash 6u7
6798785: Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers

(there are no compiler changes on the 1.5.0_18 release notes)

Full core file and associated crash data available on request.

There are a few existing CRs which include similar crash stack traces:

6903416
6788347 (fixed in 1.5.0_19)
6922056
6891431