From milan.mimica at gmail.com Sun Aug 20 08:57:29 2017 From: milan.mimica at gmail.com (Milan Mimica) Date: Sun, 20 Aug 2017 08:57:29 +0000 Subject: PRT memory usage Message-ID: Hello I'm (still) trying to figure our high memory usage by PRT. I have studied heapRegionRemSet.cpp code and came up with a calculation I need you to confirm. Given region size of 8M and default G1 settings: * max number of PRT instances is 2^12 for each HR * PRT size is 64MB I'm looking at the worst-case scenario and I don't dare to multiply the tree numbers. The cap is just to high. Am I missing something? Do only Young HR get a OtherRegionsTable? Where can I find the number of regions per generation? I cannot spot it in GC logs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Aug 21 16:42:18 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Aug 2017 18:42:18 +0200 Subject: PRT memory usage In-Reply-To: References: Message-ID: <1503333738.7185.27.camel@oracle.com> Hi, On Sun, 2017-08-20 at 08:57 +0000, Milan Mimica wrote: > Hello > > I'm (still) trying to figure our high memory usage by PRT. I have > studied heapRegionRemSet.cpp code and came up with a calculation I > need you to confirm. Given region size of 8M and default G1 settings: > * max number of PRT instances is 2^12 for each HR Where did you get the 2^12 from? > * PRT size is 64MB Not completely following, where from do you understand that max prt size is 64MB? 8M region size implies a 2k PRT (bitmap) size (one bit per 512 bytes) > > I'm looking at the worst-case scenario and I don't dare to multiply > the tree numbers. The cap is just to high. Am I missing something? > Do only Young HR get a OtherRegionsTable? All regions get them. But there are no PRTs from young regions to old regions. Humongous continues regions don't have any remembered set. > Where can I find the number of regions per generation? I cannot spot > it in GC logs. -Xlog:gc+heap=info gives you the following kind of output: [15.369s][info ][gc,heap????????] GC(0) Eden regions: 3->0(576) [15.369s][info ][gc,heap????????] GC(0) Survivor regions: 0->0(0) [15.369s][info ][gc,heap????????] GC(0) Old regions: 0->1 [15.369s][info ][gc,heap????????] GC(0) Humongous regions: 0->0 Here is some rough calculation for remembered set size for jdk8 (copy&pasted from some other email from some time ago - I did not check it again, so there might be some omissions): "[...] for every region in #non-young-regions: ? e1) coarse table: one bit for every #regions + MAX( ?????e2) sparse table: (2 * #regions) * (8 + #sparse-entries * 4) ?????e3) fine table: MIN(#fine-entries, #non-young-regions - 1) * (bit per #cards-per-region + 8 + 56) ? ) where: #regions = maximum number of regions in heap = -Xmx / G1HeapRegionSize #cards-per-region = G1HeapRegionSize / 512 #non-young-regions = #regions - #minimum-number-of-young-regions #minimum-number-of-regions = #regions * G1NewSizePercent / 100 #sparse-entries = G1RSetSparseRegionEntries #fine-entries = MIN(G1RSetRegionEntries, #non-young-regions) Default values of options: G1NewSizePercent = 5 G1RSetSparseRegionEntries = G1RSetSparseRegionEntriesBase * (log2(#G1HeapRegionSize-in-MB) + 1) G1RSetSparseRegionEntriesBase = 4 This is I think a reasonably accurate worst case memory usage. [...] The remembered set holds the greatest potential (but also the largest risk to introduce performance issues) for savings. This is due to the fact that actually every entry in a remembered set (there, every region A stores for every other region x_0, ..., x_n the cards that contain references to A) can either take memory in e1, e2, or e3 (actually only the latter two for simplicity). I.e. G1 can represent such an x_i in one of the data structures of e1, e2, and e3, with different memory/performance characteristics. The direction of representation is e2, then e3 and finally e1 (unfortunately there is no way to go back; when a region is freed, its remembered set goes back to e2). So what could be tried is trying to keep x_i at e2 level - that can be controlled by G1RSetSparseRegionEntries. A given value of G1RSetSparseRegionEntries indicates how many cards it can store - if that is not enough, it expands to e3. (Just for reference: G1RSetRegionEntries determines how many of e3 a remembered set for a region A can hold - if more, it selects one to evict to e1; this is the dreaded "coarsening" if you ever heard of it. Setting G1RSetRegionEntries to something >= the number of regions avoids that coarsening) Since e2 is slightly more memory efficient, it might be worth trying to bump G1RSetSparseRegionEntries. If you think all what I explained above is gibberish to you, and you are still interested, I can try to explain it a bit better :) JDK9 made e2 more memory-efficient (only takes 1/4th of memory as before), and does not create e1 if not needed. [...]" Hth, ? Thomas From milan.mimica at gmail.com Mon Aug 21 19:36:06 2017 From: milan.mimica at gmail.com (Milan Mimica) Date: Mon, 21 Aug 2017 19:36:06 +0000 Subject: PRT memory usage In-Reply-To: <1503333738.7185.27.camel@oracle.com> References: <1503333738.7185.27.camel@oracle.com> Message-ID: Hello Thomas pon, 21. kol 2017. u 18:42 Thomas Schatzl napisao je: > > need you to confirm. Given region size of 8M and default G1 settings: > > * max number of PRT instances is 2^12 for each HR > > Where did you get the 2^12 from? > A bit simplified calculation of OtherRegionsTable::_max_fine_entries: _max_fine_entries = G1RSetRegionEntries = G1RSetRegionEntriesBase * (region_size_log_mb + 1) where: G1RSetRegionEntriesBase = 256 region_size_log_mb ... is 3, not 23. Ok, I made a mistake here. > * PRT size is 64MB > > Not completely following, where from do you understand that max prt > size is 64MB? > > 8M region size implies a 2k PRT (bitmap) size (one bit per 512 bytes) > Ah yes, my bed. It made several miscalculations also here. > Do only Young HR get a OtherRegionsTable? > > All regions get them. But there are no PRTs from young regions to old > regions. Humongous continues regions don't have any remembered set. > So there is only old-to-young, for each young? > Where can I find the number of regions per generation? I cannot spot > > it in GC logs. > > -Xlog:gc+heap=info gives you the following kind of output: > > Great. Thanks! Since e2 is slightly more memory efficient, it might be worth trying to > bump G1RSetSparseRegionEntries. > You don't remember, but we've gone through this some months ago. It did help indeed. Thanks again. If you think all what I explained above is gibberish to you, and > you are still interested, I can try to explain it a bit better :) > No, I actually understood everything, and have gone through all this in the code already. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milan.mimica at gmail.com Wed Aug 23 11:01:17 2017 From: milan.mimica at gmail.com (Milan Mimica) Date: Wed, 23 Aug 2017 11:01:17 +0000 Subject: PRT memory usage In-Reply-To: <1503333738.7185.27.camel@oracle.com> References: <1503333738.7185.27.camel@oracle.com> Message-ID: pon, 21. kol 2017. u 18:42 Thomas Schatzl wrote: > > -Xlog:gc+heap=info gives you the following kind of output: > Unrecognized option: -Xlog:gc+heap=info Must be something else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yu.zhang at oracle.com Wed Aug 23 16:05:45 2017 From: yu.zhang at oracle.com (yu.zhang at oracle.com) Date: Wed, 23 Aug 2017 09:05:45 -0700 Subject: PRT memory usage In-Reply-To: References: <1503333738.7185.27.camel@oracle.com> Message-ID: <5f598c20-29f6-9491-1079-2e025de35641@oracle.com> If you are using jdk8, try -XX:+PrintHeapAtGC On 08/23/2017 04:01 AM, Milan Mimica wrote: > pon, 21. kol 2017. u 18:42 Thomas Schatzl > wrote: > > > -Xlog:gc+heap=info gives you the following kind of output: > > > Unrecognized option: -Xlog:gc+heap=info > Must be something else. > > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Wed Aug 23 17:41:12 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 23 Aug 2017 19:41:12 +0200 Subject: PRT memory usage In-Reply-To: <5f598c20-29f6-9491-1079-2e025de35641@oracle.com> References: <1503333738.7185.27.camel@oracle.com> <5f598c20-29f6-9491-1079-2e025de35641@oracle.com> Message-ID: <1503510072.16532.2.camel@oracle.com> Hi, On Wed, 2017-08-23 at 09:05 -0700, yu.zhang at oracle.com wrote: > If you are using jdk8, try -XX:+PrintHeapAtGC ? and -XX:+PrintHeapAtGCExtended if you really want extensive per- region information (at every GC). I do not think there is a switch that prints per-region type summary information in JDK8. -XX:PrintHeapAtGC only prints number of regions for eden and survivor iirc. Thomas > > On 08/23/2017 04:01 AM, Milan Mimica wrote: > > pon, 21. kol 2017. u 18:42 Thomas Schatzl > m> wrote: > > > > > > -Xlog:gc+heap=info gives you the following kind of output: > > > > > Unrecognized option: -Xlog:gc+heap=info? > > Must be something else. > > > > > > > > _______________________________________________ > > hotspot-gc-use mailing list > > hotspot-gc-use at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > ? > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use