RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION

[Mikael Vidstedt]

It was indeed a fun one! Vladimir/Chris/Igor - thanks for the reviews!

Cheers,
Mikael

On 2013-10-31 17:49, Igor Veresov wrote:
> That was a fun one! Looks good.
>
> igor
>
> On Oct 31, 2013, at 4:09 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>
>> Please review:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026775
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/
>>
>> Exec summary:
>>
>> The stack banging code in the UncommonTrapBlob is not pre-touching all the stack shadow pages as it should. The result is that under some circumstances it may leave unmapped "holes" on the stack, and when a compiled method later touches a stack page on the other side of the hole Windows will raise an exception because it requires all stack pages to be touched/mapped in order.
>>
>>
>> Details:
>>
>> The code in MacroAssembler::bang_stack_size() is supposed to generate code which touches enough stack pages to make room for the interpreter frame for the deoptimized method and then touch an additional StackShadowPages pages. However, the code fails to do this because:
>>
>> a) it touches the same page twice (the last page touched in the first loop is the exact same address touched the first time in the second loop), and
>> b) it doesn't loop all the way up to *and including* StackShadowPages (the "-1" is incorrect, and so is the less than)
>>
>> The corresponding code in AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all pages from 1 page below sp all the way down to StackShadowPages below sp *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same behavior.
>>
>> Cheers,
>> Mikael
>>