The testcase from HP (see below) reveals a HotSpot server crash related to loops. The crash can be avoided by setting LoopUnrollLimit=0. The test case has a huge jar. I will work with HP on trying to obtain the source and produce a smaller test case. The test doesn't fail with client compiler.

The crash dump (reproducible with the latest mantis build: 1.4.2-beta-b04):
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2-beta-b04 mixed mode)
#
# Error ID: 53484152454432554E54494D450E435050018D 01
#
# Problematic Thread: prio=5 tid=0x0002deb8 nid=0x1 runnable 
#

TEST CASE TO REPRODUCE:

0. cd /net/knight1/export/tmp/hp_loop_bug/

1. Use ksh or bash

2. "source setenv.sh"

3. run myant

4. after a couple of minutes a crash will happen

====================================

HP's customer is not comfortable giving the source to Sun. So, I won't be able to deliver a micro test case.

 xxxxx@xxxxx  2002-11-01

create a file named .hotspot_compiler in current directory, and put the followling line in the file:

exclude weblogic/xml/babel/scanner/Trie get

 xxxxx@xxxxx  2002-11-05

Loop unrolling is missing a loop-carried dependency between a test against null and a load.

 xxxxx@xxxxx  2002-11-07

In the program provided, unrolling of a loop causes bad code to be
generated because a loop carried dependency is lost.  The load at the
top a loop is mistakenly moved outside a loop iteration because the
PostCCP pass presumes a CastPP to loop invariant. When the loop is
unrolled, there is no control to pin the load in the current
iteration, allowing it to float above the previous iteration's load,
on which it is dependent.

In Ideal_DU_postCCP, the server compile removes CastPP nodes and
adjusts the control input of memnodes.  If a CastPP is elided, C2
needs to be vigilant about not moving the associated load out of a
[counted] loop, unless it can be determined that the CastPP is loop
invariant.

We could simply not check for loop invariance, and disallowed all
CastPP covered loads to not float out of a loop. However, this causes
a few loops in Spec to suffer code degradation.  The invariance check
allows Spec code to remain unchanged, and during a CTW test rt.jar,
only 5 loads in 3 loops failed this additional check.

 xxxxx@xxxxx  2002-11-22

In which release was this fixed? We are encountering the 
same error with the 1.4.2 VM, running on a 5.8 Solaris box 
with the J2SE cluster patch applied to it.

Same here. 1.4.2_01 Server VM on Linux 2.4.18 debian.

on Linux test i mentionned,
JAVA_OPTS="-Xms256m -Xmx256m"

on Solaris 8:
same build and version for JVM SUN
JAVA_OPTS="-server -d32 -Xms128m -Xmx128m -
XX:+UseLWPSynchroniza
tion"

same containers and stress conditions, no crash, no errors

no same here. 
OS :RedHat 7.2 2.4.7-10 smp 
JVM :SUN java version "1.4.2_01" (build 1.4.2_01-b06)
web container :apa1327-tomcat4.1.24 with jolt8
sbgd: oracle 8.1.7
stress: 800 concurent access ,10hours, 635 hit/s througput 
3,25 Mb/s, no errors , no crash
but next road map is with 2.4.18 kernel..
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

may be next step will be problematic..

what are you thinking about?

We encounter this with 

FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-
b06, mixed mode)

FULL OS VERSION :
SunOS 5.8 Generic_108529-22 i86pc i386 i86pc

 

I see this on HPUX RISC 11.11
JRE 1.4.1.07
consistently after running for a day.

You should check the ErrorID to make sure it exactly matches the one in the original report.  You should also move to the VM from the most recent 1.4.2 release available.  There will no more updates to 1.4.1. 

If you find you still are seeing the crash, since your bug is on an HP platform which is not supported by Sun, please contact HP customer support.