Bug ID: JDK-4753233 VolanoMark/VolanoTest failed intermittenly with Mantis b02 -d64

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.2 mantisFixed

Intermitten volanomark/volanotest failure happened with Mantis b02 -d64.

# uname -a
SunOS jtg-e250-3 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-250

On jtg-e250-3.sfbay, volanotest failed intermittenly with Mantis b02 -d64. (Failure rate: 1/500)
There is no core dump.
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002E2 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi

Log files available under /bt/VolanoTestrun.13093.-d64. There is an error file
"hs_err_pid13954.log" under the directory.

# uname -a
SunOS jtg-e420-3 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-80
On jtg-e420-3.sfbay, volanomark failed intermittenly with Mantis b02 -d64. (Failure rate: 43/6771)

# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002E2 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi

No core dump.

Log file availale under /bt/VolanoMarkrun.3992.-d64. There are a bunch of
"hs_err_pid*log" files under the directory.

###@###.### 2002-09-25

On jtgbp62d.sfbay ( uname -a
SunOS jtgbp62d 5.8 Generic_108529-15 i86pc i386 i86pc ), volanotest failed
intermittenly with Mantis b02 -client.
failure rate: 2/948
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002E2

log files are under /bt/VolanoTestrun.18845.-client

On jtgb4u2d1.sfbay (uname -a
SunOS jtgb4u2d1 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-60), vmark failed,
server crashed after 1 hour 10 minutes.
# Error ID : 4F530E43505002E2 01
# Please report this error at

log files are under /bt/VolanoMarkrun.2737.-server
There was a "hs_err_pid2767.log" error file generated just before the server crashed.

###@###.### 2002-09-25

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis VERIFIED IN: mantis

14-06-2004

EVALUATION On a deopt that happens during execution of an inlined jsr/ret, c2 is restoring the return bci as a 32-bit int, not a 64-bit return address. Cliff's change to the ret code in templateTables_sparc.cpp that changed the _LP64 code that had dealt with this from unconditional to an assert exposed the problem. The steps to finding the problem were 1. The segv occured in the ret interpreter code when we tried to load the byte at the ret target. Because sparc is big-endian and 32-bit values are stored in the low addressed half of a 64-bit stack/locals slot for _LP64, when we loaded the entire 64 bits and attempted to use it as a bci, we got a very large bci. Converting that large bci to a bytecode pointer produced an illegal address. 2. I enabled the assertion code in the ret() template table method unconditionally. It triggered almost immediately and sure enough, what looked like a valid bci was in the high half of the loaded value. The code for jsr looked like it did the right thing when it transferred control to its target, i.e., stored the bci as a 64-bit value. On a hunch I ran with -XX:+TraceDeoptimize -XX:+Verbose. The +Verbose dumps the values that are restored to the interpreter locals and stack slots. That dump showed deopt restoring the wrong value to the local used by the ret. 3. Examination of the code for FillLocArray() in opto/output.cpp showed that we were indeed restoring a 32-bit for return addresses rather than restoring a 64-bit value in the _LP64 case. The fix was to create LongValue debugInfo entries instead of IntValue ones. ###@###.### 2002-10-01

01-10-2002