Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth)

2019-07-04 Thread David Holmes
Hi Daniil, Sorry I found it harder to get to this this week than I would have hoped, so I've asked a couple of other runtime folk to please take a look while I'm on vacation. I do have some comments though. First, you've based this off the ResolvedMethodTable code and it isn't clear to me

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread Yasumasa Suenaga
On 2019/07/05 6:44, David Holmes wrote: On 5/07/2019 7:41 am, Chris Plummer wrote: On 7/4/19 2:07 PM, David Holmes wrote: I'm not aware of any automatic doc updating process driven by the CSR. If there is a doc task to be done then a specific task needs to be created for it. In this case

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread Yasumasa Suenaga
Hi Chris, On 2019/07/05 4:24, Chris Plummer wrote: Hi Yasumasa, On 7/4/19 5:30 AM, Yasumasa Suenaga wrote: Hi Chris, Thank you for your review. On 2019/07/04 8:07, Chris Plummer wrote: Hi Yasumasa, Overall these changes look good, but I think there is a bit of cleanup still needed.

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread David Holmes
On 5/07/2019 7:41 am, Chris Plummer wrote: On 7/4/19 2:07 PM, David Holmes wrote: I'm not aware of any automatic doc updating process driven by the CSR. If there is a doc task to be done then a specific task needs to be created for it. In this case it is the manpage for jhsdb that needs to

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread Chris Plummer
On 7/4/19 2:07 PM, David Holmes wrote: Hi Chris, On 5/07/2019 5:24 am, Chris Plummer wrote: Hi Yasumasa, On 7/4/19 5:30 AM, Yasumasa Suenaga wrote: Hi Chris, Thank you for your review. On 2019/07/04 8:07, Chris Plummer wrote: Hi Yasumasa, Overall these changes look good, but I think

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread David Holmes
Hi Chris, On 5/07/2019 5:24 am, Chris Plummer wrote: Hi Yasumasa, On 7/4/19 5:30 AM, Yasumasa Suenaga wrote: Hi Chris, Thank you for your review. On 2019/07/04 8:07, Chris Plummer wrote: Hi Yasumasa, Overall these changes look good, but I think there is a bit of cleanup still needed.

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread Chris Plummer
Hi Yasumasa, On 7/4/19 5:30 AM, Yasumasa Suenaga wrote: Hi Chris, Thank you for your review. On 2019/07/04 8:07, Chris Plummer wrote: Hi Yasumasa, Overall these changes look good, but I think there is a bit of cleanup still needed. You've changed the indentation of the help to always

RFR: 8225690: Multiple AttachListener threads can be created

2019-07-04 Thread Yasumasa Suenaga
Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8225690 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/webrev.00/ This issue has been discussed on [1] and [2]. This webrev passed tests on submit repo (mach5-one-ysuenaga-JDK-8225690-20190704-1214

Re: Slow class loading when running JVM in debug mode

2019-07-04 Thread Egor Ushakov
I filed https://bugs.openjdk.java.net/browse/JDK-8227269. Not sure that we could fix that ourselves. Egor On 21-Jun-19 21:50, Chris Plummer wrote: You might also want to have a look at: JDK:8214892: Delayed starting of debugging via jcmd This should allow you to defer initialization of the

Re: PING: RFR: 8209790: SA tools not providing option to connect to debug server

2019-07-04 Thread Yasumasa Suenaga
Hi Chris, Thank you for your review. On 2019/07/04 8:07, Chris Plummer wrote: Hi Yasumasa, Overall these changes look good, but I think there is a bit of cleanup still needed. You've changed the indentation of the help to always have a few spaces before the /t. If you are going to do

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

2019-07-04 Thread David Holmes
Hi Erik, On 4/07/2019 6:08 pm, Erik Österlund wrote: Hi David, When you run without TLH, this copying mechanism is used to synchronize the safepoint while JavaThreads are running. The interpreter doesn't emit any polls then. Instead it clobbers the dispatch table. JavaThreads will be

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

2019-07-04 Thread Erik Österlund
Hi David, When you run without TLH, this copying mechanism is used to synchronize the safepoint while JavaThreads are running. The interpreter doesn't emit any polls then. Instead it clobbers the dispatch table. JavaThreads will be reading from the dispatch table while it is being

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

2019-07-04 Thread David Holmes
PS. I just noticed this comment: // This change must always be occur when at a safepoint. // Being at a safepoint causes the interpreter to use the // safepoint dispatch table which we overload to find single // step points. Just to be sure that it has been set, we // call notice_safepoints

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

2019-07-04 Thread David Holmes
Hi Erik, On 4/07/2019 5:10 pm, Erik Österlund wrote: Hi Dan, Thanks for picking this up. The change looks good. However, when reviewing this, I looked at the code for actually restoring the table (ignore/notice safepoints). It copies the dispatch table for the interpreter. There is a

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

2019-07-04 Thread Erik Österlund
Hi Dan, Thanks for picking this up. The change looks good. However, when reviewing this, I looked at the code for actually restoring the table (ignore/notice safepoints). It copies the dispatch table for the interpreter. There is a comment stating it is important the copying is atomic for

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

2019-07-04 Thread David Holmes
Hi Dan, On 4/07/2019 12:04 pm, Daniel D. Daugherty wrote: Greetings, Robbin recently discovered this issue with Thread Local Handshakes. Since he's not available at the moment, I'm handling the issue:     JDK-8227117 normal interpreter table is not restored after single stepping with TLH  

Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code

2019-07-04 Thread David Holmes
Hi Daniil, On 4/07/2019 1:04 pm, Daniil Titov wrote: Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents