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

[Tom Rodriguez]

On May 11, 2011, at 2:28 PM, Vladimir Kozlov wrote:

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

That was a leftover from an alternate attempt to fix this.  I've deleted it.  The UnrollInfo version is the one that's used.  Thanks!

tom

> 
> 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.