Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions

Hi Paul, Looks much better to me. The other question I have is about the legacy mode. I understand why, from a tool's perspective, having a legacy mode is practical. By doing it this way, we are ensuring we don't break any tools (or at least they can use a flag to be "unbroken") and give time to m

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/18/18 12:27 AM, David Holmes wrote: Hi Dean, On 18/10/2018 2:06 PM, dean.l...@oracle.com wrote: You're right, I missed that.  I think the right thing to do is call current_thread_exiting while holding the Threads_lock. Then we can get rid of the parallel atomic counters.  So, here's o

КАК JDK-8212665: com/sun/jdi/DeferredStepTest.java: jj1 (line 57) - unexpected. lastLine=52, minLine=52, maxLine=55

Hi all, Please review small test fix for https://bugs.openjdk.java.net/browse/JDK-8212665 webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ The test verifies that after "next" command debugger always stops in the position within loops. Each thread has maximum 40 stops

Re: RFR JDK-8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest

Looks good. Chris On 10/18/18 3:26 PM, Alex Menkov wrote: Hi all, please review trivial fix for https://bugs.openjdk.java.net/browse/JDK-8212629 webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_extraBP/webrev/ The fix adds space inside comment to avoid wrong breakpoint parsing (break

RFR JDK-8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest

Hi all, please review trivial fix for https://bugs.openjdk.java.net/browse/JDK-8212629 webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_extraBP/webrev/ The fix adds space inside comment to avoid wrong breakpoint parsing (breakpoint lines are marked as "@{id} breakpoint", where {id} is a

Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions

Thanks for your review, JC. New webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.03/ I updated the copyright date in memoryService.hpp because I forgot to do so in the patch for https://bugs.openjdk.java.net/browse/JDK-8195115. Thomas asked me to fix in it a separate CR, so I’ve reverted

Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD

+1 --alex On 10/17/2018 18:53, JC Beyler wrote: Hi Daniil, It looks good to me. I noticed a tiny nit in TTY.java where you removed an empty line (l171) Thanks! Jc On Wed, Oct 17, 2018 at 5:50 PM Daniil Titov > wrote: Hi Chris, Alex and JC, I cre

Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD

+1 On 10/18/18 4:47 AM, Gary Adams wrote: Back in July, I tried to address the jdb output synchronization problem by buffering the output from commands and events.   http://cr.openjdk.java.net/~gadams/8169718/webrev.01/ The changes were very invasive and only provided a partial solution. Bott

Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Hi Fairoz, I compared the original and the port, it looks good to me, Jc On Thu, Oct 18, 2018 at 12:55 AM Fairoz Matte wrote: > Thanks David, for the review... > > > -Original Message- > > From: David Holmes > > Sent: Thursday, October 18, 2018 1:20 PM > > To: Fairoz Matte ; serviceabil

Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD

Hi Gary, Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then

Bugs in progress

It would be helpful in tracking bugs we are targetting for the current release, if the bug status was kept up to date. An unassigned or lower priority bug is a good candidate to defer. Sometimes bugs are assigned, but there ends up being resource conflicts to complete the effort. I'd like to ask

Re: RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt

No kill002 failures were observed in the next 1000 testruns. I plan to push the change below and we can see if the exceptions show up in regular CI test runs. On 10/16/18, 7:31 AM, Gary Adams wrote: Still seeing a 1/1000 kill002 failure on solais-sparcv9-debug. The message waiting for "killing

Re: Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt

It's not uncommon to have a couple of build directives before a run request. It made sense to me to combine the build of ExecDriver along with the main test. Then the builds of the redefined newclasses. Followed by the run statement. On 10/17/18, 11:03 AM, JC Beyler wrote: Hi Gary, Looks goo

Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD

Back in July, I tried to address the jdb output synchronization problem by buffering the output from commands and events. http://cr.openjdk.java.net/~gadams/8169718/webrev.01/ The changes were very invasive and only provided a partial solution. Bottom line for me is the fact that the jdb comm

Re: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java

On 10/17/18, 6:46 PM, Alex Menkov wrote: Hi Gary, - RedefineCrossEvent.java: you can drop "@modules jdk.jdi" as well. jdk.jdi is added to all test in the dir (it's specified in test/jdk/com/sun/jdi/TEST.properties) Done. about InstanceFilter test - it's strange that RedefineCrossEvent fails

Re: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java

So far I have not seen the timeout in my current test runs. Since the test has been on the ProblemList for 1.5 years we would not have seen any timeouts recently. The test does run through a large number of tests that formerly relied on java ee modules, so may have been running longer in the past

Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD

I'm not certain that we should be printing locations or prompts for events when the vm has not been suspended. This looks OK for the simple test case we are working on here, but in real life there may be a lot more output produced. The user has to select a specific thread before additional comman

RE: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Thanks David, for the review... > -Original Message- > From: David Holmes > Sent: Thursday, October 18, 2018 1:20 PM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket > thread crash > > Looks good ! T

Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Looks good ! Thanks for doing the backport to 8u. David On 18/10/2018 5:37 PM, Fairoz Matte wrote: Hi, Kindly review the backport of "8211909: JDWP Transport Listener: dt_socket thread crash" to 8u code is almost cleanly applied. Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.0

[8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash

Hi, Kindly review the backport of "8211909: JDWP Transport Listener: dt_socket thread crash" to 8u code is almost cleanly applied. Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 JDK12 changeset - http://hg.openjdk.

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

Hi Dean, On 18/10/2018 2:06 PM, dean.l...@oracle.com wrote: On 10/17/18 7:07 PM, David Holmes wrote: Hi Dean, This still seems racy to me. We increment all counts under the Threads_lock but we still decrement without the Threads_lock. So we can lose updates to the perfCounters.  117   _tot