Re: RFR JDK-8170089: nsk/jdi/EventSet/resume/resume008: ERROR: suspendCounts don't match for : Common-Cleaner

In the successful run below "the first acquire thread suspend counts, resume, and the second acquire thread suspend counts" is not interrupted by the breakpoint event. Note that the failed thread0 case the test thread finishes rapidly. [2018-01-22T20:33:46.86] debugee.stderr> **> debuggee:

Re: RFR(XS): 8207819: Problem list serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatRateTest.java

JDK-8207765 covers two different tests as of yesterday: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatRateTest.java and serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java I updated it to add a similar failure mode sighting for HeapMonitorStatIntervalTest.j

Re: RFR(XS): 8207819: Problem list serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatRateTest.java

Hi Dan, Thank you, Dan. I've just discovered the same in the recent mach5 test results. Sorry for overlooking it. Will need another sub-task for this now. Thanks, Serguei On 7/19/18 06:46, Daniel D. Daugherty wrote: JDK-8207765 covers two different tests as of yesterday: serviceability/jvmti/

RFR: 8207843: HSDB cannot show Object Histogram when ZGC is working

Hi all, Please review this webrev. JBS: https://bugs.openjdk.java.net/browse/JDK-8207843 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8207843/webrev.00/ I encountered AssertionFailure when I attached HSDB to the process which is working with ZGC as below: sun.jvm.hotspot.utilities.

Re: committed > max in MemoryMXBean#getHeapMemoryUsage()

On 07/13/2018 04:10 PM, Daniel Mitterdorfer wrote: Hi, I have good news. I was able to reproduce this issue but this time I have logs. A test failed with the following stack trace around 15:06:55 with: java.lang.IllegalArgumentException: committed = 537919488 should be < max = 536870912 >

Re: RFR: 8206456 - [TESTBUG] docker jtreg tests fail on systems without cpuset.effective_cpus / cpuset.effective_mem

> On Jul 17, 2018, at 8:07 PM, mandy chung wrote: > > > > On 7/17/18 7:00 AM, Bob Vandette wrote: >> Please review this fix which eliminates some docker/cgroup test failures >> when running on older >> Linux kernels with missing cgroup metric files. >> BUGS: >> https://bugs.openjdk.java.net/

RFR(S) 8207765: HeapMonitorIntervalRateTest fails with ZGC

Hi all, Could I have a few reviews of: http://cr.openjdk.java.net/~jcbeyler/8207765/webrev.00/ The test assumed the size of a 1-element array but ZGC changes that assumption. The test now first allocates a bit of memory and gets the average size of the samples before assuming the size. This work

Re: RFR(S) 8207765: HeapMonitorIntervalRateTest fails with ZGC

JDK-8207765 covers two different tests as of yesterday: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatRateTest.java and serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java I updated it to add a similar failure mode sighting for HeapMonitorStatIntervalTest.j

Re: committed > max in MemoryMXBean#getHeapMemoryUsage()

Hi Erik, I am quite happy that I could reproduce it after running the tests repeatedly for approximately a week after the first failure. Glad I could help and thank you all for you help as well! Daniel Am Do., 19. Juli 2018 um 16:57 Uhr schrieb Erik Helin : > > On 07/13/2018 04:10 PM, Daniel Mit

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

It seems that any test that requests ClassPrepareEvents could be getting unexpected events when graal is enabled. Chris On 7/17/18 8:32 PM, Daniil Titov wrote: Hi Serguei,   The changes ar

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Hi Chris, This would depend on how the particular test is implemented. The specifics of this particular test are that an event listener for ClassPrepare events was registered and unregistered multiple times and the failure happened when ClassPrepare event from Graal compiler thread was recei

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Hi Daniil, I understand the changes in eventReceived() to filter out events that are not on the main thread, but I don't understand why you've gone from having a new listener on each iteration, to just having one listener that stays active over all iteratio

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Hi Chris, It solves the problem when ClassPrepare event comes from the Graal compiler thread at the time when no any listener listening for this event is registered by the test. In this case it is handled by the EventHandler itself (lines 261-262 below) as an unexpected event and the test fa

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

But the code used to be:  168 request.disable();  169  170 eventHandler.removeListener(listener); Doesn't the disable stop any new ClassPrepareEvents from coming in, and this is done before the listener is removed, or is there

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Hi Chris, Some events are still coming in after disable() returns. The event handler sees the request object associated with this event ( event.request() ) as disabled but it still receives them. Best regards, Daniil From: Chris Plummer Date: Thursday, July 19, 2018 at 10:54 AM To:

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Ok, your changes look good then. thanks, Chris On 7/19/18 11:01 AM, Daniil Titov wrote: Hi Chris,   Some events are still coming in after disable() returns. The event handler se

Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Thank you Chris and Serguei for reviewing this change! Best regards, Daniil From: Chris Plummer Date: Thursday, July 19, 2018 at 11:03 AM To: Daniil Titov , "[email protected]" , "[email protected] [email protected]" Subject: Re: RFR 8

Re: PING: RFR: 8205992: jhsdb cannot attach to Java processes running in Docker containers

Hi Yasumasa,   84 // It maps the LWPID in the host to it in the container. "it" -> "the PID"  286 // Get LWPID in the host from the container's LWPID.  287 public int getHostPID(int id) {  288 try {  289 return nspidMap.get(id);  290 } catch (NullPointerE

Re: RFR(S) 8207765: HeapMonitorIntervalRateTest fails with ZGC

Hi Jc, The fix looks good to me. Just minor comments. http://cr.openjdk.java.net/%7Ejcbeyler/8207765/webrev.00/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java.frames.html 108 public static void calculateAverageOneElementSi

Re: RFR(S) 8207765: HeapMonitorIntervalRateTest fails with ZGC

Hi Jc, Looks good. Thank you for the update! Thanks, Serguei On 7/19/18 14:52, JC Beyler wrote: Hi Serguei, Done here: http://cr.openjdk.java.net/~jcbeyler/8207765/webrev.01/

Re: RFR (S) 8207252: C1 still does eden allocations when TLAB is enabled

Thanks, Rahul! In fact, there no good experts for this area in the serviceability team. It would be much better if anyone from the Compiler team could do it. Vladimir K., Is there anyone from the Compiler team available to review this? Otherwise, I could try to review it but am not sure about my

Re: RFR(S) 8207765: HeapMonitorIntervalRateTest fails with ZGC

Looks good. --alex On 07/19/2018 14:52, JC Beyler wrote: Hi Serguei, Done here: http://cr.openjdk.java.net/~jcbeyler/8207765/webrev.01/ I added: + // Calculate the size of a 1-element array in order to assess average sampling int

Re: RFR(S) 8207765: HeapMonitorIntervalRateTest fails with ZGC

Thanks a lot, Alex! Jc, Could you please send me a patch for push? Thanks, Serguei On 7/19/18 17:06, Alex Menkov wrote: Looks good. --alex On 07/19/2018 14:52, JC Beyler wrote: Hi Serguei, Done here: http://cr.openjdk.java.net/~jcbeyler/8207765/webrev.01/

Re: PING: RFR: 8205992: jhsdb cannot attach to Java processes running in Docker containers

Hi Chris, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8205992/webrev.02/ I tested my change on Linux x64, but I cannot check it on other platform (includes older Linux). However SA tests are included in HotSpot tier 1 test