RFR: 8149743: JVM crash after debugger hotswap with lambdas

[Coleen Phillimore]

On 2/23/16 10:47 AM, Andreas Eriksson wrote:
>
> On 2016-02-23 10:22, Andreas Eriksson wrote:
>>
>>
>> On 2016-02-23 00:53, Coleen Phillimore wrote:
>>>
>>>
>>> On 2/22/16 6:46 PM, Daniel D. Daugherty wrote:
>>>> Just noticed that this thread did not include the Serviceability
>>>> aliases... JVM/TI belongs to the Serviceability team so...
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 2/22/16 4:44 PM, 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.
>>>
>>> The tests in the runtime directory test runtime changes to support 
>>> redefinition primarily, so are in the right place. They are run with 
>>> JPRT -testset hotspot.  They don't use these other frameworks 
>>> intentionally.
>>>
>>>>>
>>>>> 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.
>>>>>
>>>
>>> Can you or someone from serviceability team review this test then? I 
>>> have no idea what it does and would prefer a test more tailored to 
>>> testing the JVM functionality than jdb commands.
>>
>> Hi,
>>
>> I'll try creating a hotspot only test, but I'm not sure how to 
>> reproduce this without using jdb.
>>
>> - Andreas
>
> Looks like creating a hotspot only test is difficult, the problem only 
> causes obvious problems (a crash) on code paths taken when using 
> JDI/JDB (or JVMTI directly).
>
> Given that the serviceability team have reviewed this I'll go ahead 
> and push this with the test as-is unless you object.

This is fine.  I'm glad someone reviewed the test.

Coleen

>
> Thanks,
> Andreas
>
>>
>>>
>>> Thanks,
>>> Coleen
>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>