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 );
   1508
   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);
   1575
   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) 
======================================================================