RFR(S): 8231288: "jhsdb jmap" test needed to reproduce issues that used to be reproduced by JShellHeapDumpTest

Chris Plummer chris.plummer at oracle.com
Wed Oct 2 15:31:16 UTC 2019


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