RFR(S): 8231288: "jhsdb jmap" test needed to reproduce issues that used to be reproduced by JShellHeapDumpTest
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Wed Oct 2 23:32:23 UTC 2019
Hi Chris,
It looks good.
Thanks,
Serguei
On 10/2/19 08:31, Chris Plummer wrote:
> Ping!
>
> I updated the webrev to actually exclude any 8196969 reference in
> ProblemList.txt.
>
> https://bugs.openjdk.java.net/browse/JDK-8231288
> http://cr.openjdk.java.net/~cjplummer/8231288/webrev.01/index.html
>
> thanks,
>
> Chris
>
> On 10/1/19 9:52 AM, Chris Plummer wrote:
>> On 10/1/19 2:59 AM, Severin Gehwolf wrote:
>>> Hi Chris,
>>>
>>> On Mon, 2019-09-30 at 12:59 -0700, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> Please review the following:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8231288
>>>> http://cr.openjdk.java.net/~cjplummer/8231288/webrev.00/index.html
>>>>
>>>> There were a number of jmap issues that JShellHeapDumpTest.java
>>>> used to
>>>> reproduce that went away with the fixes for JDK-8228625 because these
>>>> fixes bring the jshell process to an idle state. This new test gets
>>>> rid
>>>> of the Thread.sleep(2000) that JShellHeapDumpTest.java does, making it
>>>> so the jshell process is still active during the jmap heap dump. The
>>>> helps to reproduce 4 other jmap bugs for which there are open CRs
>>>> already filed. This new test has to be problem listed as a results.
>>>> Note I left mention of JDK-8196969 out of the problemlist because a
>>>> fix
>>>> for it is about to be pushed by someone else, and I don't want
>>>> either of
>>>> us to have to deal with timing issues for which CR gets pushed first.
>>> Speaking of JDK-8196969 it is still being mentioned:
>>>
>>> +sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
>>> 8231635,8231634,8196969 generic-all
>>>
>>> I guess that's intentional?
>> Ah, I must have removed it after I created the webrev and before I
>> sent out this RFR. It's not in my current sources.
>>
>> thanks,
>>
>> Chris
>>> Thanks,
>>> Severin
>>>
>>
>
More information about the serviceability-dev
mailing list