Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987 [v3]

On Thu, 20 Jan 2022 04:22:28 GMT, Chris Plummer wrote: >> The JDWP spec mentions nothing about `DisableCollection` and >> `EnableCollection` tracking the depth or nesting of the commands. This means >> that `EnableCollection` should enable collection no matter how many >> `DisableCollection`

Re: RFR: 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper

On Mon, 22 Nov 2021 13:49:02 GMT, Erik Österlund wrote: > The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is > constructed right before running a parallel operation with a work gang, but > freed in the destructor of the VM_HeapDumper. This means it is created on one

Re: RFR: 8275035: Clean up worker thread infrastructure [v2]

On Thu, 14 Oct 2021 09:03:18 GMT, Per Liden wrote: >> I propose that we clean up our GangWorker/WorkGang and related classes, to >> remove abstractions we no longer need (after CMS was removed, >> MutexDispatcher was removed, Parallel is now using WorkGang, etc) and

Integrated: 8275035: Clean up worker thread infrastructure

On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to > remove abstractions we no longer need (after CMS was removed, MutexDispatcher > was removed, Parallel is now using WorkGang, etc) and adjusting names as

Re: RFR: 8275035: Clean up worker thread infrastructure [v2]

g: Passes Tier 1-3 on all Oracle platforms. Per Liden has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge master - Clean up naming in ReferenceProcessor - Clean up naming in Shenandoah - Clean up naming in HeapDum

RFR: 8275035: Clean up worker thread infrastructure

I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: * Rename AbstractGangTask to WorkerTask * Rename WorkGang

Re: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842 [v5]

On Mon, 27 Sep 2021 14:28:43 GMT, Lin Zang wrote: >> The root cause for crash in ZGC is that the JNIHandles are processed before >> object iteration. And ZGC would update the JNIHandles at object iteration >> with read barrier. So the crash is cause by accessing the invalid address >> which

Re: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842 [v4]

On Mon, 27 Sep 2021 12:02:53 GMT, Lin Zang wrote: >> The root cause for crash in ZGC is that the JNIHandles are processed before >> object iteration. And ZGC would update the JNIHandles at object iteration >> with read barrier. So the crash is cause by accessing the invalid address >> which

Re: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842 [v2]

On Sun, 26 Sep 2021 08:02:33 GMT, Lin Zang wrote: >> The root cause for crash in ZGC is that the JNIHandles are processed before >> object iteration. And ZGC would update the JNIHandles at object iteration >> with read barrier. So the crash is cause by accessing the invalid address >> which

Integrated: 8273482: Remove "foreground work" concept from WorkGang

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden wrote: > JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a > special case for use by the HeapDumper. I propose that we remove this code, > since this special use case can be solved without the n

Re: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]

On Thu, 9 Sep 2021 20:07:25 GMT, Per Liden wrote: >> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a >> special case for use by the HeapDumper. I propose that we remove this code, >> since this special use case can be solved with

Re: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]

On Fri, 10 Sep 2021 07:52:32 GMT, Ralf Schmelter wrote: > The reason I've added this was, that for the shenandoah GC the heap iteration > would run into assertions if not called from the VM thread. Maybe this has > changed in the meantime. As mentioned in my previous comment. This PR removes

Re: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]

ity/dcmd/gc/ > - Manually ran jcmd GC.heap_dump with various GCs enabled Per Liden has updated the pull request incrementally with one additional commit since the last revision: Remove asserts - Changes: - all: https://git.openjdk.java.net/jdk/pull/5410/files - new:

Re: RFR: 8273482: Remove "foreground work" concept from WorkGang

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden wrote: > JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a > special case for use by the HeapDumper. I propose that we remove this code, > since this special use case can be solved without the n

RFR: 8273482: Remove "foreground work" concept from WorkGang

JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang. As far as I can tell, there's no

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

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 >>

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 >

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

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

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

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 `newInsta

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

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 >>

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 the

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

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 t

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

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/jdi`

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()`.

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 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()`.

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 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 sugg

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 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 >

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

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

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

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

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

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

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

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

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

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: 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

(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, the t

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

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: Reingruber, Richard

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

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

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

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

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

/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 deliberate decision to not support

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

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 ZGC's design

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

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 vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC

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

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 that use case

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

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 properly respect address space limitations

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

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: >

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

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:

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;

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()

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

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 Thu, Dec 13,

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

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 dig into this some more

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: Hi

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

://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 (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: -

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: 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.java.net

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

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

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

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: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

!= "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/browse/JDK-8214484 We

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 heap

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 enabled

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

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.java.net

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 (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

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" +

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

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

is 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. &

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

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 heapIteration

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

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

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

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: 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, > > Done

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

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 really

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 class

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

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 hence might have

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: 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,

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

  1   2   >