[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8149743: JVM crash after debugger hotswap with lambdas
From:       Andreas Eriksson <andreas.eriksson () oracle ! com>
Date:       2016-02-23 16:02:20
Message-ID: 56CC828C.30708 () oracle ! com
[Download RAW message or body]



On 2016-02-23 16:54, Coleen Phillimore wrote:
>
>
> 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

Great, thanks.
Also, I closed the bug you linked as a duplicate.

- Andreas

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

[prev in list] [next in list] [prev in thread] [next in thread]