RFR(L) : 8199382 : [TESTBUG] Open source VM testbase JDI tests

[Igor Ignatyev]

http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html
> 577169 lines changed: 577169 ins; 0 del; 0 mod; 

Hi all,

could you please review the patch which open sources JDI tests from vm 
testbase? These tests cover different aspects of JDI implementation.

As usually w/ VM testbase code, these tests are old, they have been run in 
hotspot testing for a long period of time. Originally, these tests were run by 
a test harness different from jtreg and had different build and execution 
schemes, some parts couldn't be easily translated to jtreg, so tests might have 
actions or pieces of code which look weird. In a long term, we are planning to 
rework them.

JBS: https://bugs.openjdk.java.net/browse/JDK-8199382
webrev:  http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html
testing: vmTestbase_nsk_jdi test group

Thanks,
-- Igor

Re: 8202466: Test serviceability/tmtools/jstat/GcTest01.java fails: Number of concurrent GC events is 1, but CGCT is 0

[Chris Plummer]

Hi Yasumasa,

Here are my results. I ran the test on macosx-x64-debug 500 times using 
random machines. I saw the failure twice, both times on different 
machines. I then ran 25 times on each of the 3 macosx machines that have 
shown the failure, and did not see it again. So I don't think this is 
necessarily an issue that is more likely to turn up on one macosx 
machine than any other. It's just very intermittent.


I then ran 200 times each on all our supported platforms. So that would 
be both debug and product builds on macosx, linux-x64, solaris-sparc, 
and windows-x64. During those runs it turned up once on linux-x64 
(product, not debug), so this issue does not seem to be limited to macosx.


best regards,

Chris

On 5/3/18 8:26 AM, Chris Plummer wrote:

Hi Yasumasa,

I only see the one reported failure in our recent test history for 
this test, so it doesn't look like it happens every time. I'll try 
running the test on the machine it failed on, both with the binary it 
failed with and a more recent binary.


best regards,

chris

On 5/3/18 4:48 AM, Yasumasa Suenaga wrote:

FYI: jdk-11-ea+11 passed GcTest01.java
https://download.java.net/openjdk/testresults/11/archives/11/diff-hotspot-10-11.txt 




On 2018/05/02 21:46, Yasumasa Suenaga wrote:

Hi all,

I've tried to fix 8202466, but I do not yet certain which solution 
is the best for it.

So I want your opinion for it.

https://bugs.openjdk.java.net/browse/JDK-8202466

David reports serviceability/tmtools/jstat/GcTest01.java failed in 
Mach5. It seems to appear on OS X only.

He has shared jtreg report, and I found as below:

```
stdout: S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC 
FGCT CGC CGCT GCT
  0.0 0.0 0.0 0.0 3072.0 0.0 11264.0 2825.6 9472.0 9003.3 1024.0 
845.3 26 0.204 3 0.292 1 0.000 0.497

```

YGCT: 0.204
FGCT: 0.292
CGCT: 0.000

  GCT: 0.497

I guess this failure was caused by rounding error because (YGCT + 
FGCT + CGCT) < GCT.

CGC is 1, so CGC operation might finish in very short time.


GcTest01.java:
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcTest01.java#l57 



GcCauseTest01.java:
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcCauseTest01.java#l53 



GcTest01 and GcCauseTest01 are very similar, but GcCauseTest01 passed.
Both tests use GcProvoker::provokeGc() to inflate memory usage. So I 
wonder why GcTest01 just only failed.
I guess we might encounter similar issue(s) in the future if we get 
more fast machines.


Hence I think we can take two approaches as below:

   1. Add all tests in serviceability/tmtools/jstat to ProblemList.
   2. Change all JstatGc*Tool to use custom jstat_options - to show 
raw values in PerfCounters



What do you think?
I can start to work for it if they are OK.


Thanks,

Yasumasa

RFR: (S): JDK-8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int

[Jini George]

Hello!

Requesting reviews for:

https://bugs.openjdk.java.net/browse/JDK-8195613

([SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int)

Webrev: http://cr.openjdk.java.net/~jgeorge/8195613/webrev.00/

Testing: The SA tests passed on Mach5.

Thanks,
Jini.

Re: 8202466: Test serviceability/tmtools/jstat/GcTest01.java fails: Number of concurrent GC events is 1, but CGCT is 0

[Chris Plummer]

Hi Yasumasa,

On 5/2/18 5:46 AM, Yasumasa Suenaga wrote:

Hi all,

I've tried to fix 8202466, but I do not yet certain which solution is 
the best for it.

So I want your opinion for it.

https://bugs.openjdk.java.net/browse/JDK-8202466

David reports serviceability/tmtools/jstat/GcTest01.java failed in 
Mach5. It seems to appear on OS X only.

He has shared jtreg report, and I found as below:

```
stdout: S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT 
CGC CGCT GCT
 0.0 0.0 0.0 0.0 3072.0 0.0 11264.0 2825.6 9472.0 9003.3 1024.0 845.3 
26 0.204 3 0.292 1 0.000 0.497

```

YGCT: 0.204
FGCT: 0.292
CGCT: 0.000

 GCT: 0.497

I guess this failure was caused by rounding error because (YGCT + FGCT 
+ CGCT) < GCT.

CGC is 1, so CGC operation might finish in very short time.


GcTest01.java:
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcTest01.java#l57

GcCauseTest01.java:
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcCauseTest01.java#l53

GcTest01 and GcCauseTest01 are very similar, but GcCauseTest01 passed.
Both tests use GcProvoker::provokeGc() to inflate memory usage. So I 
wonder why GcTest01 just only failed.
I guess we might encounter similar issue(s) in the future if we get 
more fast machines.


Hence I think we can take two approaches as below:

  1. Add all tests in serviceability/tmtools/jstat to ProblemList.
I don't think we want to do that at this time since this is a newly 
introduced problem, and is intermittent. So the goal would be to fix it 
in the near term without problem listing it.
  2. Change all JstatGc*Tool to use custom jstat_options - to show raw 
values in PerfCounters

I'm not sure what is meant by this.

thanks,

Chris



What do you think?
I can start to work for it if they are OK.


Thanks,

Yasumasa

Re: 8202466: Test serviceability/tmtools/jstat/GcTest01.java fails: Number of concurrent GC events is 1, but CGCT is 0

[Chris Plummer]

Hi Yasumasa,

I only see the one reported failure in our recent test history for this 
test, so it doesn't look like it happens every time. I'll try running 
the test on the machine it failed on, both with the binary it failed 
with and a more recent binary.


best regards,

chris

On 5/3/18 4:48 AM, Yasumasa Suenaga wrote:

FYI: jdk-11-ea+11 passed GcTest01.java
https://download.java.net/openjdk/testresults/11/archives/11/diff-hotspot-10-11.txt


On 2018/05/02 21:46, Yasumasa Suenaga wrote:

Hi all,

I've tried to fix 8202466, but I do not yet certain which solution is 
the best for it.

So I want your opinion for it.

https://bugs.openjdk.java.net/browse/JDK-8202466

David reports serviceability/tmtools/jstat/GcTest01.java failed in 
Mach5. It seems to appear on OS X only.

He has shared jtreg report, and I found as below:

```
stdout: S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT 
CGC CGCT GCT
  0.0 0.0 0.0 0.0 3072.0 0.0 11264.0 2825.6 9472.0 9003.3 1024.0 
845.3 26 0.204 3 0.292 1 0.000 0.497

```

YGCT: 0.204
FGCT: 0.292
CGCT: 0.000

  GCT: 0.497

I guess this failure was caused by rounding error because (YGCT + 
FGCT + CGCT) < GCT.

CGC is 1, so CGC operation might finish in very short time.


GcTest01.java:
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcTest01.java#l57

GcCauseTest01.java:
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcCauseTest01.java#l53

GcTest01 and GcCauseTest01 are very similar, but GcCauseTest01 passed.
Both tests use GcProvoker::provokeGc() to inflate memory usage. So I 
wonder why GcTest01 just only failed.
I guess we might encounter similar issue(s) in the future if we get 
more fast machines.


Hence I think we can take two approaches as below:

   1. Add all tests in serviceability/tmtools/jstat to ProblemList.
   2. Change all JstatGc*Tool to use custom jstat_options - to show 
raw values in PerfCounters



What do you think?
I can start to work for it if they are OK.


Thanks,

Yasumasa

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

[serguei.spit...@oracle.com]

  
  
Hi Andrew,
  
  Okay, thanks!
  Serguei
  
  
  On 5/3/18 07:18, Andrew Leonard wrote:


  
  Hi Serguei,
  
  I've done some
debug, and there seems to be some difference in behaviour with
Hotspot
with regards the report VM_INIT command, i'm not sure I quite
understand
why... so i'm consulting with a colleague to get some help. 
  
  I'll update the
bug when I have some more information.
  
  Thanks
  
  Andrew
  
  
  Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 
  
  
  
  
  
  From:
       "serguei.spit...@oracle.com"

  
  To:
       Andrew
Leonard 
  
  Cc:
       serviceability-dev@openjdk.java.net
  
  Date:
       24/04/2018
01:47
  
  Subject:
       Re:
RFR: 8201409: JDWP debugger initialization hangs intermittently
  
  
  
  
  
  The most relevant stack traces from Solaris
pstack dump are:

  12 -  lwp# 2 / thread# 2  
  13  7eae9b3c lwp_cond_wait (100123448, 100123430, 0,
0)
  14  fffd12331a94 void os::PlatformEvent::park()
(100123400,
e6c40, e6c00, 0, fffd12adbf00, 100123430) + c4
  15  fffd122c6038 int Monitor::IWait(Thread*,long)
(100122f30,
100122000, 0, fffd12b4dba8, 0, 100122f50) + 98
  16  fffd122c6a4c bool Monitor::wait(bool,long,bool)
(100122f30,
1, 0, 0, 2155, 100122000) + 7c
  17  fffd125464e8 int JavaThread::java_suspend_self()
(100122000,
1, 4000, 1001220b8, 100122f30, 100122f30) + a8
  18  fffd120c84a4 int
JvmtiRawMonitor::raw_wait(long,bool,Thread*)
(10079e3b0, 10079e430, 1, 100122000, 94400, fffd12b70600) +
254
  19  fffd120942ec jvmtiError
JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long)
(4, 10079e3b0, , 100122000, 0, fffd12adbf00)
+ 5c
  20  fffd0f8385bc debugMonitorWait (fffd0f946268, c10,
c00, fffd0f945580, fffd0f945580, 0) + 3c
  21  fffd0f825140 enqueueCommand (1007a0a20,
ffefc418,
103800, ffefc3e8, 0, fffd0f945580) + 140
  22  fffd0f826e58 eventHelper_reportEvents (0, 10079a000,
0, 1007a0a20, 1, 1) + 108
  23  fffd0f81b4c0 initialize (1001222e0, c00, 4,
fffd0f83edc0,
fffd0f9460d0, fffd0f945580) + 540
  24  fffd0f81a77c cbEarlyException (fffd0f946190,
1001222e0,
1005953a0, fffd0f83eaa0, fffd0f946268, 1005953a8) + 21c
  25  fffd120af6a4 void
JvmtiExport::post_exception_throw(JavaThread*,Method*,unsigned
char*,oopDesc*) (100122000, fffd12b78f38, 100764b40,
62cb91b50, 100122d48,
fffd12b7a618) + 15b4
  26  fffd11c27484 unsigned
char*InterpreterRuntime::exception_handler_for_exception(JavaThread*,oopDesc*)(0,
4a0014e0, 100122000, 4a001470, 100122d40,
fffd12adbf00)
+ 704
  27  6100eac0 * JITDebug.debugTarget()V+29
  28  61009ecc *
JITDebug.parseArgs([Ljava/lang/String;)Z+50
  29  610084ac * JITDebug.main([Ljava/lang/String;)V+8
  30  610003c0  (7d0ffc20,
7d0ffe30,
a, 4a000f18, 6100ff40, 7d0ffd78) +
fff8006cc46de0b0
  31  fffd11c43134 void
JavaCalls::call_helper(JavaValue*,const
methodHandle&,JavaCallArguments*,Thread*) (7d0ffe28,
4a000f18,
7d0ffd68, 7d0ffde8, e, 61000340) + 2e4
  32  fffd11cfd95c jni_CallStaticVoidMethod (1001222e0,
1400,
1c, 7d0ffde8, 100122000, 153d) + 5bc
  33  fffd12c0603c JavaMain (ac8, 100123780, 100123798, 1,
fffd12b605f0, fffd11cfd3a0) + 81c
  34  7eae4b38 _lwp_start (0, 0, 0, 0, 0, 0)

 216 -  lwp# 18 / thread# 18 

 217  7eae9b3c lwp_cond_wait (10078cd48, 10078cd30, 0,
0)
 218  fffd12331a94 void os::PlatformEvent::park()
(10078cd00,
e6c40, e6c00, 0, fffd12adbf00, 10078cd30) + c4
 219  fffd120c7b00 int
JvmtiRawMonitor::SimpleWait(Thread*,long)
(10078a470, 10079c000, , fffd120c50e0, 1, 0)
+ 

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

[Andrew Leonard]

Hi Serguei,
I've done some debug, and there seems to be some difference in behaviour 
with Hotspot with regards the report VM_INIT command, i'm not sure I quite 
understand why... so i'm consulting with a colleague to get some help. 
I'll update the bug when I have some more information.
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   "serguei.spit...@oracle.com" 
To: Andrew Leonard 
Cc: serviceability-dev@openjdk.java.net
Date:   24/04/2018 01:47
Subject:Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently



The most relevant stack traces from Solaris pstack dump are:

  12 -  lwp# 2 / thread# 2  
  13  7eae9b3c lwp_cond_wait (100123448, 100123430, 0, 0)
  14  fffd12331a94 void os::PlatformEvent::park() (100123400, e6c40, 
e6c00, 0, fffd12adbf00, 100123430) + c4
  15  fffd122c6038 int Monitor::IWait(Thread*,long) (100122f30, 
100122000, 0, fffd12b4dba8, 0, 100122f50) + 98
  16  fffd122c6a4c bool Monitor::wait(bool,long,bool) (100122f30, 1, 
0, 0, 2155, 100122000) + 7c
  17  fffd125464e8 int JavaThread::java_suspend_self() (100122000, 1, 
4000, 1001220b8, 100122f30, 100122f30) + a8
  18  fffd120c84a4 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) 
(10079e3b0, 10079e430, 1, 100122000, 94400, fffd12b70600) + 254
  19  fffd120942ec jvmtiError 
JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (4, 10079e3b0, 
, 100122000, 0, fffd12adbf00) + 5c
  20  fffd0f8385bc debugMonitorWait (fffd0f946268, c10, c00, 
fffd0f945580, fffd0f945580, 0) + 3c
  21  fffd0f825140 enqueueCommand (1007a0a20, ffefc418, 
103800, ffefc3e8, 0, fffd0f945580) + 140
  22  fffd0f826e58 eventHelper_reportEvents (0, 10079a000, 0, 
1007a0a20, 1, 1) + 108
  23  fffd0f81b4c0 initialize (1001222e0, c00, 4, fffd0f83edc0, 
fffd0f9460d0, fffd0f945580) + 540
  24  fffd0f81a77c cbEarlyException (fffd0f946190, 1001222e0, 
1005953a0, fffd0f83eaa0, fffd0f946268, 1005953a8) + 21c
  25  fffd120af6a4 void 
JvmtiExport::post_exception_throw(JavaThread*,Method*,unsigned 
char*,oopDesc*) (100122000, fffd12b78f38, 100764b40, 62cb91b50, 
100122d48, fffd12b7a618) + 15b4
  26  fffd11c27484 unsigned 
char*InterpreterRuntime::exception_handler_for_exception(JavaThread*,oopDesc*) 
(0, 4a0014e0, 100122000, 4a001470, 100122d40, 
fffd12adbf00) + 704
  27  6100eac0 * JITDebug.debugTarget()V+29
  28  61009ecc * JITDebug.parseArgs([Ljava/lang/String;)Z+50
  29  610084ac * JITDebug.main([Ljava/lang/String;)V+8
  30  610003c0  (7d0ffc20, 7d0ffe30, a, 
4a000f18, 6100ff40, 7d0ffd78) + fff8006cc46de0b0
  31  fffd11c43134 void JavaCalls::call_helper(JavaValue*,const 
methodHandle&,JavaCallArguments*,Thread*) (7d0ffe28, 
4a000f18, 7d0ffd68, 7d0ffde8, e, 61000340) 
+ 2e4
  32  fffd11cfd95c jni_CallStaticVoidMethod (1001222e0, 1400, 1c, 
7d0ffde8, 100122000, 153d) + 5bc
  33  fffd12c0603c JavaMain (ac8, 100123780, 100123798, 1, 
fffd12b605f0, fffd11cfd3a0) + 81c
  34  7eae4b38 _lwp_start (0, 0, 0, 0, 0, 0)

 216 -  lwp# 18 / thread# 18  
 217  7eae9b3c lwp_cond_wait (10078cd48, 10078cd30, 0, 0)
 218  fffd12331a94 void os::PlatformEvent::park() (10078cd00, e6c40, 
e6c00, 0, fffd12adbf00, 10078cd30) + c4
 219  fffd120c7b00 int JvmtiRawMonitor::SimpleWait(Thread*,long) 
(10078a470, 10079c000, , fffd120c50e0, 1, 0) + 100
 220  fffd120c8328 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) 
(10078a470, , 1, 10079c000, ffd880ac, 
fffd12adbf00) + d8
 221  fffd120942ec jvmtiError 
JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (4, 10078a470, 
, 10079c000, 0, fffd12adbf00) + 5c
 222  fffd0f8385bc debugMonitorWait (fffd0f946268, c10, c00, 
fffd0f945580, fffd0f946190, 0) + 3c
 223  fffd0f81adac debugInit_waitVMInitComplete (0, f28, 
fffd0f945580, c00, fffd0f844888, 1) + 3c
 224  fffd0f81caac debugLoop_run (105c00, f50, fffd0f945580, 1, 
fffd0f9464d0, 0) + 6c
 225  fffd0f8335b4 connectionInitiated (fffd0f705250, 1000, 1, 
fffd0f945580, fffd0f9468d8, 0) + e4
 226  fffd0f833800 acceptThread (0, fffd0f705260, 1007973c0, 
fffd0f843de0, fffd0f945580, fffd0f946190) + 110
 227  fffd120c0934 void JvmtiAgentThread::call_start_function() 
(10079c000, 0, 0, fffd12adbf00, fffd12b78f38, 0) + 1b4
 228  fffd125445fc void JavaThread::thread_main_inner() (10079c000, 
3d8, 1005bd3f8, 

Re: 8202466: Test serviceability/tmtools/jstat/GcTest01.java fails: Number of concurrent GC events is 1, but CGCT is 0

[Yasumasa Suenaga]

FYI: jdk-11-ea+11 passed GcTest01.java
  
https://download.java.net/openjdk/testresults/11/archives/11/diff-hotspot-10-11.txt


On 2018/05/02 21:46, Yasumasa Suenaga wrote:

Hi all,

I've tried to fix 8202466, but I do not yet certain which solution is the best 
for it.
So I want your opinion for it.

https://bugs.openjdk.java.net/browse/JDK-8202466

David reports serviceability/tmtools/jstat/GcTest01.java failed in Mach5. It 
seems to appear on OS X only.
He has shared jtreg report, and I found as below:

```
stdout: S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT CGC CGCT 
GCT
  0.0 0.0 0.0 0.0 3072.0 0.0 11264.0 2825.6 9472.0 9003.3 1024.0 845.3 26 0.204 
3 0.292 1 0.000 0.497
```

YGCT: 0.204
FGCT: 0.292
CGCT: 0.000

  GCT: 0.497

I guess this failure was caused by rounding error because (YGCT + FGCT + CGCT) 
< GCT.
CGC is 1, so CGC operation might finish in very short time.


GcTest01.java:
   
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcTest01.java#l57

GcCauseTest01.java:
   
http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcCauseTest01.java#l53

GcTest01 and GcCauseTest01 are very similar, but GcCauseTest01 passed.
Both tests use GcProvoker::provokeGc() to inflate memory usage. So I wonder why 
GcTest01 just only failed.
I guess we might encounter similar issue(s) in the future if we get more fast 
machines.

Hence I think we can take two approaches as below:

   1. Add all tests in serviceability/tmtools/jstat to ProblemList.
   2. Change all JstatGc*Tool to use custom jstat_options - to show raw values 
in PerfCounters


What do you think?
I can start to work for it if they are OK.


Thanks,

Yasumasa