RFR: 8149743: JVM crash after debugger hotswap with lambdas

[serguei.spitsyn at oracle.com]

On 2/23/16 07:43, Daniel D. Daugherty wrote:
> On 2/23/16 8:34 AM, Andreas Eriksson wrote:
>>
>> On 2016-02-23 15:11, Daniel D. Daugherty wrote:
>>> On 2/18/16 9:11 AM, Andreas Eriksson wrote:
>>>> Hi,
>>>>
>>>> Please review this fix for JDK-8149743: JVM crash after debugger 
>>>> hotswap with lambdas
>>>> https://bugs.openjdk.java.net/browse/JDK-8149743
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8149743/webrev.00/
>>>
>>> hotspot/src/share/vm/prims/jvmtiRedefineClasses.cpp
>>>     No comments other than please update the copyright before you push.
>>>
>>
>> Will do.
>
> Coleen has a commit script that automatically makes sure that
> the copyrights are updated... She's sent it out before...
>
>
>>
>>>
>>> jdk/test/com/sun/jdi/RedefineAddPrivateMethod.sh
>>>     L76: debuggeeFailIfPresent "Internal exception:"
>>>
>>>     Is the failure mode for this bug always a crash? If so, then
>>>     the above check should work as long as we don't change the
>>>     "Internal exception:" part of the output. If we do that then
>>>     we'll have to update a number of tests... :-)
>>>
>>
>> Yes, it's always a crash/assert. The runit call checks for some 
>> common hs_err output as well, so even if that specific output changes 
>> it should still work.
>
> I had forgotten about that part of TestScaffold. I guess it has
> been too long since I wrote/debugged one of these tests. Sigh...
>
>
>>
>>>
>>> Thumbs up.
>>>
>>> Dan
>>
>> Thanks for the review.
>
> No problem.
>
> Dan
>
> P.S.
> I know there are plans to update/replace this scaffold stuff
> with Java code... any idea on when that might happen? There's
> some tricky stuff in there that dates back to Jim Holmlund
> (and me)... Serguei will also likely remember some of the
> dark twisty passages...

The SQE team wanted to make this change.
But now just one SQE person left that is still covering the Serviceability.
I guess, we do not have cycles at the moment to make it happen.


Thanks,
Serguei


>
>
>>
>> - Andreas
>>
>>>
>>>
>>>>
>>>> When redefining a class to add or delete methods an array that's 
>>>> tracking method ordering is not updated correctly.
>>>> This change swaps the method ordering array between the old class 
>>>> being redefined and the scratch class it is being redefined into at 
>>>> the same point where we swap the methods and constant pool between 
>>>> them.
>>>>
>>>> Regards,
>>>> Andreas
>>>>
>>>
>>
>