PopAsynchronousTest case fails in latest hotspot jvm. The jvm crashes with
SEGV or SIGBUS.


###@###.### 2002-04-08


The problem is VM is crashing in invokevirtual helper due to bad Lesp.

  __ ld_ptr(Rrecv, base + vtableEntry::method_offset_in_bytes(), Gmethod);
  
  The Rrecv is either a bad address or misaligned address. So we get SEGV or SIGBUS.
  

I do not know how Lesp set up is done. If it is executing in pure -Xint mode the
Lesp is never get bad. Beacuse it is switching from compiled frame to interpreted
frame the Lesp got bad I think. I think as a part of deoptimization unpack_frame
process the Lesp should be setup for the interpreted frames. Correct me if I am
wrong.

This is what is happening in the testcase when the first PopFrame request
is pending:

Stack trace:
0xf9c8fc58() <==== Deoptimized frames
0xf9c8fc58()
0xf9c8fc58()


Before Unpack_frames:
0xf9c0c778()
0xdead0001()
0xdead0001()
0xf9c8fc58()
0xf9c8fc58()

After unpack frames:
0xf9c0c778()
0xf9c06570() <=== deopt entry ( Now it is Interpreted frames )
0xf9c0652c() <=== return entry ( Now it is Interpreted frames )
0xf9c8fc58()
0xf9c8fc58()


After unpack frames it deopt entry code starts executing and it will
enter the code in generate_throw_exception for actual frame pop and
deopt entry get poped off here and returns to the return entry frame.


After FramePop:
0xf9c0652c() <=== return entry ( Now it is Interpreted frames )
0xf9c8fc58()
0xf9c8fc58()


If the return entry starts executing and if the next byte code instruction
is invokevirtual then it will crash in that code because the Lesp is
not set up correctly as per the interpreter calling convention at this time.

I do not know when and how the Lesp should be set up. I feel deoptimization
unpack_frames should do it or popframe should set this Lesp. How to fix Lesp
is not clear to me.




I think we have another problem with save params and retrieve params.

After unpack frames:
0xf9c0652c() <=== return entry ( say maps to java method foo() of class X )
0xf9c8fc58() <=== deoptimization handler
0xf9c8fc58()

If a PopFrame request is pending at this time and deoptimized_caller bit
is set the popframe code in generate_throw_exception saves the
parameter of current return entry point frame and then this frame
get popped off from the stack and return it to deoptimized handler frame.
Now popframe_processing_bit_mask is set in popframe_condition_addr.

Now deoptimized handler unpacks the vframe so:

After unpack frames:
0xf9c8fc58() <=== deoptimization handler
0xf9c04570() <=== deopt entry (say maps to java method bar() of class Y)
0xf9c0652c() <=== return entry
0xf9c8fc58()

After unpack frame the HOTSWAP code in deoptimized handler removes the
deopt entry frame and restore the previously saved params. This is
some thing does not look right to me. Now it has replaced the
java method bar() of class Y parameter got replaced with parameters
of foo() of class X.

See this code in c1_Runtime1_sparc.cpp

 __ restore() // Get out of the deoptimization handler frame
 
 This line of code removes the deopt entry frame and then do
 retrieving of params and then dispatch next byte code.

If we can figure out how to set up the Lesp then we can easily
fix this I think.



Also we should check if the fix for bug 4646985. This may be related
to this problem. Please check with Ken.

Thanks,
Swamy