Re: RFR: 8179387: Factor out CMS specific code from GenCollectedHeap into its own subclass

(I included hotspot-runtime-dev and serviceability-dev to review vmStructs.cpp changes. see below) Hi Erik, >> Ok, added those and some more that I found. Not sure why we'd need >> #include "gc/cms/concurrentMarkSweepGeneration.hpp" ? Left that out >> for now. > > Because you are accessing

Re: RFR: 8179387: Factor out CMS specific code from GenCollectedHeap into its own subclass

Am 20.07.2017 um 10:44 schrieb Erik Helin: > On 07/17/2017 02:07 PM, Roman Kennke wrote: >>>> Ok, added those and some more that I found. Not sure why we'd need >>>> #include "gc/cms/concurrentMarkSweepGeneration.hpp" ? Left that out >>>> for no

Re: RFR: 8179387: Factor out CMS specific code from GenCollectedHeap into its own subclass

: http://cr.openjdk.java.net/~rkennke/8179387/webrev.10/ <http://cr.openjdk.java.net/%7Erkennke/8179387/webrev.10/> I also need a 2nd reviewer. Roman Am 20.07.2017 um 10:44 schrieb Erik Helin: > On 07/17/2017 02:07 PM, Roman Kennke wrote: >>>> Ok, added those and some more that I fo

Re: RFR: 8189373: jmap -heap exited with error code

Am 18.10.2017 um 20:29 schrieb Roman Kennke: My recent CMSHeap extraction has broken the JVM servicability agent. It looks like I actually need a little bit more boilerplate to make it happy: http://cr.openjdk.java.net/~rkennke/8189373/webrev.00/ <http://cr.openjdk.java.net/%7Erken

Re: RFR: 8189373: jmap -heap exited with error code

Am 19.10.2017 um 14:27 schrieb David Holmes: On 19/10/2017 9:28 PM, Roman Kennke wrote: Hi David, hi Jini, thank you both for review! Now I need a sponsor. Final patch (incl. summary and reviewed-by): http://cr.openjdk.java.net/~rkennke/8189373/webrev.01/ <http://cr.openjdk.java.

Re: RFR: 8189373: jmap -heap exited with error code

- Jini is the expert so that's good enough for me. :) Reviewed. David On 19/10/2017 8:57 PM, Jini George wrote: Your changes look good to me, Roman. Nit: Please do change the copyright year to 2017 in CollectedHeapName.java. Thank you, Jini (not a Reviewer). On 10/18/2017 11:59 PM, Roman

RFR: 8189373: jmap -heap exited with error code

My recent CMSHeap extraction has broken the JVM servicability agent. It looks like I actually need a little bit more boilerplate to make it happy: http://cr.openjdk.java.net/~rkennke/8189373/webrev.00/ It does fix the test that's

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

, then the managers, then do something like generation->set_memory_manager(x). 3) In cmsHeap.cpp:54: maxSize should preferably not use camel case. Otherwise I think it looks good. Thanks, /Erik On 2017-11-27 10:30, Roman Kennke wrote: Erik implemented a few more refactorings and touch-ups,

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

that in the bootstrapping. Otherwise I think this looks good! Thanks, /Erik On 2017-11-28 12:22, Roman Kennke wrote: Hi Erik, Thanks for your review! All of the things that you mentioned should be addressed in the following changes: Differential: http://cr.openjdk.java.net/~rkennke/8191564/webrev

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Hi Erik, thanks for the review! I think this requires another reviewer from serviceability-dev. Who can I ping about this? Roman Hi Roman, Looks good now. Thanks for doing this. Thanks, /Erik On 2017-11-28 22:26, Roman Kennke wrote: Hi Erik, thank you for reviewing! You are right. I

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Including hotspot-runtime-dev... I need one more review (esp. for the src/hotspot/share/services part): http://cr.openjdk.java.net/~rkennke/8191564/webrev.06/ Thanks, Roman On 11/29/2017 09:39 AM, Roman Kennke wrote: Hi Erik, thanks for the review! I think this requires another reviewer

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Hi Mandy, thanks for reviewing! I think Erik Ö. already pushed it for me. A minor comment that GCMemoryManager could take an enum to indicate the type of this  GC action (major vs minor).   This can be a future cleanup. This may be overly restrictive: some GCs may not necessarily provide a

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Erik implemented a few more refactorings and touch-ups, and here is our final (pending reviews) webrev: http://cr.openjdk.java.net/~rkennke/8191564/webrev.04/ Compared to webrev.02, it improves the handling of gc-end-message, avoids dragging the GCMemoryManager through Generation and a few

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

After a few more discussions with Erik I made some more changes. MemoryService is now unaware of the number and meaning of GC memory managers (minor vs major). This should be better for GCs that don't make that distinction and/or use more different GCs (e.g. minor, intermediate, full). This

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

ot;hg rename" to move the files? The webrev suggests not. Thanks, David On 30/11/2017 1:38 AM, Roman Kennke wrote: Including hotspot-runtime-dev... I need one more review (esp. for the src/hotspot/share/services part): http://cr.openjdk.java.net/~rkennke/8191564/webrev.06/ Thanks, Roman

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Hi David, I added the tag as you proposed: Differential: http://cr.openjdk.java.net/~rkennke/8191564/webrev.08.diff/ Full: http://cr.openjdk.java.net/~rkennke/8191564/webrev.08/ Re-run tests without regressions. Roman On 30/11/2017 9:30 PM, Roman Kennke wrote: Hi David, yes I did

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Currently, there's lots of GC specific code sprinkled over src/hotspot/share/services. This change introduces a GC interface for that, and moves all GC specific code to their respective src/hotspot/share/gc directory. http://cr.openjdk.java.net/~rkennke/8191564/webrev.00/

RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

Currently, there's lots of GC specific code sprinkled over src/hotspot/share/services. This change introduces a GC interface for that, and moves all GC specific code to their respective src/hotspot/share/gc directory. http://cr.openjdk.java.net/~rkennke/8191564/webrev.00/

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

I had some off-band discussions with Erik Helin and re-did most of the changeset: - The GC interface now resides in CollectedHeap, specifically the two methods memory_managers() and memory_pools(), and is implemented in the various concrete subclasses. - Both methods return (by value) a

Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass

Am 02.11.2017 um 04:55 schrieb Kim Barrett: On Oct 25, 2017, at 4:07 AM, Roman Kennke <rken...@redhat.com> wrote: Hi Kim, hi Jini, thank you both for your reviews! I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): http://cr.openjdk.java.net/~r

Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass

Am 02.11.2017 um 04:55 schrieb Kim Barrett: On Oct 25, 2017, at 4:07 AM, Roman Kennke <rken...@redhat.com> wrote: Hi Kim, hi Jini, thank you both for your reviews! I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): http://cr.openjdk.java.net/~r

Re: GcInfo: longest pause duration?

Hi Paul, + hotspot-gc-dev. I’d say that hsperfdata is the right place to put detailed collector-specific data, and JMX the place to put anything that might be generalized. How far does anyone want to go with this? I took a look at Azul’s GC-related MXBean docs

Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass

at 12:39 PM, Roman Kennke <rken...@redhat.com> wrote: Am 18.10.2017 um 22:41 schrieb Kim Barrett: On Oct 18, 2017, at 4:04 PM, Roman Kennke <rken...@redhat.com> wrote: Am 18.10.2017 um 20:41 schrieb Kim Barrett: On Oct 18, 2017, at 8:08 AM, Roman Kennke <rken...@redhat.com> wr

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

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

Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass

Am 18.10.2017 um 22:41 schrieb Kim Barrett: On Oct 18, 2017, at 4:04 PM, Roman Kennke <rken...@redhat.com> wrote: Am 18.10.2017 um 20:41 schrieb Kim Barrett: On Oct 18, 2017, at 8:08 AM, Roman Kennke <rken...@redhat.com> wrote: Differential webrev: http://cr.openjdk.java.net/~rke

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

Hello all, Thanks so far for all the reviews and support! I forgot to update the 'round' yesterday. We are in round 3 now :-) Also, I fixed the numbering of my webrevs to match the review-round. ;-) Things we've changed today: - We moved shenandoah-specific code out of .ad files into our own

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

Hi Chris, Per, Shenandoah has the same problem, for the same reasons. And I'm not convinced that G1 is safe either, at least with -XX:+ClassUnloadingWithConcurrentMark. In my opinion, this whole code section needs to be rewritten to use something like CollectedHeap::object_iterate() (which is

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

ntentionally) is definitely >not acceptable. > >Thanks, >Vladimir > >On 11/30/18 1:55 AM, Roman Kennke wrote: >>>> Hi Per, >>>> >>>> Thanks for taking time to look at this! >>>> >>>> We will take care of all the issues you ment

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

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 tests - Trim unused code from Shenandoah's SA impl -

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

Hi Magnus, >> I got reviews for shared-build, but an earlier version, so maybe makes >> sense to look over this again. Erik J, Magnus? > > Build changes look good. Thanks, Magnus! Roman signature.asc Description: OpenPGP digital signature

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

eads > not make sense for Shenandoah (like it is for G1, ZGC, etc)? I suppose it does. I will add it. Thanks, Roman > Thank you, > Jini. > > > On 12/4/2018 12:57 AM, Roman Kennke wrote: >> Round 5 of Shenandoah review includes: >> - A fix for the @requires tag in TestFu

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

Hi Per, >> 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: >>   - Actual GC set by harness

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

Thanks, Leonid, for reviewing! Roman > Hi > > The shared tests changes looks good for me. Thank you for fixing and testing > different combinations. > > Leonid > >> On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote: >> >> Round 5 of Shenandoah review

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

Here comes round 6, possibly/hopefully the last round of webrevs for upstreaming Shenandoah: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ It incorporates: - renames vm_operations_shenandoah* to shenandoahVMOperations*, as suggested by Coleen - reshuffles gcCause in shared-gc SA as

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

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: - Actual GC set by harness is CMS *and*

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

Zhengyu's and Thomas' TaskQueue stuff landed in jdk/jdk and we integrated it into shenandoah/jdk and in the master patch and webrevs. I'm updating the webrevs in-place in: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ This is going to be the final webrev that I intend to push on

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

, passed: 72, failed: 1, skipped: 0 Am 08.12.18 um 12:33 schrieb Roman Kennke: > Zhengyu's and Thomas' TaskQueue stuff landed in jdk/jdk and we > integrated it into shenandoah/jdk and in the master patch and webrevs. > I'm updating the webrevs in-place in: > > http://cr.openjdk.ja

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

dimir > > On 11/30/18 1: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

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

    _shenandoah_traversal_gc, >     _shenandoah_upgrade_to_full_gc, > > ==> share/classes/sun/jvm/hotspot/runtime/VMOps.java > > It would be good to add 'ShenandoahOperation' to the VMOps enum (though > it is probably not in sync now). > > Thank you, > Jini. >

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

Hi Per, Thanks for looking again. I've fixed the ordering in shenandoah-dev: http://cr.openjdk.java.net/~rkennke/fix-macro-order/webrev.00/ and it will apear in the next round of webrevs. Thanks, Roman > Hi Roman, > > On 11/30/18 10:00 PM, Roman Kennke wrote: >> Hi all, &

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

loopopts.cpp when you check > is_ShenandoahBarrier(). And you don't do that in other files. > > Code in opto/macro.cpp is ugly but it is only the place so we can live > with it I think. > > Thanks, > Vladimir > > On 11/30/18 1:00 PM, Roman Kennke wrote: >> H

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

popts.cpp when you check >>> is_ShenandoahBarrier(). And you don't do that in other files. >>> >>> Code in opto/macro.cpp is ugly but it is only the place so we can live >>> with it I think. >>> >>> Thanks, >>> Vladimir >>> >>> O

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

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: - Actual GC set by harness is CMS *and*

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

they are: diagnostic flags. Makes sense? Thanks, 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/barrier

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

>> 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, it runs kindof like

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

s > > if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test > "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then > > > But it's a matter of preference, if you do not want to change. Otherwise > it looks good! > > /Magnus >> >> /Erik >&

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

eck, here: > >   # Disable unsupported GCs for Zero >   if HOTSPOT_CHECK_JVM_VARIANT(zero); then >     DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES epsilongc g1gc zgc" >   fi > > cheers, > Per > > On 11/26/18 11:47 PM, Erik Joelsson wrote: >> Build

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

r clarifying. Yeah, we already have a fix in shenandoah/jdk and it will appear in next round of reviews. Thanks, Roman > Thank you, > Jini > > On 11/29/2018 3:59 AM, Roman Kennke wrote: >> Alright, we fixed: >> - The minor issues that Kim reported in shared-gc >>

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

riants, which need to be subclasses of their non-Shenandoah-counterparts, and I don't see how to change that. Thanks for reviewing and helping! Roman > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/157c1130b46e/make/hotspot/gensrc/GensrcAdlc.gmk#l122 > > > On 11/28/18 2:29 PM, Roman

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

targeted JDK12 ~tomorrow. I intend/expect to push Shenandoah during the next couple of days, unless somebody speaks up until then :-) Thanks, Roman > > thanks, > Coleen > > On 12/4/18 3:37 PM, Roman Kennke wrote: >> Thanks, Leonid, for reviewing! >> >> Roman >&g

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

>>> You need to check if shenandoahgc is disabled first - check >>> DISABLED_JVM_FEATURES list (see code for jvmci). >> >> Why? If Shenandoah is disabled, it will be on this list, and therefore >> not be built (see JvmFeatures.gmk). > > Did you test with --with-jvm-variants=-shenandoahgc to make

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

Hi Vladimir, > On 11/27/18 1:37 AM, Roman Kennke wrote: >> Hi Vladimir, >> >>> You need to check if shenandoahgc is disabled first - check >>> DISABLED_JVM_FEATURES list (see code for jvmci). >> >> Why? If Shenandoah is disabled, it will be on

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

Thanks for reviewing, Erik! Roman > Build changes look ok to me. > > /Erik > > On 2018-11-26 13:39, Roman Kennke wrote: >> Hi, >> >> This is the first round of changes for including Shenandoah GC into >> mainline. >> I divided the review into

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

47 PM, Erik Joelsson wrote: >> Build changes look ok to me. >> >> /Erik >> >> On 2018-11-26 13:39, Roman Kennke wrote: >>> Hi, >>> >>> This is the first round of changes for including Shenandoah GC into >>> mainline. >>>

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

Hi Kim, >> Sections to review (at this point) are the following: >> >> *) shared-gc >> - This is mostly boilerplate that is common to any GC >> - referenceProcessor.cpp has a little change to make one assert not fail >> (next to CMS and G1) > > Ick. But I don’t have a better

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

ecific nodes. This looks intrusive. I hope you clean it up. > > Thanks, > Vladimir > > On 11/26/18 2:47 PM, Erik Joelsson wrote: >> Build changes look ok to me. >> >> /Erik >> >> On 2018-11-26 13:39, Roman Kennke wrote: >>> Hi, >>> >

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

Hi Per, > Hi Roman, > > On 11/26/18 10:39 PM, Roman Kennke wrote: > [...] >>   *) shared-serviceability >> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceability/> >> >> - The usual code to support another GC &g

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

Hi Kim, >> On Nov 27, 2018, at 4:46 AM, Roman Kennke wrote: >> >> Hi Kim, >> >>>> Sections to review (at this point) are the following: >>>> >>>> *) shared-gc >>>>- This is mostly boilerplate that is common to any GC

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

Hi Kim, >> On Nov 26, 2018, at 4:39 PM, Roman Kennke wrote: >> *) shared-gc >> - This is mostly boilerplate that is common to any GC >> - referenceProcessor.cpp has a little change to make one assert not fail >> (next to CMS and G1) >> - task

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

>> Hi Per, >> >>> Hi Roman, >>> >>> On 11/26/18 10:39 PM, Roman Kennke wrote: >>> [...] >>>>    *) shared-serviceability >>>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceability/> >&g

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

reg/gc/metaspace/TestMetaspacePerfCounters.java.sdiff.html > Also these tests are going to be run with all GC and fails if Shenandoah > is not supported. Right. I fixed those and a few others I have found. Those which drive Shenandoah at runtime now have a runtime check (GC.Shenandoah.is

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

Alright, we fixed: - The minor issues that Kim reported in shared-gc - A lot of fixes in shared-tests according to Leonid's review - Disabled SA heapdumping similar to ZGC as Per suggested Some notes: Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually correct. The @requires there

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

Hi, This is the first round of changes for including Shenandoah GC into mainline. I divided the review into parts that roughly correspond to the mailing lists that would normally review it, and I divided it into 'shared' code changes and 'shenandoah' code changes (actually, mostly additions). The

Re: RFR(S) 8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes

Oops, totally forgot about that. Should this also go into jdk13 as bugfix? Roman Am 14. Juni 2019 17:50:57 MESZ schrieb Zhengyu Gu : >Please review this patch, that adjusts SA to reflect removal of extra >header for forwarding pointer. > >Bug: https://bugs.openjdk.java.net/browse/JDK-8225801

Re: RFR(T) 8225804: SA: Remove unused CollectedHeap.oopOffset() method

Looks good. Thanks, Roman Roman > Please review this patch that removes a method that is no longer needed. > > CollectedHeap.oopOffset() was added for Shenandoah GC to offset extra > header for forwarding pointer. Recently, Shenandoah removed the header > and folded the forwarding pointer into

Re: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier

iews for this version? I'd also like to ask others to at > least partially look at this: > > 1) Platform maintainers probably want to run this patch through their > build system. > 2) SA maintainers (CC:ed serviceability-dev) > 3) JVMCI maintainers > > Thanks, > Stef

Re: RFR (XS/T) 8231931: [TESTBUG] serviceability/sa/TestUniverse.java looks for wrong string with Shenandoah

Looks good to me. Thanks, Roman > Trivial test bug: > https://bugs.openjdk.java.net/browse/JDK-8231931 > > Fix: > > diff -r f9cd97ec8549 test/hotspot/jtreg/serviceability/sa/TestUniverse.java > --- a/test/hotspot/jtreg/serviceability/sa/TestUniverse.javaMon Oct 07 > 11:45:11 2019 +0200

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

link them directly upon unload, and build the > unloaded-signatures list there, but I don't currently see that it's > worth the effort). > > In addition to all that, this process is only activated when there's an > actual listener registered for EI_GC_FINISH. > > Thanks, > Rom

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

to expect. >>> >>> (I have some ideas how to improve the implementation to ~O(1) but it >>> would be considerably more complex: have to maintain a (hash)table that >>> maps tags -> KlassNode*, unlink them directly upon unload, and build the >>> unload

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

Hi Coleen, >>> I'll have a look at this, although it might not be for a few days. In >>> the meantime, maybe you can describe your new implementation in >>> classTrack.c so it's easier to look through the changes. >> Sure. >> >> The purpose of this class-tracking is to be able to determine the >>

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

ould be considerably more complex: have to maintain a (hash)table that >> maps tags -> KlassNode*, unlink them directly upon unload, and build the >> unloaded-signatures list there, but I don't currently see that it's >> worth the effort). >> >> In addition to all that, this process i

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

unload, and build the unloaded-signatures list there, but I don't currently see that it's worth the effort). In addition to all that, this process is only activated when there's an actual listener registered for EI_GC_FINISH. Thanks, Roman > Chris > > On 12/18/19 5:05 AM, Roman Kennke wrote

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

s->klass_tag != tag) { // klass not found - ignore. > debugMonitorExit(deletedSignatureLock); > return; > } > > It will take more time when I get a chance to look at the rest. > > > Thanks, > Serguei > > > > > On 12/21/19 13:24, Roman Kennke wrote: &

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

NULL && klass->klass_tag != tag) { >> klass_ptr = >next; >> klass = *klass_ptr; >> } >> if (klass == NULL || klass->klass_tag != tag) { // klass not found - ignore. >> debugMonitorExit(deletedSignatureLock); >> return; >> } >> &g

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

reen: mach5-one-rkennke-JDK-8227269-2-20200325-1421-9706762 Thanks, Roman > thanks, > > Chris > > On 3/25/20 6:00 AM, Roman Kennke wrote: >> Hi Sergei, >> >>> The fix looks pretty clean now. >>> I also like new name of the lock.:) >> Thank

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

ption.java > vmTestbase/nsk/jdwp/VirtualMachine/Dispose/dispose001/TestDescription.java > > thanks, > > Chris > > > On 3/25/20 11:37 AM, Roman Kennke wrote: >> Hi Chris, >> >>> Regarding the new assert: >>> >>>  105 if

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

The new job finished, its ID is: mach5-one-rkennke-JDK-8227269-2-20200325-2027-9716289 Thank you, Roman > Yes, please submit a new job. I'll start my testing once I see that the > builds are done. > > Chris > > On 3/25/20 12:59 PM, Roman Kennke wrote: >> Hi Chris,

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

h. Let me know if you want me to run any specific tests. Thank you, Roman > Thanks, > Serguei > > > On 3/20/20 08:30, Roman Kennke wrote: >> I believe I came up with a much simpler solution that also solves the >> problems of the existing one, and the ones I propose

Re: RFR (XS) 8241750: x86_32 build failure after JDK-8227269

Looks good to me, thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8241750 > > Fix: > > diff -r fef47d126675 src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c > --- a/src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c Fri Mar 27 > 15:33:24 2020 +0100 > +++

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

re > seeing before your changes, and your changes resolved it, or it was > initially caused by an earlier version of your changes, and you later > fixed it. We just want to better understand what this issue was and how > it was fixed. > > thanks, > > Chris > > On 3/2

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

alized, >> nobody's interested 153 // Class tracking not initialized yet, >> nobody's interested 158 /* Check this is not a duplicate */ Missed dot >> at the end. 106 if (klass != NULL || klass->klass_tag != tag) { // >> klass not found - ignore. In opposite, dot is not ne

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

: >> Invoke the callback when classes are freed, find and record the >> signature in deletedSignatureBag. >> >> 96 // Find deleted KlassNode 133 // Class tracking not initialized, >> nobody's interested 153 // Class tracking not initialized yet, >> nobody's

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

or so. Thanks, Roman > thanks, > > Chris > > On 3/20/20 12:52 PM, Chris Plummer wrote: >> On 3/20/20 8:30 AM, Roman Kennke wrote: >>> I believe I came up with a much simpler solution that also solves the >>> problems of the existing one, and the ones I propose

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

291 void >>>>>>>    292 classTrack_reset(void) >>>>>>>    293 { >>>>>>> 294 int idx; >>>>>>> 295 debugMonitorEnter(deletedSignatureLock); >>>>>>> 296 >>>>>>> 297 f

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty wrote: >> This RFE is to migrate the following field to OopStorage: >> >> class ObjectMonitor { >> >> void* volatile _object; // backward object pointer - strong root >> >> Unlike the previous patches in this series, there are a lot of

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]

On Mon, 14 Sep 2020 13:48:25 GMT, Daniel D. Daugherty wrote: > @rkennke - Thanks for the review. I believe @fisk is going to address > your comments. Actually, if I understand it correctly, OopStorage already gives us full barriers, so we should be covered, and we can simply revert

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]

On Mon, 14 Sep 2020 18:55:38 GMT, Daniel D. Daugherty wrote: >> This RFE is to migrate the following field to OopStorage: >> >> class ObjectMonitor { >> >> void* volatile _object; // backward object pointer - strong root >> >> Unlike the previous patches in this series, there are a lot of

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]

On Mon, 14 Sep 2020 20:21:23 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/gc/shared/space.inline.hpp line 176: >> >>> 174: assert(!space->scanned_block_is_obj(cur_obj) || >>> oop(cur_obj)->mark_raw().is_unlocked() || >>> 175:

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]

On Mon, 14 Sep 2020 18:59:06 GMT, Daniel D. Daugherty wrote: > @coleenp, @rkennke, and @kimbarrett - I believe all of the changes that you > have requested > have been made. Please confirm by re-reviewing. It looks good to me now! I've also build with Shenandoah GC, and run our sanity-tests

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]

On Mon, 14 Sep 2020 20:51:34 GMT, Daniel D. Daugherty wrote: >> This code seems like something that doesn't belong here anymore. This code >> assumed synchronous scanning of oops in >> ObjectMonitor and scanning memory regions, and that's no longer the case >> with OopStorage. I think this

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

On Tue, 29 Sep 2020 07:28:20 GMT, Per Liden wrote: >> FTR, this is the RFE to remove the oop verification from the oop_iterate >> framework: >> https://bugs.openjdk.java.net/browse/JDK-8237363 >> >> I really would like to get rid of it, but got push back because it made GCs >> have to

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

On Tue, 29 Sep 2020 10:02:16 GMT, Erik Österlund wrote: >> IMO it's ok to remove it. >> However, it can be argued that is_in() should not check for 'in committed >> memory' but 'in reserved space for heap', IOW >> 'is this a pointer into our heap memory region?'. Or maybe this would be >>

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

On Mon, 28 Sep 2020 12:14:11 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: libjdwp crash while debugging application ran on OpenJDK 16

Hi Simon, my colleagues recently ran into a crash in libjdwp, when measuring performance with OpenJDK 17 (early access build). The same crash was observed with OpenJDK 16.0.1, but not with OpenJDK 15. We are hoping to get a fix for the crash, before the official OpenJDK 17 release. We've

Re: [jdk17] RFR: 8269232: assert(!is_jweak(handle)) failed: wrong method for detroying jweak

On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer wrote: > Don't let node->strongRef go below 0, or we end up thinking we still have a > strongref when it is a weakref. Note the fact that we are doing nesting > counts is still a bug (and the main cause of this issue). However, the fix > for

Re: RFR: 8264311: Heap object statistics

On Tue, 30 Mar 2021 17:12:52 GMT, Chris Plummer wrote: > You'll need a CSR for this enhancement. Hmm, yeah. I'm wondering if this should rather go into the Lilliput repository once it is created (I'd expect in ~1week or so). Then it would be refined during Lilliput project live time, and

Re: RFR: 8264311: Heap object statistics

On Fri, 2 Apr 2021 17:46:35 GMT, Serguei Spitsyn wrote: > Hi Roman, > Do you have any test case verifying this? > Thanks, > Serguei Hi Serguei, no, not yet, but I will add some. Thanks for the suggestion! - PR: https://git.openjdk.java.net/jdk/pull/3271

Possible memory leak in invoker_completeInvokeRequest()?

A user is reporting a memory leak starting from invoker_completeInvokeRequest(). Consider the trace below (relative to JDK11): It looks like invoker_completeInvokeRequest() calls outStream_writeValue(), which calls outStream_writeObjectRef(), which then ends up calling commonRef_refToID().

RFR: 8283710: JVMTI: GC abstraction for ObjectMarker

JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in

Re: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations

On Tue, 1 Feb 2022 19:26:19 GMT, Chris Plummer wrote: > Shouldn't this be done when the invoke has completed rather than at the start > of the next invoke? Otherwise you potentially have one outstanding allocation > for every thread, and you still have a leak when the thread exits. Yes,

  1   2   >