RFR: 8149743: JVM crash after debugger hotswap with lambdas

[serguei.spitsyn at oracle.com]

On 2/22/16 15:44, Daniel D. Daugherty wrote:
> On 2/22/16 1:28 PM, Coleen Phillimore wrote:
>>
>> This fix looks good.   The test looks like it uses some framework I 
>> don't know, in a directory that I don't usually run tests in.
>>
>> We have some redefinition tests in hotspot/test/runtime/RedefineTests 
>> - can you write one with source code there instead?
>
> The redefine tests in the runtime directory are in the wrong place.
>
> JVM/TI RedefineClasses() is a debugging API and jdk/test/com/sun/jdi
> is the usual place for JDI tests that exercise RedefineClasses(). If
> the test is using the Java entry points (JLI/JPLIS), then those tests
> belong in jdk/test/java/lang/instrument. Of course, if the test needs
> to use to JDWP entry point for JVM/TI RedefineClasses(), then those
> tests live in yet another location.

Andreas,

I'm not sure what tests did you run.
It'd be nice to run both the com/sun/jdi and java/lang/instrument tests
to make sure there are no regressions with your fix.


Thanks,
Serguei


>
> Dan
>
>
>>
>> I linked an old bug to this, can you see if they are the same?
>>
>> Thanks,
>> Coleen
>>
>> On 2/18/16 11: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/
>>>
>>> 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
>>
>