A licensee reported the JVM ABENDs in 1.3.1_03(-server) with Internal Error, 

# ShouldNotReachHere()
#
# Error ID: 52454C4F4341544F520E43505001DB

(This code means "src/share/vm/runtime/relocator.cpp, 475".)

Although they can not send the test code, the licensee sent the following
detail report.
Their report also says this will occur in 1.4.X.(and tiger ?).
So, I filed this issue.

==== Their investigation ====

This reported issue occurs in Windows2000 and JDK1.3.1_03(-server).
However, as the following report says, that might not depend on
specific platform and JDK version.

CRASH SCENARIO :

 This issue occurs at rewrite/relocate operation which is achieved at 
 initializing process of byte code interpreter.
 According to our investigation, the source code and functions related to 
 the rewrite/relocate process are as follows.
 
- rewrite :
  - src/share/vm/oops/generateOopMap.cpp
     void GenerateOopMap::do_interpretation()
     void GenerateOopMap::rewrite_refval_conflicts()
     void GenerateOopMap::rewrite_refval_conflict()
     bool GenerateOopMap::rewrite_refval_conflict_inst()
     bool GenerateOopMap::rewrite_load_or_store()
     bool GenerateOopMap::expand_current_instr()
     
- relocate:
  -src/share/vm/runtime/relocator.cpp
    methodHandle Relocator::insert_space_at()
    bool Relocator::handle_code_changes()
    bool ChangeJumpWiden::handle_code_change()
    void Relocator::change_jumps()
    void Relocator::change_jump()
    bool Relocator::handle_jump_widen()
 
The rewrite operation broadens the index area of aload/astore op. code
under some condition.(To insert wide op. code and expand the 1-byte area to
2-bytes area)
When this rewrite operation occurs, the relocate occurs at the same time 
in order to adjust the offset in byte-codes. 
The problem occurs during the change for the branch offset value of "if" 
code in relocate operation. 

Specifically speaking, the branch offset value of goto/jsr can take 65535
as maximun(than's when goto_w/jsr_w is used).
However, the offset of "if" op. code can take 32767(signed int 16 bits) 
as maximum value. If the length of byte code area becomes over 32767 
after the above rewrite operation, there might be the case when the program 
can not branch because of the offset short.

When the conversion from signed 16 bit offset to signed 32 bit offset 
for each  op. code like goto/jsr/if(ex. goto =>goto_w, jsr => jsr_w ) 
is needed and the op. code is "if", this abnormal end occurs in 
Relocator::handle_jump_widen() as Internal error.

=== Their investigation End ======


REQUEST:
 We need a workaround or fix.
 
 
NOTE:
 According to the source code of 1.4.X(and 1.5 ?), the same issue occurs
 possibly.
 ===================================

N/A

The Fujitsu evaluation sounds correct.  An "if" bytecode cannot currently be
rewritten to a wide version, since none exists.  I am working on a relocator
change that will change the code from:
   #1 if <cond> <wide delta>
   #2 <else code>

   #1 if <cont> #2
   #2 goto #4
   #3 goto_w <wide delta>
   #4 <else code>

I don't really have anything to test it on.  Can Fujitsu send a class file
sample?  Or could I send them my changes and have them test them out?  Thanks!

 xxxxx@xxxxx  2003-10-24

I marked this incomplete to get it off the hot list until Fujitsu can try out
the fix I put in "suggested fix".

 xxxxx@xxxxx  2003-11-18

Correction, the new bytecode sequence is:

   #1 if <cond> #3
   #2 goto #4
   #3 goto_w <wide delta>
   #4 <else code>

I have a test case to test it on now and the code is debugged and working.

 xxxxx@xxxxx  2003-12-09

Putback comments:
Several users in the field have been getting the ShouldNotReachHere() from
relocator.cpp because support for the branch destination of "if" bytecodes
could not be widened past a short.

In this fix, I have rewritten the bytecode stream for widening "if" from:

   #1 if <cond> <wide delta>
   #2 <else code>

   #1 if <cont> #3
   #2 goto #4
   #3 goto_w <wide delta>
   #4 <else code>

This has been debugged and tested for a testcase that Mingyao wrote that meets
all the conditions for this rewriting (appropriately placed jsr's and an
if branch needing widening to 32 bits).  I was hoping Fujitsu would test
this out but I never heard from them.

Risk assessment:  This is a corner case, which previously asserted.
There have been lots of customer complaints about this assertion so this
fix should be backported.

Also, fixed was the bitfield length calculation for representing bits for each
bci in basic blocks.  If there was >1 rewriting towards the end of the
method, the bit vector would overflow and assert.

Also fixed:  When pushing jump relocations on the _changes worklist, the delta
offset to use was wrong if the jump relocation was already on the worklist. The
second request was ignored if it had already been relocated. This was wrong
because if the bci delta needed further adjustment, that adjustment was never
made.  This was seen with another of Mingyao's test cases where two branches
needed adjustment and the adjustment of the first (+2) required that the second
delta be further adjusted.  The fix was to scan the worklist and modify the
delta rather than pushing a duplicate request on the list with a delta that
was derived from the original non-adjusted code stream.
See suggested fix for webrev.

 xxxxx@xxxxx  2003-12-19