Name: cl74495 Date: 12/13/2003
We are seeing SEGV's in the generated intepreter in a 64 bit Sparc VM
when the stack frame of an interpreted method contains
the memory location with address 0xfffffffefffffff8 .
We are seeing this when running with -Xmx in the range of 490M
to 600M. We have application native code that is mmap'ing
quite a bit of memory, so the exact -Xmx and number of threads
needed to reproduce this in a simple test program are hard to specify .
The findpc() function says the PC where the SEGV happened is in
method entry point (kind = zerolocals)
In the sources for J2SE 1.4.2.03 ,
in file cpu/sparc/vm/interpreter_sparc.cpp,
in function InterpreterGenerator::generate_asm_interpreter_entry
there is the following code .
1506 __ bind( clear_loop );
1507 __ inc( O2, wordSize );
1509 __ cmp( O2, O1 );
1510 __ br( Assembler::lessEqualUnsigned, true, Assembler::pt, clear_loop );
1511 __ delayed()->st_ptr( init_value, O2, 0 );
The instruction generated by line 1511 is producing a SEGV
and the registers at the point of the SEGV are
o1 = 0xfffffffefffffff8 , o2 = 0xffffffff00002000
To fix this, the "br" at line 1510 should be "brx" .
I did a search for all "__ br(" occurances in sparc code and
after excluding branches with any of
::equal ::zero ::always ::notZero ::notEqual
I find one additional place where I believe "br should be "brx".
We have not seen SEGV at this location yet , which is
in file cpu/sparc/vm/templateTable_sparc.cpp,
in function TemplateTable::fast_linearswitch
1569 // table search
1570 __ bind(loop);
1571 __ cmp(O4, Otos_i);
1572 __ br(Assembler::equal, true, Assembler::pn, found);
1573 __ delayed()->ld(O3, BytesPerInt, O4); // offset -> O4
1574 __ inc(O3, 2 * BytesPerInt);
1576 __ bind(loop_entry);
1577 __ cmp(O2, O3);
1578 __ br(Assembler::greaterUnsigned, true, Assembler::pt, loop);
1579 __ delayed()->ld(O3, 0, O4);
The "br" at line 1578 should be "brx" , I believe , since the cmp
at line 1577 is comparing two pointers .
(Incident Review ID: 230298)