JDK-4915922 : vmark failed with tiger b16/17 on solaris sparc 64 bits
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_04,5.0
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_9
  • CPU: generic,sparc
  • Submitted: 2003-09-02
  • Updated: 2004-06-25
  • Resolved: 2003-10-07
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_06 06Fixed
Description
On jtg-e250-4.sfbay, ( SunOS jtg-e250-4 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-250)  with tiger b16/17, vmark failed within 2 hours when running
with -d64.

The failure is reproducible.

Error message:
Unexpected Signal: 11 at pc=0xffffffff3900b8e0, pid=1514, tid=0
An error has just occurred.
To debug, use 'dbx - 1514'; then switch to thread t@0

To reproduce the failure:
1. telnet to jtg-e250-4 as root
2. export JAVA_HOME=<your java home>
3. execute the script
/net/jtgb4u4c/export/sail8/bigapps/tests/runvmark.ksh -d64
4. log files are under /bt/volanomark*

###@###.### 2003-09-02

The failure is reproducible with tiger b18.
The failure is NOT reproducilble when running with -server

###@###.### 2003-09-03
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic tiger FIXED IN: 1.4.2_06 tiger INTEGRATED IN: 1.4.2_06 tiger tiger-b22 VERIFIED IN: tiger-beta
08-07-2004
EVALUATION The bug is in the following code produced by InterpreterGenerator::generate_fixed_frame(): 0xffffffff38c0b914: add %o2, 0x8, %o2 0xffffffff38c0b918: cmp %o2, %o1 0xffffffff38c0b91c: bleu,a,pt %icc,0xffffffff38c0b914 0xffffffff38c0b920: stx %g0, [%o2] <<<< SEGV here 0xffffffff38c0b924: mov 0x1, %g3 This code zeroes out the local variables when creating an interpreter frame. However the branch instruction is incorrect on 64-bit SPARC. It should test the %xcc condition codes instead of the %icc condition codes. This bug will cause problems in the very rare situation when the region being zeroed crosses a 4 Gb boundary. The fix is to change this instruction to use the %xcc condition codes on 64-bit sparc. I will check for other cases of this type of error in the other generated code. ###@###.### 2003-09-18 My analasis above of when this bug will cause a problem is not quite correct. A problem occurs when the region being zeroed is at the end of, or crosses a 4 Gb boundary. If the LSW of the address of end of the memory region is 0xfffffff8, the loop does not properly terminate and zeroes memory far beyond the the intended region (this is the cause of the SEGV.) If the region crosses a 4 Gb boundary, the loop will not execute at all. ###@###.### 2003-09-22
22-09-2003