Re: [PATCH] Windows 32-bit DLL name decoration

On 2018-12-11 18:22, Bob Vandette wrote: Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad functions. Perhaps you should just follow the same procedure for the debug library. #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad@8", "JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS

Re: [PATCH] Windows 32-bit DLL name decoration

On 2018-12-11 18:16, Alexey Ivanov wrote: Hi Simon, Thank you for your comments. The updated webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Indeed, it looks much cleaner. Yes! This seems like the correct fix. Ship it! :) /Magnus Regards, Alexey On 11/12/2018 16:43, Si

Re: [PATCH] Windows 32-bit DLL name decoration

On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. That's right, an unload wasn't needed when that SPI was originally added but could be added in the event that

RE: RFR (M) 8214892: Delayed starting of debugging via jcmd

Hi, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/21dfea980e23 Best regards Christoph > -Original Message- > From: Langer, Christoph > Sent: Dienstag, 11. Dezember 2018 11:28 > To: Schmelter, Ralf ; Chris Plummer > ; serviceability-dev@openjdk.java.net > Cc: Lindenmaier, Goetz > Subjec

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Thank you very much for looking into this, JC! I have a revised webrev addressing your comments at: http://cr.openjdk.java.net/~jgeorge/8202884/webrev.02/index.html Requesting one more review for this. My comments inline: On 12/12/2018 2:53 AM, JC Beyler wrote: Hi Jini, I saw a few nits: htt

Re: [PATCH] Windows 32-bit DLL name decoration

On 2018-12-12 12:35, Alan Bateman wrote: On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. That's right, an unload wasn't needed when that SPI was originally

Re: optimize KlassInfoTable size to power of 2

Lgtm, JC. Thanks, Paul From: serviceability-dev on behalf of 臧琳 Date: Tuesday, December 11, 2018 at 6:31 PM To: JC Beyler Cc: "serviceability-dev@openjdk.java.net" Subject: RE: optimize KlassInfoTable size to power of 2 Dear JC, That’s exactly modification I made ☺ Thanks a l

[8u] RFR: 8059038: Create new launcher for SA tools

Hi, Can I get a review of this small 8u enhancement, please? It adds two new launchers for the serviceability agent, one CLI version and one GUI version: $ /bin/clhsdb $ /bin/hsdb The enhancement request has been approved here: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/00825

Re: [PATCH] Windows 32-bit DLL name decoration

On 12/12/2018 12:58, Magnus Ihse Bursie wrote: On 2018-12-12 12:35, Alan Bateman wrote: On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. That's right, an

Re: [PATCH] Windows 32-bit DLL name decoration

Hi Bob, Thank you for the pointers on how the same situation is handled in Hotspot for *_OnLoad* functions. At this time, we're dealing with one symbol only. If other symbols are added in the future, we should definitely use this approach. Regards, Alexey On 11/12/2018 17:22, Bob Vandette

Re: [PATCH] Windows 32-bit DLL name decoration

Hi Simon, I'd like to clarify some points… Please see my comments inline: On 11/12/2018 17:16, Alexey Ivanov wrote: Hi Simon, Thank you for your comments. The updated webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Indeed, it looks much cleaner. Regards, Alexey On 11/12/2018

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

Ali has scanned the code base, he says, “couldn’t find (hopefully tbh) other occurrences of such mismatches.” On 10/12/2018 10:45, Magnus Ihse Bursie wrote: It might be worthwhile to scan the entire code base for JNICALL and verify that we have no more mismatches. In general, JNICALL should be

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

Thank you, Ali, for doing this! On 10/12/2018 21:13, Ali İnce wrote: Hi Alexey, I’ve searched for |GetProcAddress| usages across source code and couldn’t find (hopefully tbh) other occurrences of such mismatches. Regards, Ali

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

Forgot to add the link: On 12/12/2018 16:10, Alexey Ivanov wrote: Ali has scanned the code base, he says, “couldn’t find (hopefully tbh) other occurrences of such mismatches.” http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024358.html On 10/12/2018 10:45, Magnus Ihse Bursie

Re: [8u] RFR: 8059038: Create new launcher for SA tools

On Wed, 12 Dec 2018 at 14:10, Severin Gehwolf wrote: > > Hi, > > Can I get a review of this small 8u enhancement, please? It adds two > new launchers for the serviceability agent, one CLI version and one GUI > version: > > $ /bin/clhsdb > $ /bin/hsdb > > The enhancement request has been approved h

[12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry (was: [PATCH] Windows 32-bit DLL name decoration)

Hi all, I have updated the summary of JDK-8214122 and the subject accordingly. Could you please review the following fix? https://bugs.openjdk.java.net/browse/JDK-8214122 webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ *Root cause* jdwpTransport_OnLoad is exported as _jdwpTransp

Re: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry

On 2018-12-12 17:38, Alexey Ivanov wrote: Hi all, I have updated the summary of JDK-8214122 and the subject accordingly. Could you please review the following fix? https://bugs.openjdk.java.net/browse/JDK-8214122 webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Looks good to

Re: [PATCH] Windows 32-bit DLL name decoration

On 2018-12-12 16:34, Alexey Ivanov wrote: On 12/12/2018 12:58, Magnus Ihse Bursie wrote: On 2018-12-12 12:35, Alan Bateman wrote: On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other)

RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

After some testing with nsk verbose messages enabled, it is clear that this test is failing in checkThreads when the location did not match between the call to GetStackTrace and GetFrameLocation. For the tests that are run when the threads have not been suspended, there is no guarantee the locatio

Re: [PATCH] Windows 32-bit DLL name decoration

On 12/12/2018 16:52, Magnus Ihse Bursie wrote: On 2018-12-12 16:34, Alexey Ivanov wrote: On 12/12/2018 12:58, Magnus Ihse Bursie wrote: On 2018-12-12 12:35, Alan Bateman wrote: On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there

Re: [8u] RFR: 8059038: Create new launcher for SA tools

On Wed, 2018-12-12 at 16:18 +, Andrew Hughes wrote: > On Wed, 12 Dec 2018 at 14:10, Severin Gehwolf wrote: > > > > Hi, > > > > Can I get a review of this small 8u enhancement, please? It adds two > > new launchers for the serviceability agent, one CLI version and one GUI > > version: > > >

Re: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

Hi Gary, The fix looks good to me. Thanks, Daniil On 12/12/18, 8:55 AM, "serviceability-dev on behalf of Gary Adams" wrote: After some testing with nsk verbose messages enabled, it is clear that this test is failing in checkThreads when the location did not match between the call

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

On 12/12/2018 10:47 PM, JC Beyler wrote: Hi Jini, Should your return not be return !found_state instead of false here: 257   if (!found_state) { 258     // Assuming the thread exists. 259     print_error("Could not find the 'State:' string in the /proc/%d/status file\n", pid); 260   } 261   f

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

Agreed. We don't usually do a NSK_COMPLAIN without also failing the test. Among other things, it results in an error message and the fake exception in the log, which become a red herring if there is a real failure later on in the test. Otherwise chang

Re: RFR (M) 8201655: Add thread-enabled support for the Heap Sampling

Looks good to me. --alex On 12/12/2018 11:25, JC Beyler wrote: Thanks both for the review, I fixed both issues and here is the new webrev, let me know what you think: Webrev: http://cr.openjdk.java.net/~jcbeyler/8201655/webrev.06/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201655 Thanks!

Re: RFR (M) 8201655: Add thread-enabled support for the Heap Sampling

LGTM++ Thanks, Serguei On 12/12/18 12:15, Alex Menkov wrote: Looks good to me. --alex On 12/12/2018 11:25, JC Beyler wrote: Thanks both for the review, I fixed both issues and here is the new webrev, let me know what you think: Webrev: http://cr.openjdk.java.net/~jcbeyler/8201655/webrev.0

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

Hi Gary, Looks good in general. Agreed with Jc and Chris the tweak below is reasonable. Thanks, Serguei On 12/12/18 09:25, JC Beyler wrote: Hi Gary, Looks good to me, especi

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Hi Jini, I have a comment for your webrev.02 . You added process_doesnt_exist() to check process / thread liveness from /proc/, but it is not enough. Information of threads (LWP) will be stored in /proc//task/. So you should check /proc//task/status for threads. Thanks, Yasumasa On 2018/1

RE: optimize KlassInfoTable size to power of 2

Thanks Paul for looking into this! Hi All, Can I get more review about this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215228/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215228 Thanks. BRs, Lin From: Hohensee, Paul [mailto:hohen...@amazon.com] Sent: Wednesday, December 1

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Thank you very much for looking into this, Yasumasa! The 'pid' used in process_doesnt_exist() is actually the lwpid of the thread to be attached to. From Pgrab(), we call ptrace_attach() first for the pid at line 448. In which case, we end up calling process_doesnt_exist() through ptrace_att

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Thanks, JC! Will add the comments. Thanks, - Jini. On 12/13/2018 12:09 AM, JC Beyler wrote: Hi Jini, Fair enough, thanks for the explanation. It makes sense to me. I imagine that it is a conservative approach, ie can't find the information then assume still live. Perhaps a small comment ab

RFR (XS) 8215329: Modify ZGC requirement for HeapMonitorThreadTest.java

Hi all, When working on another webrev, I saw this problem: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215329/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215329 (Basically, from what I understood from an email from Per Liden: - @requires !vm.gc.Z -> ZGC is built in the JDK

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Hi Jini, 2018年12月13日(木) 12:14 Jini George : > > Thank you very much for looking into this, Yasumasa! > > The 'pid' used in process_doesnt_exist() is actually the lwpid of the > thread to be attached to. > > From Pgrab(), we call ptrace_attach() first for the pid at line 448. In > which case, we e

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Your webrev.02 looks good to me! Yasumasa 2018年12月13日(木) 14:05 Yasumasa Suenaga : > > Hi Jini, > > 2018年12月13日(木) 12:14 Jini George : > > > > Thank you very much for looking into this, Yasumasa! > > > > The 'pid' used in process_doesnt_exist() is actually the lwpid of the > > thread to be attache

RFR: JDK-8211923- [Testbug] serviceability/sa/ClhsdbFindPC.java ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1

Hi, Pls review the test fix in serviceability/sa/ClhsdbFindPC.java Jira: https://bugs.openjdk.java.net/browse/JDK-8211923 Webrev: http://cr.openjdk.java.net/~sballal/8211923/webrev.00/ I have done the following modifications to the testcase: 1. If jstack output does not contain "LingeredA

Re: RFR: JDK-8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching

Going forward, we should remove the libpthread_db dependency for the threads discovery and only depend on /proc//task/s for this (https://bugs.openjdk.java.net/browse/JDK-8181313). It's great news! I will help you :-) Sure -- and thank you for the review! -Jini.

8215534: [testbug] some jfr test don't check @requires vm.hasJFR

Hi, These tests lack @requires vm.hasJFR, thus they are failing on AIX. http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/ Please review. I will push this to jdk12 as it is a testbug if I miss the RDP deadline. Best regards, Goetz.