review for 7043461: VM crashes in void LinkResolver::runtime_resolve_virtual_method

[Vladimir Kozlov]

I don't see an usage and initialization of 
vframeArray::_caller_actual_parameters field. Otherwise looks good.

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7043461
> 
> If you want to see these changes against the changeset prior to the original fix look at http://cr.openjdk.java.net/~never/7043461_against_2395.  You'll see some minor differences for intervening changesets but it makes the deoptimization.cpp and templateInterpreter_sparc.cpp changes clearer.
> 
> 7043461: VM crashes in void LinkResolver::runtime_resolve_virtual_method
> Reviewed-by:
> 
> The original fix for 7009361, JSR 292 Invalid value on stack on
> solaris-sparc with -Xcomp, has had a bunch of fallout with several
> follow on fixes.  I'm abandoning the original fix as there are issues
> with how popframe works that I can't easily resolve.  I had originally
> considered a fix that passed the callers notion of the number of
> parameters down the call chain down to layout activation so the
> correct top of stack could be computed but the other fix seemed more
> straightforward and appeared to work ok initially.  I've now gone back
> to that fix.  So I anti-delta'ed the original fix in
> templateInterpreter_sparc.cpp and passed the callers parameters count
> around to all the places it's needed.  This required touching a lot of
> shared code to pass it through.  Each platform had it's own copy of
> the size_activation wrapper and moved that into shared code.  x86
> doesn't have to fix use the new value since they don't attempt to
> place the locals next to the caller stack.  The fix now has no effect
> on how deopt works except in the case where an invokedynamic is on the
> stack.  Tested with all failing test cases from 7009361, 7043461,
> 7042052, and 7043473.  I'm currently running the larger suites that
> those failing tests were part of to ensure there aren't other issues.
>