Re: INCLUDE_SA/serviceability agent - support on s390x
Hi Matthias, Your change looks good to me. It might make sense to also remove the following lines from: src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h 78 #if defined(s390x) 79 #include 80 #endif I am not sure if the following files are required either: src/hotspot/cpu/s390/vmStructs_s390.hpp src/hotspot/os_cpu/linux_s390/vmStructs_linux_s390.hpp Thanks, Jini (Not a Reviewer). On 4/23/2018 5:31 PM, 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: 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, 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
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 -Xdump:heap:events=gpf+abort+traceassert+corruptcache -Xfut
Re: RFR: 8201409: JDWP debugger initialization hangs intermittently
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 that the JCK test harness starts the target process,
Re: RFR(XS): JDK-8202155: quarantine test com/sun/jdi/JdbExprTest.sh on all platforms
+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
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
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
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
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
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
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
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