JDK 1.4.1_02 C1 crashes during compilation, on Sol8.

Attached is a standalone reproduceable test case (testcase_030603.tar) which 
exhibits this problem (untar and run "ksh test_template.sh" to reproduce the
problem).

The hotspot error is as follows:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 4 occurred at PC=0xB2F6C
Function=[Unknown.]
Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.

Current Java thread:

Dynamic libraries:
0x10000         /export/javaprod/j2sdk1.4.1_02/bin/java
0xff340000      /usr/lib/libthread.so.1
0xff380000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff320000      /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
0xfe000000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/client/libjvm.so
0xff2d0000      /usr/lib/libCrun.so.1
0xff1d0000      /usr/lib/libsocket.so.1
0xff100000      /usr/lib/libnsl.so.1
0xff0d0000      /usr/lib/libm.so.1
0xff300000      /usr/lib/libw.so.1
0xff0b0000      /usr/lib/libmp.so.2
0xff060000    /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/native_threads/libhpi.so
0xff030000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/libverify.so
0xfe7c0000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/libjava.so
0xfe7a0000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/libzip.so
0xfe4e0000      /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2

Local Time = Thu Mar  6 11:03:19 2003
Elapsed Time = 9
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.1_02-b06 mixed mode)
#
# An error report file has been saved as hs_err_pid2145.log.
# Please refer to the file for further information.
#
Abort - core dumped


The native stack is as follows:
jtech% /net/statt/opt/FD7/SUNWspro/bin/dbx /export/javaprod/j2sdk1.4.1_02/bin/java core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc
Reading java
core file header read successfully
Reading ld.so.1
Reading libthread.so.1
Reading libdl.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading libjvm.so
Reading libCrun.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.1
Reading libw.so.1
Reading libmp.so.2
Reading libhpi.so
Reading libverify.so
Reading libjava.so
Reading libzip.so
Reading en_US.ISO8859-1.so.2
detected a multithreaded program
 xxxxx@xxxxx  ( xxxxx@xxxxx ) terminated by signal ABRT (Abort)
0xff359794: __sigprocmask+0x0008:       jmp     %o7 + 0x8
(dbx) 
(dbx) where                                                                  
current thread:  xxxxx@xxxxx 
=>[1] __sigprocmask(0x0, 0xffbecec8, 0x0, 0x0, 0x0, 0x0), at 0xff359794
  [2] _resetsig(0xff35bf6c, 0x0, 0x0, 0x288f0, 0xff36e000, 0x0), at 0xff34e9a0
  [3] _sigon(0x288f0, 0xff375938, 0x6, 0xffbecf9c, 0x288f0, 0x6), at 0xff34e140
  [4] _thrp_kill(0x0, 0x1, 0x6, 0xff36e000, 0x1, 0xff2be438), at 0xff351180
  [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2be3a4, 0x4), at 0xff24b568
  [6] abort(0xff2ba000, 0xffbed0f0, 0x0, 0xfffffff8, 0x4, 0xffbed111), at 0xff23587c
  [7] os::abort(0x1, 0xfe3efed6, 0xffbed190, 0x0, 0xfe43d4d4, 0xfe339314), at 0xfe33af48
  [8] os::handle_unexpected_exception(0x2c728, 0x4, 0xb2f6c, 0xffbedec8, 0x4, 0xfe33d164), at 0xfe339384
  [9] JVM_handle_solaris_signal(0xb2f6c, 0xffbedec8, 0xffbedc10, 0x4000, 0x4318, 0x0), at 0xfe33d410
  [10] __sighndlr(0x4, 0xffbedec8, 0xffbedc10, 0xfe33bd38, 0x28994, 0x28984), at 0xff35b830
  [11] sigacthandler(0x4, 0x288f0, 0x0, 0x0, 0x0, 0xff36e000), at 0xff358508
  ---- called from signal handler with signal 4 (SIGILL) ------
  [12] 0xb2f6c(0x82, 0x82, 0xffbee0b4, 0xfe428000, 0x1b84, 0xffbedfc8), at 0xb2f6b
  [13] 0xfa405c64(0xf6118168, 0x0, 0xffbee0c8, 0xfa415398, 0x2ccdc, 0xffbee058), at 0xfa405c63
  [14] 0xfa405c64(0xf20111b0, 0xffbee1e4, 0xffbee1e8, 0xfa415078, 0x1, 0xffbee100), at 0xfa405c63
  [15] 0xfa405c64(0xf20111b0, 0xffbee1f0, 0xffbee1f0, 0xfa415030, 0xfa40ac74, 0xffbee188), at 0xfa405c63
  [16] 0xfa405c64(0xf200ef48, 0xf6118168, 0x0, 0xfa415030, 0xf200ef48, 0xffbee218), at 0xfa405c63
  [17] 0xfa4989e8(0xf2071c00, 0xf2071ba0, 0xf200ef48, 0x0, 0x0, 0x0), at 0xfa4989e7
  [18] 0xfa405c64(0xf203dfd0, 0x20, 0x8, 0xfa415030, 0xf2200000, 0xffbee3c0), at 0xfa405c63
  [19] 0xfa405c64(0xf203dfd0, 0xb6, 0x2, 0xfa415030, 0xf6114250, 0xffbee448), at 0xfa405c63
  [20] 0xfa405c64(0xffbee530, 0x0, 0x0, 0xfa415030, 0x3611ec, 0xffbee4d0), at 0xfa405c63
  [21] 0xfa400118(0xffbee5bc, 0xffbee7b8, 0xa, 0xf61145f0, 0xfa40aae0, 0xffbee6b8), at 0xfa400117
  [22] JavaCalls::call_helper(0xffbee7b0, 0xffbee670, 0xffbee6b0, 0x2c728, 0x2c728, 0x5c00), at 0xfe0d4bec
  [23] jni_invoke_static(0x1, 0xffbee7b0, 0x0, 0x0, 0xba730, 0xffbee794), at 0xfe0ecafc
  [24] jni_CallStaticVoidMethod(0x2c7b4, 0x2d18c, 0xba730, 0x2d19c, 0x2c7b4, 0xf203dfc0), at 0xfe189854
  [25] main(0x4, 0x0, 0xba730, 0x2d19c, 0xba745, 0x284), at 0x12538
(dbx) quit
jtech% 
jtech% 
jtech% 

This problem does not happen with b16 of jdk 1.4.2 beta.

1) A viable workaround is to exclude the following method in .hotspot_compiler
   file:
	      exclude notification_jsp_ _templateService
   This workaround works fine for the attached test case (testcase_030603.tar).
	      	  	
2) Also this problem does not happen with C2 (server) compiler, but 
   unfortunately using C2 compiler is not an option in this scenario.

Can reproduce with 1.4.1_02 but appears to be fixed already in 1.4.2.

 xxxxx@xxxxx  2003-03-06


Given that this doesn't show up in the current release the customer should file
an escalation to have this fixed in a previous release if necessary.

 xxxxx@xxxxx  2003-03-07


 xxxxx@xxxxx  was able to reproduce this with the current 1.4.2 and
further investigation shows that when the classes are compiled with the 1.4.1
javac both the 1.4.1 and 1.4.2 VMs crash, but when the classes are compiled with
the 1.4.2 javac (which I believe eliminates most jsr/ret pairs) the result works
on both 1.4.1 and 1.4.2. Will commit to 1.4.2 pending further investigation.

 xxxxx@xxxxx  2003-03-10


The problem is that excessive amounts of relocation information are being
generated due to pathological inlining of jsr/rets in the JSP's bytecodes.
The 1.4.2 javac inlines these jsrs at the bytecode level; the VM then doesn't
need to perform any inlining. Added a bailout check on the relocation portion
of C1's temporary codebuffer.

 xxxxx@xxxxx  2003-03-10


Fixed in 1.4.2.

 xxxxx@xxxxx  2003-03-13