Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

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

  
  
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, 1005bd020, 48cffbb8,
  fffd12bb62a0) + 8c
   229  fffd12544534 void JavaThread::run() (10079c000, b, 12,
  62cb92b48, 0, 22) + 4a4
   230  fffd12324ca0 thread_native_entry (0, 10079c000, 0,
  10079c9d0, fffd12adbf00, 50dc) + 320
  

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

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

  
  
On 4/23/18 16:08,
  serguei.spit...@oracle.com wrote:


  
  Hi Andrew,

There is a regression with this fix.
The following test is failed with timeout on all platforms
except Windows:
  


Sorry, forgot to copy the test name:
  open/test/jdk/com/sun/jdi/JITDebug.sh


Thanks,
Serguei



   I'll try to get more details about
this timeout.

Thanks,
Serguei


On 4/18/18 09:49, serguei.spit...@oracle.com wrote:
  
  
Hi Andrew,
  
  Sorry, I did not reply earlier.
  The fix need more testing. We also have some important tests
  in closed.
  I'll run them but I'm a little bit busy at the moment.
  
  You have two reviews which is enough for push after testing.
  
  Thanks,
  Serguei
  
  
  On 4/18/18 08:23, Andrew Leonard wrote:


  Hi Serguei, 
  Do you need me to try anything else for this review?
hotspot/jtreg/serviceability suite run successfully.
  
  Many 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:        daniel.daughe...@oracle.com,
Andrew Leonard 
  
  Cc:        serviceability-dev@openjdk.java.net
  
  Date:        16/04/2018 07:10 
  Subject:        Re: RFR: 8201409: JDWP
debugger initialization hangs intermittently 
   
  
  
  On 4/15/18 10:01, Daniel D. Daugherty wrote: 
  On 4/13/18 3:07 PM, serguei.spit...@oracle.com
wrote: 
  Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that
includes the bug number.

The issues is:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
  http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/
  
   
  src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
      No comments.
  
  src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
      No comments.
  
  src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
      So now pauses in debugLoop_run() before the loop
      that reads cmds. Looks good.
  
  src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
      So the VM_INIT event handler now signals that we have
      received the VM_INIT event so that allows
  debugLoop_run()
      to proceed.
  
  Serguei, this fix needs to have the most of the
  Serviceability
  stack of tests run against it (jdwp, JVM/TI, JDI and jdb
  tests).
  Based on the email thread, I can't tell which tests have
  been
  run with the fix in place. 
  
Hi Dan,

I'm going to sponsor this fix and will run all the debugger
tests.
Sorry that I did not announce it yet.

Thanks,
Serguei
   
  
  Dan
 
  

The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for
this issue is not easy.

At least, one more review is needed before the fix can be
pushed.

Thanks,
Serguei


On 4/11/18 06:33, Andrew Leonard wrote: 
  Hi Serguei, 
Thank you for raising the bug. 
I had a chat with one of my colleagues who could recreate
it, and it's probably related to the handshaking that is
done in the particular scenario. So with the JCK harness: 

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64
/projects/jck/jdwp/j2sdk-image/bin/java
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache
-Xdump:heap:none 

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

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

  
  
Hi Andrew,
  
  There is a regression with this fix.
  The following test is failed with timeout on all platforms except
  Windows.
  I'll try to get more details about this timeout.
  
  Thanks,
  Serguei
  
  
  On 4/18/18 09:49, serguei.spit...@oracle.com wrote:


  
  Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests in
closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei


On 4/18/18 08:23, Andrew Leonard wrote:
  
  
Hi Serguei, 
Do you need me to try anything else for this review?
  hotspot/jtreg/serviceability suite run successfully. 
Many 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:        daniel.daughe...@oracle.com,
  Andrew Leonard 

Cc:        serviceability-dev@openjdk.java.net

Date:        16/04/2018 07:10 
Subject:        Re: RFR: 8201409: JDWP
  debugger initialization hangs intermittently 
 


On 4/15/18 10:01, Daniel D. Daugherty wrote: 
On 4/13/18 3:07 PM, serguei.spit...@oracle.com
  wrote: 
Andrew and reviewers,
  
  I'm re-sending this RFR with a corrected subject that includes
  the bug number.
  
  The issues is:
    https://bugs.openjdk.java.net/browse/JDK-8201409
  
  Webrev:
    http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/

 
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
    No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
    No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
    So now pauses in debugLoop_run() before the loop
    that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
    So the VM_INIT event handler now signals that we have
    received the VM_INIT event so that allows
debugLoop_run()
    to proceed.

Serguei, this fix needs to have the most of the
Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb
tests).
Based on the email thread, I can't tell which tests have
been
run with the fix in place. 

  Hi Dan,
  
  I'm going to sponsor this fix and will run all the debugger
  tests.
  Sorry that I did not announce it yet.
  
  Thanks,
  Serguei
 

Dan
   

  
  The fix looks good to me.
  Also, I've agreed to skip a unit test as creating it for this
  issue is not easy.
  
  At least, one more review is needed before the fix can be
  pushed.
  
  Thanks,
  Serguei
  
  
  On 4/11/18 06:33, Andrew Leonard wrote: 
Hi Serguei, 
  Thank you for raising the bug. 
  I had a chat with one of my colleagues who could recreate it,
  and it's probably related to the handshaking that is done in
  the particular scenario. So with the JCK harness: 
  
  com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64
  /projects/jck/jdwp/j2sdk-image/bin/java
  -Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache
  -Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache
  -Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache
  -Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache
  -Xfuture
  -agentlib:jdwp=server=y,transport=dt_socket,address=localhost:35000,suspend=y
  -classpath /javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/classes
  -Djava.security.policy=/javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/lib/jck.policy
  javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600
  -msgSwitch=ub1604x64vm10:38636 -componentName=ArrayReference.GetValues.getvalues002
  
  
  Note 

Re: RFR(XS): JDK-8202155: quarantine test com/sun/jdi/JdbExprTest.sh on all platforms

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

+1

Thanks,
Serguei


On 4/23/18 15:01, David Holmes wrote:

Looks good.

Thanks,
David

On 24/04/2018 6:25 AM, Chris Plummer wrote:

Hello,

Please review the following:

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

--
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -738,6 +738,8 @@

  com/sun/jdi/RedefineImplementor.sh 8004127 generic-all

+com/sun/jdi/JdbExprTest.sh 8185803 generic-all
+
  com/sun/jdi/JdbMethodExitTest.sh 8171483 generic-all

  com/sun/jdi/RepStep.java 8043571 generic-all
--

https://bugs.openjdk.java.net/browse/JDK-8185803 was filed last year 
for this failure, but it has rarely turned up since. However, 
starting late last week it seems to fail on every run. Not too sure 
of the reason why, but it should be quarantined until it is figured out.


I plan to push this as a trivial change.

thanks,

Chris

Re: RFR(XS): JDK-8202155: quarantine test com/sun/jdi/JdbExprTest.sh on all platforms

[Chris Plummer]

Thanks!

On 4/23/18 3:01 PM, David Holmes wrote:

Looks good.

Thanks,
David

On 24/04/2018 6:25 AM, Chris Plummer wrote:

Hello,

Please review the following:

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

--
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -738,6 +738,8 @@

  com/sun/jdi/RedefineImplementor.sh 8004127 generic-all

+com/sun/jdi/JdbExprTest.sh 8185803 generic-all
+
  com/sun/jdi/JdbMethodExitTest.sh 8171483 generic-all

  com/sun/jdi/RepStep.java 8043571 generic-all
--

https://bugs.openjdk.java.net/browse/JDK-8185803 was filed last year 
for this failure, but it has rarely turned up since. However, 
starting late last week it seems to fail on every run. Not too sure 
of the reason why, but it should be quarantined until it is figured out.


I plan to push this as a trivial change.

thanks,

Chris

Re: RFR(XS): JDK-8202155: quarantine test com/sun/jdi/JdbExprTest.sh on all platforms

[David Holmes]

Looks good.

Thanks,
David

On 24/04/2018 6:25 AM, Chris Plummer wrote:

Hello,

Please review the following:

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

--
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -738,6 +738,8 @@

  com/sun/jdi/RedefineImplementor.sh 8004127 generic-all

+com/sun/jdi/JdbExprTest.sh 8185803 generic-all
+
  com/sun/jdi/JdbMethodExitTest.sh 8171483 generic-all

  com/sun/jdi/RepStep.java 8043571 generic-all
--

https://bugs.openjdk.java.net/browse/JDK-8185803 was filed last year for 
this failure, but it has rarely turned up since. However, starting late 
last week it seems to fail on every run. Not too sure of the reason why, 
but it should be quarantined until it is figured out.


I plan to push this as a trivial change.

thanks,

Chris

RFR(XS): JDK-8202155: quarantine test com/sun/jdi/JdbExprTest.sh on all platforms

[Chris Plummer]

Hello,

Please review the following:

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

--
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -738,6 +738,8 @@

 com/sun/jdi/RedefineImplementor.sh 8004127 generic-all

+com/sun/jdi/JdbExprTest.sh 8185803 generic-all
+
 com/sun/jdi/JdbMethodExitTest.sh 8171483 generic-all

 com/sun/jdi/RepStep.java 8043571 generic-all
--

https://bugs.openjdk.java.net/browse/JDK-8185803 was filed last year for 
this failure, but it has rarely turned up since. However, starting late 
last week it seems to fail on every run. Not too sure of the reason why, 
but it should be quarantined until it is figured out.


I plan to push this as a trivial change.

thanks,

Chris

Re: RFR: 8196325: GarbageCollectionNotificationInfo has same information for before and after

[sangheon.kim]

Hi all,

Can I have a second reviewer please?

Thanks,
Sangheon


On 04/18/2018 04:57 PM, mandy chung wrote:



On 4/19/18 4:52 AM, sangheon.kim wrote:



Webrev:
http://cr.openjdk.java.net/~sangheki/8196325/webrev.1 (full)
http://cr.openjdk.java.net/~sangheki/8196325/webrev.1_to_0/ (inc)


Looks good.

Mandy

Re: INCLUDE_SA/serviceability agent - support on s390x

[Erik Joelsson]

Makes sense to me. Looks good.

/Erik


On 2018-04-23 05:01, Baesken, Matthias wrote:


Hello,   as far as I know  the serviceability agent   is not  
supported on  linux s390x .


However  (unlike  on aix where it is not supported as well) ,  
 INCLUDE_SA=false is not set  in the central configure  m4 files .


Should we set it  ( suggested diff below)  ?

Best regards, Matthias

hg diff

diff -r fcd5df7aa235 make/autoconf/jdk-options.m4

--- a/make/autoconf/jdk-options.m4  Wed Apr 18 11:19:32 2018 +0200

+++ b/make/autoconf/jdk-options.m4  Mon Apr 23 13:46:17 2018 +0200

@@ -238,6 +238,9 @@

   if test "x$OPENJDK_TARGET_OS" = xaix ; then

 INCLUDE_SA=false

   fi

+  if test "x$OPENJDK_TARGET_CPU" = xs390x ; then

+    INCLUDE_SA=false

+  fi

   AC_SUBST(INCLUDE_SA)

# Compress jars

Best regards, Matthias

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

[Alan Bateman]

On 15/04/2018 07:23, mandy chung wrote:



This proposal would allow java agents to migrate from internal API and 
ClassDefiner to be enhanced in the future.


Webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8200559/webrev.00/
I went through the proposed spec/API addition and it looks good. The 
original instrumentation envisaged in JSR 163 was to support data 
collection by tools (profilers, tracing, etc.) and it's not unreasonable 
that such instrumentation would make use of (ideally non-public) helper 
classes that the agent defines into the same run-time package as the 
instrumented class.


The reentrancy issues with transform implementations loading or defining 
new classes is very tricky so I think the proposal to not send the 
auxillary classes through the transformer pipeline is pragmatic. It 
means a small inconsistent with JVM TI but I don't think this matters 
too much.


A minor suggestion is to replace "The transformers can ..."  with 
"Transformers may". The rest of the wording looks good.


-Alan

INCLUDE_SA/serviceability agent - support on s390x

[Baesken, Matthias]

Hello,   as far as I know  the serviceability agent   is not  supported on  
linux s390x .
However  (unlike  on aix where it is not supported as well) ,   
INCLUDE_SA=falseis not set  in the central configure  m4 files .
Should we set it  ( suggested diff below)  ?

Best regards, Matthias


hg diff
diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
--- a/make/autoconf/jdk-options.m4  Wed Apr 18 11:19:32 2018 +0200
+++ b/make/autoconf/jdk-options.m4  Mon Apr 23 13:46:17 2018 +0200
@@ -238,6 +238,9 @@
   if test "x$OPENJDK_TARGET_OS" = xaix ; then
 INCLUDE_SA=false
   fi
+  if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
+INCLUDE_SA=false
+  fi
   AC_SUBST(INCLUDE_SA)
   # Compress jars



Best regards, Matthias