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

Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 CSR: https://bugs.openjdk.java.net/browse/JDK-8196991 Webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.00 This webrev is marked ‘L’ because it’s a behavioral change (CSR in draft state, may I have a review of that too ple

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

On 7/20/18 13:44, Chris Plummer wrote: On 7/20/18 1:40 PM, serguei.spit...@oracle.com wrote: Hi Ralf, On 7/20/18 07:28, Schmelter, Ralf wrote: Hi Sergue, I’ve updated the webref: http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v4/ The copyright year in ThreadReferenceImpl.c still

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

On 7/20/18 1:40 PM, serguei.spit...@oracle.com wrote: Hi Ralf, On 7/20/18 07:28, Schmelter, Ralf wrote: Hi Sergue, I’ve updated the webref: http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v4/ The copyright year in ThreadReferenceImpl.c still has to be 2018, not 2008. http://cr.

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

Hi Ralf, On 7/20/18 07:28, Schmelter, Ralf wrote: Hi Sergue, I’ve updated the webref: http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v4/ The copyright year in ThreadReferenceImpl.c still has to be 2018, not 2008. http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v4/test/jd

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

Linux x64, but I cannot check it on other platform (includes older Linux). However SA tests are included in HotSpot tier 1 tests. Tests on submit repo work fine with this change (mach5-one-ysuenaga-JDK-8205992-20180720-0305-31840). Thanks, Yasumasa 2018-07-20 3:26 GMT+09:00 Chris Plummer : Hi

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

Oops. Sorry, that testing comment was for another changeset. I didn't test your changes. If you think they could use some additional testing on some more platforms, let me know. thanks, Chris On 7/20/18 1:07 PM, Chris Plummer wrote: Hi Ralf, Changes look good and pass all the testing I did.

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

Hi Ralf, Changes look good and pass all the testing I did. You can push once Serguei approves. thanks, Chris On 7/20/18 7:28 AM, Schmelter, Ralf wrote: Hi Sergue, I’ve updated the webref: http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v4/ JVMTI_ERROR_OPAQUE_FRAME was never retu

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

Yes that is right, this is the latest: http://cr.openjdk.java.net/~jcbeyler/8207252/webrev.03/ I apologize for the multiple threads and confusion, Jc On Fri, Jul 20, 2018 at 11:22 AM serguei.spit...@oracle.com < serguei.spit...@oracle.com> wrote: > Thank you a lot, Vladimir! > Yes, the webrev.03

Re: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false

Here's another attempt to clear up the overlapping output from the command processing and event handler in the jdb tests. The fundamental problem is observed when "prompts" are produced interleaved with command and event output. This attempts to fix the issue by buffering the output and printing

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

Hi Gary, The test fails if the breakpoint event comes in after the test captures the initial thread suspend counts and before the test captures the 2nd suspend counts. debugger> getting : Map suspendsCounts1 debugger> {Reference Handler=1, Common-Cleaner=1, main=1, Signal Dispatcher=

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

Thank you a lot, Vladimir! Yes, the webrev.03 is the latest. Jc, will correct us if it is not right. Thanks, Serguei On 7/20/18 10:52, Vladimir Kozlov wrote: I asked Igor V. to look. Seems like review is done in an other thread which does not have bug id in subject. Currently webrev.03 Vla

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

Restored the bug number and added back the hotspot-dev and serviceability-dev mailing lists. Thanks, Serguei On 7/20/18 08:30, JC Beyler wrote: Awesome thanks Thomas! Here is the webrev with the extra information then: http://cr.openjdk.java.net/~jcbeyler/8207252/webrev.03/ Thanks again for

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

Please, don't do review in 2 mailing threads. Thanks, Vladimir On 7/20/18 8:30 AM, JC Beyler wrote: Awesome thanks Thomas! Here is the webrev with the extra information then: http://cr.openjdk.java.net/~jcbeyler/8207252/webrev.03/ Thanks again for all the reviews everyone! Jc On Fri, Jul 20,

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

I asked Igor V. to look. Seems like review is done in an other thread which does not have bug id in subject. Currently webrev.03 Vladimir On 7/19/18 4:32 PM, serguei.spit...@oracle.com wrote: Thanks, Rahul! In fact, there no good experts for this area in the serviceability team. It would be

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

Hi Sergue, I’ve updated the webref: http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v4/ JVMTI_ERROR_OPAQUE_FRAME was never returned from GetFrameLocation(). If it would have, the old code would have removed all native methods from the call stack. The original JVMDI call did indeed ret