[PING] RFR(XS): 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686

On Mon, 2018-07-23 at 18:27 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this one-liner change related to jhsdb > --mixed when attaching to a running Java process? The issue arises when > threads are in native code and that native code has frame pointers not > properly pr

Re: RFR (S) 8205608: Fix 'frames()' in ThreadReferenceImpl.c to prevent quadratic runtime behavior

Hi Sergey, thanks for your help, but I've just pushed the fix now. @Thomas: sorry, I really apologize, but I've just realized that I've forgot to add you as a Reviewer :( I'll promise to look more carefully next time. Regards, Volker On Tue, Jul 24, 2018 at 6:01 PM, [email protected]

Re: RFR (S) 8205608: Fix 'frames()' in ThreadReferenceImpl.c to prevent quadratic runtime behavior

Oh my good! And I've also forgot to add Ralf as a Contributer :(:(:( I really desperately need a vacation! Sorry Ralf, Volker On Thu, Jul 26, 2018 at 11:36 AM, Volker Simonis wrote: > Hi Sergey, > > thanks for your help, but I've just pushed the fix now. > > @Thomas: sorry, I really apologize

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

PING: Could you review it? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8207843/webrev.00/ Yasumasa On 2018/07/19 23:03, Yasumasa Suenaga wrote: Hi all, Please review this webrev. JBS: https://bugs.openjdk.java.net/browse/JDK-8207843   webrev: http://cr.openjdk.java.net/~ys

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

CC'ing to hotspot-gc-dev On 2018/07/26 21:30, Yasumasa Suenaga wrote: PING: Could you review it?    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8207843/webrev.00/ Yasumasa On 2018/07/19 23:03, Yasumasa Suenaga wrote: Hi all, Please review this webrev.   JBS: https://bugs.open

Re: RFR(L): 8196989: Revamp G1 JMX MemoryPoolMXBean, GarbageCollectorMXBean, and jstat counter definitions

Hi Paul, Erik may not have time in the next few months to review such a large change. But it would also be better to do the changes in steps for other reviewers. Also see below. On Mon, 2018-07-23 at 21:33 +, Hohensee, Paul wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/b

RFR (XS) 8208251: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCCMSTest.java fails intermittently on Linux-X64

Hi all, As we fixed the HeapMonitorTest to not fail from time to time, there seems to be the same issue and risk in HeapMonitorGCTest. Could someone review the similar fix: Webrev: http://cr.openjdk.java.net/~jcbeyler/8208251/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8208251 The r

Re: RFR 8207364: nsk/jvmti/ResourceExhausted/resexhausted003 fails to start

Hi Chris, The smallest allowed metaspace size for the test is 9MB. In both cases (when the metaspace size is set to 9Mb and to 16 Mb) the expected OutOfMemoryError is thrown and the test passes. I did update the patch to use the smallest settings. Webrev: http://cr.openjdk.java.net/~dtitov/82

Re: RFR 8207364: nsk/jvmti/ResourceExhausted/resexhausted003 fails to start

Thanks for the explanation. Update looks good. Chris On 7/26/18 9:56 AM, Daniil Titov wrote: Hi Chris, The smallest allowed metaspace size for the test is 9MB. In both cases (when the metaspace size is set to 9Mb and to 16 Mb) the expected OutOfMemoryError is thrown and the test passes. I d

Re: RFR (XS) 8208251: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCCMSTest.java fails intermittently on Linux-X64

Hi Jc, It looks good to me. Thanks, Serguei On 7/26/18 09:53, JC Beyler wrote: Hi all, As we fixed the HeapMonitorTest to not fail from time to time, there seems to be the same issue a

Re: RFR 8207364: nsk/jvmti/ResourceExhausted/resexhausted003 fails to start

+1 Thanks, Serguei On 7/26/18 09:59, Chris Plummer wrote: Thanks for the explanation. Update looks good. Chris On 7/26/18 9:56 AM, Daniil Titov wrote: Hi Chris, The smallest allowed metaspace size for the test is 9MB. In both cases (when the metaspace size is set to 9Mb and to 16 Mb) the

Re: RFR 8208303: Track JNI failures and fail tests

Hi Jc, It looks good to me. Thanks, Serguei On 7/26/18 09:58, JC Beyler wrote: Hi all, The tests in the HeapMonitor subsystem has a lot of JNI calls. There is a need for verification a

RE: [PING] RFR(XS): 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686

Changes looks good Severin. I am not a reviewer though, so you still need a Reviewer to review. Thanks, Sharath -Original Message- From: Severin Gehwolf [mailto:[email protected]] Sent: Thursday, July 26, 2018 1:04 PM To: serviceability-dev Subject: [PING] RFR(XS): 8208091: SA: jhsdb

Re: [PING] RFR(XS): 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686

On Thu, 2018-07-26 at 10:04 -0700, Sharath Ballal wrote: > Changes looks good Severin. Thanks for the review, Sharath! > I am not a reviewer though, so you still need a Reviewer to review. Anyone? Thanks, Severin > -Original Message- > From: Severin Gehwolf [mailto:[email protected]]

Re: RFR 8208303: Track JNI failures and fail tests

Hi Jc, Good idea. I was thinking about something like this. Thanks, Serguei On 7/26/18 10:40, JC Beyler wrote: Hi Serguei, As I was looking at another test bug (https://bugs.openjdk.java.n

Re: RFR (XS) 8208251: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCCMSTest.java fails intermittently on Linux-X64

On 7/26/18 12:53 PM, JC Beyler wrote: Hi all, As we fixed the HeapMonitorTest to not fail from time to time, there seems to be the same issue and risk in HeapMonitorGCTest. Could someone review the similar fix: Webrev: http://cr.openjdk.java.net/~jcbeyler/8208251/webrev.00/

Re: RFR (XS) 8208251: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCCMSTest.java fails intermittently on Linux-X64

Jc, Could you send me a patch? I'll sponsor the push. Thanks, Serguei On 7/26/18 11:05, Daniel D. Daugherty wrote: On 7/26/18 12:53 PM, JC Beyler wrote: Hi all, As we

Re: RFR 8208303: Track JNI failures and fail tests

Please make sure this fix is well tested in Mach5 prior to pushing. In particular, I'm focused on reducing the noise in Mach5 tier[1-3] so adding any new failures there will make me grumpy :-) Dan On 7/26/18 3:03 PM, JC Beyler wrote: Hi all, With the FatalError idea, here is the webrev to con

Re: RFR 8208303: Track JNI failures and fail tests

Yes, of course it has to be well tested before the push. Does it make sense to plan it to push to 11 (after th testing is done)? Thanks, Serguei On 7/26/18 12:08, Daniel D. Daugherty wrote: Please make sure this

Re: RFR 8208303: Track JNI failures and fail tests

We entered RDP2 today (07.26). So only P1 and P2 bug fixes allowed. Dan On 7/26/18 3:14 PM, [email protected] wrote: Yes, of course it has to be well tested before the push. Does it make sense to plan it to push to 11 (after th testing is done)? Thanks, Serguei On 7/26/18 12:08, Da

Re: RFR 8208303: Track JNI failures and fail tests

On 7/26/18 12:15, Daniel D. Daugherty wrote: We entered RDP2 today (07.26). So only P1 and P2 bug fixes allowed. Sorry, I confused 07.26 with 07.28. Then it is 12 only. Thanks, Serguei

Re: RFR 8208303: Track JNI failures and fail tests

I'm pretty sure changes that only affect tests can be any priority. But still, be a lot more cautious the closer we get to release. Chris On 7/26/18 12:15 PM, Daniel D. Daugherty wrote: We entered RDP2 today (07.26). So only P1

Re: [PING] RFR(XS): 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686

Hi Severin, I had looked at this review when it came out, but was hesitant to ok it because I really don't know this code at all. If you can get another reviewer who does know the code, then I'll approve it. This only impacts 32-bit, right? If so, keep in mind that it won't get tested by Oracl

Re: RFR 8207364: nsk/jvmti/ResourceExhausted/resexhausted003 fails to start

Thank you Serguei and Chris for reviewing this change. Best regards, Daniil On 7/26/18, 10:01 AM, "[email protected]" wrote: +1 Thanks, Serguei On 7/26/18 09:59, Chris Plummer wrote: > Thanks for the explanation. Update looks good. > > Chris