Re: RFR (S/T): 8231737: Cleanup JvmtiRawMonitor code

Hi David, On 10/8/19 3:58 AM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8231737 webrev: http://cr.openjdk.java.net/~dholmes/8231737/webrev/ Stylistic code cleanup of JvmtiRawMonitor code as previously promised: Very nice clean up! But when changing the names, may I sug

Re: RFR (S/T): 8231737: Cleanup JvmtiRawMonitor code

On 10/8/19 9:25 AM, David Holmes wrote: Hi Per, Thanks for taking a look! On 8/10/2019 4:56 pm, Per Liden wrote: Hi David, On 10/8/19 3:58 AM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8231737 webrev: http://cr.openjdk.java.net/~dholmes/8231737/webrev/ Stylistic

RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small

The newly added: GetOwnedMonitorInfoWithEATest.java GetOwnedMonitorStackDepthInfoWithEATest.java fail when run with ZGC as they set -Xmx to 32M which is too. Bumping to 128m. Bug: https://bugs.openjdk.java.net/browse/JDK-8232056 Webrev: http://cr.openjdk.java.net/~pliden/8232056/webrev.0 /Pe

Re: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small

Thanks for reviewing, David! /Per On 10/9/19 3:53 PM, David Holmes wrote: Hi Per, Thanks for fixing this one. On 9/10/2019 11:19 pm, Per Liden wrote: The newly added: GetOwnedMonitorInfoWithEATest.java GetOwnedMonitorStackDepthInfoWithEATest.java fail when run with ZGC as they set -Xmx to

Re: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small

emove the lines that set -Xmx (and -Xms). The lines are not needed in these tests (copied from other tests). I've tried that successfully just now. Thanks, Richard. -Original Message- From: Per Liden Sent: Mittwoch, 9. Oktober 2019 15:20 To: hotspot-compiler-dev Cc:

Re: RFR: 8231943: ZGC: Enable serviceability/dcmd/gc/RunGCTest

(CC:ing serviceability-dev) On 10/7/19 2:38 PM, Per Liden wrote: This test is currently disabled for ZGC, but it can easily be enabled by adjusting the expected log string. ZGC doesn't print "Pause Full", but it still prints the "(Diagnostic Command)" part. Also,

Re: RFR: 8231943: ZGC: Enable serviceability/dcmd/gc/RunGCTest

Thanks Erik! /Per On 10/16/19 8:56 AM, Erik Osterlund wrote: +1 /Erik On 10 Oct 2019, at 14:28, Per Liden wrote: (CC:ing serviceability-dev) On 10/7/19 2:38 PM, Per Liden wrote: This test is currently disabled for ZGC, but it can easily be enabled by adjusting the expected log string

Re: RFR: 8231943: ZGC: Enable serviceability/dcmd/gc/RunGCTest

Thanks Serguei! /Per On 2019-10-17 01:21, serguei.spit...@oracle.com wrote: Hi Per, Looks good. Thanks, Serguei On 10/15/19 23:56, Erik Osterlund wrote: +1 /Erik On 10 Oct 2019, at 14:28, Per Liden wrote: (CC:ing serviceability-dev) On 10/7/19 2:38 PM, Per Liden wrote: This test

Re: [14] RFR 8235829: graal crashes with Zombie.java test

Hi Coleen, The "nmethod entry barrier"-part looks good to me. Just one minor nit, maybe JvmtiDeferredEventQueue::run_nmethod_entry_barrier should have an "s" on it (i.e. JvmtiDeferredEventQueue::run_nmethod_entry_barriers) since it loops over all entries in the queue? But I don't dare to com

Re: RFR(S) : 8246494 : introduce vm.flagless at-requires property

Hi Igor, When looking at the follow-up sub-tasks for this, I see for example this: http://cr.openjdk.java.net/~iignatyev/8246499/webrev.00/test/hotspot/jtreg/gc/z/TestSmallHeap.java.udiff.html Maybe I'm misunderstanding how this is supposed to work, but it looks like this test would now _not_

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/26/18 10:39 PM, Roman Kennke wrote: [...]  *) shared-serviceability     - The usual code to support another GC Just had a quick look at the SA part. I was thinking you'd have the same proble

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

On 11/28/18 3:00 PM, Roman Kennke wrote: Hi Per, Hi Roman, On 11/26/18 10:39 PM, Roman Kennke wrote: [...]   *) shared-serviceability - The usual code to support another GC Just had a quick look at

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Small comment on the build changes. Instead of checking for zero variant here: + # Only enable Shenandoah on supported arches + AC_MSG_CHECKING([if shenandoah can be built]) + if HOTSPOT_CHECK_JVM_VARIANT(zero); then +DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" +AC_MSG

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/28/18 11:29 PM, Roman Kennke wrote: [...] Per: Disabling the SA part for heapdumping makes 2 tests fail: - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java we filter them for Shenandoah now. I'm wonderin

RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

There's no support for SA heap walking when using ZGC. Hence the tests for this should not execute when ZGC is enabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8214484 Webrev: http://cr.openjdk.java.net/~pliden/8214484/webrev.0 /Per

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

On 11/29/18 4:17 PM, Aleksey Shipilev wrote: On 11/29/18 4:07 PM, Per Liden wrote: There's no support for SA heap walking when using ZGC. Hence the tests for this should not execute when ZGC is enabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8214484 Webrev: http://cr.openjdk.jav

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Oh, I filed a bug [1] and sent out a fix for review, before noticing Jini's mail. [1] https://bugs.openjdk.java.net/browse/JDK-8214484 /Per On 11/29/18 5:39 AM, Jini George wrote: Hi Roman, The SA tests which iterate over the heap (ClhsdbJhisto.java, TestHeapDumpFor*.java) fail if ZGC is pa

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

Hi, On 11/29/18 4:48 PM, Aleksey Shipilev wrote: On 11/29/18 4:34 PM, Per Liden wrote: On 11/29/18 4:17 PM, Aleksey Shipilev wrote: On 11/29/18 4:07 PM, Per Liden wrote: There's no support for SA heap walking when using ZGC. Hence the tests for this should not execute when ZGC is en

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

On 2018-11-29 17:40, Aleksey Shipilev wrote: On 11/29/18 5:26 PM, Per Liden wrote: Hi, On 11/29/18 4:48 PM, Aleksey Shipilev wrote: On 11/29/18 4:34 PM, Per Liden wrote: On 11/29/18 4:17 PM, Aleksey Shipilev wrote: On 11/29/18 4:07 PM, Per Liden wrote: There's no support for SA

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

#x27;vm.gc != "Z"' among the SA tests. cheers, Per thanks, Chris On 11/29/18 7:07 AM, Per Liden wrote: There's no support for SA heap walking when using ZGC. Hence the tests for this should not execute when ZGC is enabled. Bug: https://bugs.openjdk.java.net/b

Re: RFR (round 3), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/29/18 9:41 PM, Roman Kennke wrote: [...] http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ Some comments (I didn't look at the compiler part): src/hotspot/share/gc/shared/barrierSetConfig.hpp src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp --

Re: RFR (round 3), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/30/18 10:09 AM, Roman Kennke wrote: Hi Per, Thanks for taking time to look at this! We will take care of all the issues you mentioned. Regarding the flags, I think they are useful as they are now. Shenandoah can be run in 'passive' mode, which doesn't involve any concurrent GC

Re: RFR (round 3), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi, On 11/30/18 10:55 AM, Roman Kennke wrote: Hi Per, Thanks for taking time to look at this! We will take care of all the issues you mentioned. Regarding the flags, I think they are useful as they are now. Shenandoah can be run in 'passive' mode, which doesn't involve any concurrent GC (iow,

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi, On 11/28/18 3:24 PM, Roman Kennke wrote: Hi Per, Hi Roman, On 11/26/18 10:39 PM, Roman Kennke wrote: [...]    *) shared-serviceability   - The usual code to support another GC Just had a quick l

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

Thanks for reviewing, Thomas! /Per On 11/30/18 1:53 PM, Thomas Schatzl wrote: Hi, On Thu, 2018-11-29 at 16:07 +0100, Per Liden wrote: There's no support for SA heap walking when using ZGC. Hence the tests for this should not execute when ZGC is enabled. Bug: https://bugs.openjdk.jav

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/30/18 10:00 PM, Roman Kennke wrote: Hi all, here comes round 4 of Shenandoah upstreaming review: This includes fixes for the issues that Per brought up: - Verify and gracefully reject dangerous flags combinations that disables required barriers - Revisited @requires filters in

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 12/3/18 8:27 PM, Roman Kennke wrote: Round 5 of Shenandoah review includes: - A fix for the @requires tag in TestFullGCCountTest.java. It should be correct now. We believe the CMS @requires was also not quite right and fixed it the same. It reads now: Don't run this test if: - Ac

Re: RFR (XS) 8215329: Modify ZGC requirement for HeapMonitorThreadTest.java

Bug: https://bugs.openjdk.java.net/browse/JDK-8215329 (Basically, from what I understood from an email from Per Liden: - @requires !vm.gc.Z -> ZGC is built in the JDK - @requires vm.gc != "Z" -> ZGC is being used for the runtime ) Thanks, Jc

Re: RFR (XS) 8215329: Modify ZGC requirement for HeapMonitorThreadTest.java

Hi again, I ran this test some more and managed to get an OOME even with a 768M heap. I'm getting a bit suspicious that something else is wrong here. Let me dig into this some more and see if I can understand what the real issue is. cheers, Per On 12/13/2018 10:31 AM, Per Liden wrote

Re: RFR (XS) 8215329: Modify ZGC requirement for HeapMonitorThreadTest.java

e bug to fix the ZGC issue (and update this test to run with ZGC again). cheers, Per On 12/13/2018 12:21 PM, Per Liden wrote: Hi again, I ran this test some more and managed to get an OOME even with a 768M heap. I'm getting a bit suspicious that something else is wrong here. Let me di

Re: RFR (XS) 8215329: Modify ZGC requirement for HeapMonitorThreadTest.java

the @requires >> to be correct then until then? >> >> (@Per: if you want, I can update the test once it's done; either >> assign a JBS bug to me or send me an email) >> >> Thanks, >> Jc >> >> On Th

Re: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc.

Hi, On 2/6/19 3:48 PM, Aleksey Shipilev wrote: On 2/6/19 3:34 PM, z...@redhat.com wrote: *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why this whole thing is removed? I would expect "just" the rename of slow_refill_waste() to refill_waste() and removing fast_refill_waste() here

Re: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc.

On 2019-02-07 15:03, z...@redhat.com wrote: Thanks, Per. Thanks for cleaning this up. GC changes look good. Just one minor thing, please align the assignment here: @@ -147,8 +145,7 @@ void ThreadLocalAllocBuffer::reset_statistics() { _number_of_refills = 0; - _fast_refill_waste = 0; -

RFR: 8221396: Clean up serviceability/sa/TestUniverse.java

Clean up serviceability/sa/TestUniverse.java to remove the need for the withZ/withoutZ option we currently pass in. This also changes the test to only run with the selected GC instead of testing all GCs every time, which should save us some cycles in testing. Bug: https://bugs.openjdk.java.net

Re: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java

Thanks Stefan! /Per On 3/25/19 2:44 PM, Stefan Karlsson wrote: Looks good. StefanK On 2019-03-25 10:59, Per Liden wrote: Clean up serviceability/sa/TestUniverse.java to remove the need for the withZ/withoutZ option we currently pass in. This also changes the test to only run with the

Re: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java

we skip an unsupported configuration. cheers, Per No need evidently to make a new webrev for that :) Thanks, Jc On Mon, Mar 25, 2019 at 6:59 AM Per Liden <mailto:per.li...@oracle.com>> wrote: Thanks Stefan! /Per On 3/25/19 2:44 PM, Stefan Karlsson wrote: >

RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

Please review this one-liner to disable vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The root problem is that ZGC doesn't properly respect address space limitations (RLIMIT_AS). This test will be re-enabled again as part of fixing https://bugs.openjdk.java.net/browse/JDK-8231552 Bug

Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

this test into zgc-specific problem list (test/hotspot/jtreg/ProblemList-zgc.txt)? Thanks, -- Igor On Sep 26, 2019, at 1:39 PM, Per Liden wrote: Please review this one-liner to disable vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The root problem is that ZGC doesn't pro

Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

Hi Igor, On 9/27/19 3:49 AM, Igor Ignatev wrote: Hi Per, On Sep 26, 2019, at 2:32 PM, Per Liden wrote: Hi Igor, I don't think it belongs in the problem list, for two reasons: 1) The test doesn't fail because of a bug. It fails because ZGC doesn't currently support th

Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

Thanks Serguei! /Per On 9/27/19 12:20 AM, serguei.spit...@oracle.com wrote: Hi Per, It looks good and trivial. Thanks, Serguei On 9/26/19 1:39 PM, Per Liden wrote: Please review this one-liner to disable vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The root problem is that ZGC

Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

er cheers, Per On 9/26/19 10:58 PM, Igor Ignatyev wrote: Hi Per, wouldn't it be better to put this test into zgc-specific problem list (test/hotspot/jtreg/ProblemList-zgc.txt)? Thanks, -- Igor On Sep 26, 2019, at 1:39 PM, Per Liden wrote: Please review this one-liner to disable vmTestba

Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

should be reenabled if/when the bug^H^H^H RFE is fixed. :-) Done ;) Dan On 9/27/19 9:39 AM, Per Liden wrote: Hi Dan, The background here is that ZGC previously (by design) required a certain amount of address space to run. So it was a deliberate decision to not support RLIMIT_AS. However, as ZG

Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails

aking it clear that vmTestbase/nsk/jvmti/Allocate/alloc001 should be reenabled if/when the bug^H^H^H RFE is fixed. :-) Dan On 9/27/19 9:39 AM, Per Liden wrote: Hi Dan, The background here is that ZGC previously (by design) required a certain amount of address space to run. So it was a deli

8191846: jstat prints debug message when debugging is disabled

Hi, jstat is designed to handle the case where a perf counter doesn't exits. In the output jstat will then print a "-" instead of the perf counter value to indicate that the counter doesn't exist. However, jstat also prints an unnecessary message, which clobbers the output. This message might

Re: 8191846: jstat prints debug message when debugging is disabled

/jstatd /Per On 2017-11-24 09:13, Erik Helin wrote: Hi Per, On 11/24/2017 09:01 AM, Per Liden wrote: Hi, jstat is designed to handle the case where a perf counter doesn't exits. In the output jstat will then print a "-" instead of the perf counter value to indicate that the counte

Re: 8191846: jstat prints debug message when debugging is disabled

Thanks Robbin! /Per On 2017-11-27 10:41, Robbin Ehn wrote: Looks good, Robbin On 11/24/2017 09:01 AM, Per Liden wrote: Hi, jstat is designed to handle the case where a perf counter doesn't exits. In the output jstat will then print a "-" instead of the perf counter value t

Re: RFR (round 4), JEP-318: Epsilon GC

Hi, On 06/01/2018 10:13 AM, Jini George wrote: [...] ==>  share/classes/sun/jvm/hotspot/oops/ObjectHeap.java 445 } else { 446    if (Assert.ASSERTS_ENABLED) { 447   Assert.that(false, "Expecting GenCollectedHeap, G1CollectedHeap, " + 448   "or ParallelScave

Re: RFR: 8204180: Implementation: JEP 318: Epsilon GC (round 5)

On 06/06/2018 06:30 PM, Aleksey Shipilev wrote: Hi, This is fifth (and hopefully final) round of code review for Epsilon GC changes. It includes the fixes done as the result of fourth round of reviews, mostly in Serviceability. The build parts are the same since last few reviews, so this is no

Re: RFR: 8204180: Implementation: JEP 318: Epsilon GC (round 5)

On 06/07/2018 02:38 PM, Aleksey Shipilev wrote: On 06/07/2018 12:13 PM, Per Liden wrote: On 06/06/2018 06:30 PM, Aleksey Shipilev wrote: Hi, This is fifth (and hopefully final) round of code review for Epsilon GC changes. It includes the fixes done as the result of fourth round of reviews

Re: RFR: 8204180: Implementation: JEP 318: Epsilon GC (round 5)

On 06/12/2018 10:48 AM, Aleksey Shipilev wrote: On 06/07/2018 02:42 PM, Per Liden wrote: On 06/07/2018 02:38 PM, Aleksey Shipilev wrote: On 06/07/2018 12:13 PM, Per Liden wrote: On 06/06/2018 06:30 PM, Aleksey Shipilev wrote: Hi, This is fifth (and hopefully final) round of code review for

Re: HotSpot Serviceability Agent (SA) Survey

Hi Stephen, On 03/21/2018 07:14 PM, Stephen Fitch wrote: Hi, The HotSpot Serviceability Agent (SA) is a set of APIs and tools for debugging HotSpot Virtual Machine and has been a part of the JVM/JDK for a long time, however we don't have a lot of data about how it is used in practice, especi

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

Hi Yasumasa, I'm afraid this approach of iterating over objects doesn't work. In ZGC, you can't walk over ZPages since some objects in there might be unreachable and hence might have an invalid/dead class pointer, which in turn means you can't tell the size of the object. When iterating over

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

/10ef3d870cb7/src/hotspot/share/gc/z/zArguments.cpp#l86 Thanks, Yasumasa On 2018/08/07 21:32, Per Liden wrote: Hi Yasumasa, I'm afraid this approach of iterating over objects doesn't work. In ZGC, you can't walk over ZPages since some objects in there might be unreachable and h

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

[1] https://www.jfokus.se/jfokus18/preso/ZGC--Low-Latency-GC-for-OpenJDK.pdf On 2018/08/08 0:28, Per Liden wrote: Hi, On 08/07/2018 03:02 PM, Yasumasa Suenaga wrote: Hi Per, Currently, class unloading seems not to be implemented. So do not worry about it? Support for class unloading is

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

On 08/08/2018 10:02 AM, Per Liden wrote: Hi, On 08/08/2018 10:00 AM, Yasumasa Suenaga wrote: Hi Per, Will class unloading be occurred after relocation? No, before relocation. But it doesn't really matter when it happens, since there can still be unreachable objects with dead

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

Hi, On 08/08/2018 10:34 AM, Yasumasa Suenaga wrote: On 2018/08/08 17:07, Per Liden wrote: On 08/08/2018 10:02 AM, Per Liden wrote: Hi, On 08/08/2018 10:00 AM, Yasumasa Suenaga wrote: Hi Per, Will class unloading be occurred after relocation? No, before relocation. But it doesn't r

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

Hi JC, (Sorry, I didn't see this thread until now... been on vacation, jvmls, etc) On 07/19/2018 11:52 PM, 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 samplin

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

. cheers, Per Jc On Wed, Aug 8, 2018 at 6:19 AM Per Liden <mailto:per.li...@oracle.com>> wrote: Hi JC, (Sorry, I didn't see this thread until now... been on vacation, jvmls, etc) On 07/19/2018 11:52 PM, JC Beyler wrote: > Hi Serguei, > >

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

can do that today, you don't need to wait for class unloading support to appear. cheers, Per Thanks, Yasumasa On 2018/08/08 20:45, Per Liden wrote: Hi, On 08/08/2018 10:34 AM, Yasumasa Suenaga wrote: On 2018/08/08 17:07, Per Liden wrote: On 08/08/2018 10:02 AM, Per Liden wrote: Hi

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

Hi, On 08/16/2018 03:52 AM, Yasumasa Suenaga wrote: Hi, On 2018/08/15 2:36, Per Liden wrote: Hi, On 2018-08-11 14:06, Yasumasa Suenaga wrote: Hi Per, SA needs memory regions to generate class histogram. So it is difficult to use visitor model for it. I want to back to this issue when

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

Hi, On 08/16/2018 10:39 AM, Yasumasa Suenaga wrote: Hi, On 2018/08/16 15:55, Per Liden wrote: Hi, On 08/16/2018 03:52 AM, Yasumasa Suenaga wrote: Hi, On 2018/08/15 2:36, Per Liden wrote: Hi, On 2018-08-11 14:06, Yasumasa Suenaga wrote: Hi Per, SA needs memory regions to generate class

RFR: 8209163: SA: Show Object Histogram asserts with ZGC

This patch avoids an assertion, and instead prints a warning, when trying to show the "Object Histogram" when using ZGC. I also had to add a call to heapIterationFractionUpdate() so that the update progress frame is properly created, even when there are not heap regions to walk over. Without th

Re: RFR: 8209163: SA: Show Object Histogram asserts with ZGC

heers, Per Thanks, Jc On Wed, Sep 12, 2018 at 1:25 AM Per Liden <mailto:per.li...@oracle.com>> wrote: This patch avoids an assertion, and instead prints a warning, when trying to show the "Object Histogram" when using ZGC. I also had to add a call to heapIteratio

Re: RFR: 8209163: SA: Show Object Histogram asserts with ZGC

s the good one then :); looks good to me then Per (not a reviewer though), Jc On Thu, Sep 13, 2018 at 6:25 AM Yasumasa Suenaga <mailto:yasue...@gmail.com>> wrote: Hi Per, On 2018/09/13 19:48, Per Liden wrote: >   Hi JC, > >   Thanks for reviewing.

RFR(xs): 8080930: SA changes broke bootcycle-images builds

JDK-8080581 introduced two new packages in the SA, but missed to add those to make/sa.files. This problem went unnoticed since it's only exposed when doing bootcycle-images builds where JDK9's javac no longer emits classes for implicit compilations. This patch makes sure the two new packages a

Re: RFR(xs): 8080930: SA changes broke bootcycle-images builds

Thanks Staffan! /Per On 2015-05-22 13:32, Staffan Larsen wrote: Looks good! Thanks, /Staffan On 22 maj 2015, at 13:23, Per Liden wrote: JDK-8080581 introduced two new packages in the SA, but missed to add those to make/sa.files. This problem went unnoticed since it's only exposed

Re: RFR(xs): 8080930: SA changes broke bootcycle-images builds

On 2015-05-25 08:55, Bengt Rutisson wrote: Hi Per, On 2015-05-22 13:23, Per Liden wrote: JDK-8080581 introduced two new packages in the SA, but missed to add those to make/sa.files. This problem went unnoticed since it's only exposed when doing bootcycle-images builds where JDK9'

Re: RFR (S): 8142482: Improve the support for prefix functions in unified logging

Hi Marcus, On 2015-11-11 15:19, Marcus Larsson wrote: Hi, Please review the following small patch to improve the support for prefixes in unified logging. Instead of the previous format and value/callback, a prefix is now defined as a function that receives the log buffer as argument, allowing

RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

Summary: This patch updates the tests in serviceability/tmtools/jstat/ to use a fixed (and relatively small) heap size. Without this these tests tend to run out of memory on machines with VM overcommit disabled. This has happened in nightly testing. The patch also moves a misplaced @ignore tag

Re: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

On 2016-04-06 11:46, Dmitry Samersoff wrote: Per, The fix looks good for me. Thanks Dima. Copyright year of these tests is not updated. GcCapacityTest.java GcCauseTest01.java GcTest02.java These already have 2016 in their copyright. cheers, Per -Dmitry On 2016-04-06 12:32, Per

Re: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

Thanks Stefan. Per On 2016-04-06 13:02, Stefan Johansson wrote: Looks good, StefanJ On 2016-04-06 11:32, Per Liden wrote: Summary: This patch updates the tests in serviceability/tmtools/jstat/ to use a fixed (and relatively small) heap size. Without this these tests tend to run out of memory

Re: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

78) figure out what the fix should be. Ok? cheers, Per Thanks, Dima On 06.04.2016 12:32, Per Liden wrote: Summary: This patch updates the tests in serviceability/tmtools/jstat/ to use a fixed (and relatively small) heap size. Without this these tests tend to run out of memory on mach

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4]

On Thu, 24 Sep 2020 08:55:03 GMT, Erik Österlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack >> Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a >> frame (supporting interprete

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7]

On Tue, 29 Sep 2020 07:24:16 GMT, Stefan Karlsson wrote: >> It was checking is_in_or_null before and after. Our is_in checks that it is >> in committed memory, and that the pointer >> is not stale w.r.t. color, as that is very likely to be a bug. We >> reluctantly made it relaxed for our safepo

Re: RFR: 8252105: parallel heap inspection for ZCollectedHeap [v2]

On Fri, 11 Sep 2020 07:24:20 GMT, Lin Zang wrote: >> Hi @pliden, >> Thanks for your comments, I will try to merge ZHeapIterator and >> ZHeapParIterator and update the pr then. >> -Lin > > Hi @pliden, >I updated the PR which merge the changed code into ZHeapIterator. >May I ask your hel

Re: RFR: 8252105: parallel heap inspection for ZCollectedHeap [v2]

On Mon, 5 Oct 2020 14:29:02 GMT, Lin Zang wrote: >> Hi @linzang, >> >> I started reviewing your patch in more detail. However, I ended up with a >> large number of major comments and I started >> to feel that it would probably be more productive to create an alternative >> patch for this, so I

Re: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing

On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It > later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load > barrier to that handle and self-heals it in

RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

A number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests d

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Fri, 20 Nov 2020 13:23:28 GMT, Per Liden wrote: > A number of JDI tests create objects on the debugger side with calls to > `newInstance()`. However, on the debugee side, these new instances will only > be held on to by a `JNIGlobalWeakRef`, which means they could be collected

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Mon, 30 Nov 2020 20:03:01 GMT, Chris Plummer wrote: >> Just a friendly ping. Still looking for reviewers for this fix. > >> Just a friendly ping. Still looking for reviewers for this fix. > > Until we resolve the discussion in > [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

Withdrawn: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Fri, 20 Nov 2020 13:23:28 GMT, Per Liden wrote: > A number of JDI tests create objects on the debugger side with calls to > `newInstance()`. However, on the debugee side, these new instances will only > be held on to by a `JNIGlobalWeakRef`, which means they could be collected

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Tue, 1 Dec 2020 12:33:31 GMT, Per Liden wrote: >>> Just a friendly ping. Still looking for reviewers for this fix. >> >> Until we resolve the discussion in >> [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987), I don't >> think your su

RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

This PR replaces the withdraw PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Fri, 4 Dec 2020 20:12:11 GMT, Chris Plummer wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying >> problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger >> side with calls to `newInstance()`. How

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Mon, 7 Dec 2020 05:14:36 GMT, David Holmes wrote: >> Another options is to save away the weakref in the node when strengthening. >> This would benefit `ObjectReference.disableCollection()` also, since it >> would no longer need to deal with a potential OOM. However, I'm not so sure >> it's

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Mon, 7 Dec 2020 05:10:34 GMT, David Holmes wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying >> problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger >> side with calls to `newInstance()`. Howe

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

code locations. > - > *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - > This test keeps the VM suspended, and then expects objects to be garbage > collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

On Mon, 7 Dec 2020 07:41:46 GMT, Chris Plummer wrote: >> That was something I pointed out in the pre-review, and it has been >> addressed in `commonRef_pinAll/unpinAll`: >> >> `568 if (gdata->pinAllCount == 1) {` >> `618 if (gdata->pinAllCount == 0) {` > >> Okay. I would not hav

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

On Mon, 7 Dec 2020 06:04:36 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add comment > > Overall seems okay. Some comments on tests as I think the existing test

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

On Mon, 7 Dec 2020 23:34:00 GMT, Chris Plummer wrote: >> I don't follow your reasoning here Chris. All ObjectReferences can be GC'd >> at any time unless GC has been disallowed. So a reference create via >> newInstance is no different to any other reference. If it is currently >> reachable the

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3]

code locations. > - > *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - > This test keeps the VM suspended, and then expects objects to be garbage > collected, which they now won't. > > Testing: > - More than 50 iterations of

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

On Tue, 8 Dec 2020 19:30:44 GMT, Chris Plummer wrote: >> I still have some reservations about the logic in some of the tests now (ie >> using disableCollection whilst the VM is suspended and reenabling also >> whilst suspended) but the logic was unclear in the first place. If necessary >> foll

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3]

On Tue, 8 Dec 2020 19:22:41 GMT, Chris Plummer wrote: >> I think we're still within what the spec says, given that the wording is so >> loose. But it's hard to tell if this change will be problematic for some use >> case. > > I'm ok with making the change and then seeing if there is any fallout

Integrated: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

On Thu, 3 Dec 2020 12:55:04 GMT, Per Liden wrote: > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying > problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side > with calls to `newInstance(

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3]

On Tue, 8 Dec 2020 22:37:13 GMT, Chris Plummer wrote: >> Per Liden has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix copyright > > Marked as reviewed by cjplummer (Reviewer). Thanks for reviewin

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

On Mon, 25 Jan 2021 13:23:27 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > Changes requested by ihse (

RFR: 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles

JDK-8240679 introduced a change where the information exposed via the GarbageCollectorMXBean went from being related to the GC pauses to instead be related to the GC cycles. This helped provide more accurate heap usage information. However, some users have noticed that that you no longer get ti

Integrated: 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles

On Wed, 14 Apr 2021 07:13:50 GMT, Per Liden wrote: > JDK-8240679 introduced a change where the information exposed via the > GarbageCollectorMXBean went from being related to the GC pauses to instead be > related to the GC cycles. This helped provide more accurate heap usage >

Re: RFR: 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles

On Thu, 15 Apr 2021 04:20:28 GMT, Serguei Spitsyn wrote: >> JDK-8240679 introduced a change where the information exposed via the >> GarbageCollectorMXBean went from being related to the GC pauses to instead >> be related to the GC cycles. This helped provide more accurate heap usage >> inform

Re: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3]

On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and >> `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request incrementally with one > additional commit since the last revisio

  1   2   >