From david.holmes at oracle.com Mon Feb 2 04:51:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Feb 2015 14:51:51 +1000 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken Message-ID: <54CF0267.4080308@oracle.com> http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ Original bug is confidential but the backport issue is not: https://bugs.openjdk.java.net/browse/JDK-8072057 Simple fix to ensure header inclusion is guarded based on all GCs being included. This fix is not applicable to 9 due to the changes there that have removed the parNew and defNew support. In fact inclusion of this header is no longer needed in 9 and I've filed https://bugs.openjdk.java.net/browse/JDK-8072056 to clean that up. Thanks, David From thomas.schatzl at oracle.com Mon Feb 2 09:43:34 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Feb 2015 10:43:34 +0100 Subject: RFR (S): 8069760: When iterating over a card, G1 often iterates over much more references than are contained in the card In-Reply-To: <7D82DB74-E5AD-4F15-824A-8C1E444B6629@oracle.com> References: <1422364908.3369.15.camel@oracle.com> <1AF5EC9D-441B-4A60-9DAD-912801745E9F@oracle.com> <1422450023.3257.1.camel@oracle.com> <1422612322.3155.2.camel@oracle.com> <7D82DB74-E5AD-4F15-824A-8C1E444B6629@oracle.com> Message-ID: <1422870214.3346.3.camel@oracle.com> Hi Kim, Mikael, On Fri, 2015-01-30 at 19:20 -0500, Kim Barrett wrote: > On Jan 30, 2015, at 5:05 AM, Thomas Schatzl wrote: > > > > New webrevs: > > http://cr.openjdk.java.net/~tschatzl/8069760/webrev.1_to_2/ (diff) > > http://cr.openjdk.java.net/~tschatzl/8069760/webrev.2/ (full) > > Looks good. thanks for the reviews. Thomas From thomas.schatzl at oracle.com Mon Feb 2 10:15:07 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Feb 2015 11:15:07 +0100 Subject: RFR: 8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure In-Reply-To: <54CA1FCB.4050403@oracle.com> References: <54CA1FCB.4050403@oracle.com> Message-ID: <1422872107.3346.5.camel@oracle.com> Hi all, On Thu, 2015-01-29 at 12:55 +0100, Stefan Johansson wrote: > Hi, > > Please review this fix for: > https://bugs.openjdk.java.net/browse/JDK-8069034 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8069034/hotspot.00/ > > Summary: > While looking for humongous objects to reclaim we unconditionally > dirtied cards, some of those might belong to freed regions and if so the > card table verification will fail. The simple fix is to avoid this by > checking that the card belong to live regions before dirtying. A more > robust fix would be to have the iterator avoid returning invalid cards, > but that is a bigger change and I will file an RFE for this. I would prefer if the comment were more detailed in why this check is required, e.g. something like "The remembered set might contain references to already freed region. Filter them out to to avoid failing assertions." or so. Also, just in case somebody is interested why this only fails now: there has always been the possibility of remembered sets containing references to regions that have been freed. Until JDK-8048179 no code used the remembered sets to mark the card table - we only spend time to scan through such regions at this time, which seems day one behavior. Btw, the RFE number filed by Stefan is https://bugs.openjdk.java.net/browse/JDK-8071913 There I added a pointer to this change to remove this change as soon as any more involved change has been implemented. Looks okay otherwise. Thanks, Thomas From thomas.schatzl at oracle.com Mon Feb 2 10:51:30 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Feb 2015 11:51:30 +0100 Subject: RFR: 8030646: Track collection set membership in one place In-Reply-To: References: <20150126110251.GB2775@ehelin.jrpg.bea.com> Message-ID: <1422874290.3346.7.camel@oracle.com> Hi Kim, > Coming in late: > > In the comments for JDK-8027959 > https://bugs.openjdk.java.net/browse/JDK-8027959 > Early reclamation of large objects in G1 > > Thomas said: > > ------------------------------------------------------------------------------ > > In reply to the previous comment: > > > > Putting the humongous objects (even temporarily) into the collection > > set gives issues with remembered set updates not occurring any more. > > > > Current prototype changes in_cset_fast_test to include humongous > > objects ( > > There are no issues with remembered set updates when temporarily > putting the humongous object into the _in_cset_fast_test collection > set test because during rset update we use the _in_collection_set > member of the heapregion, not the in_cset_fast_test. This mentions an older version of the change, that has not even been out for review. As the date of the original comment suggests, we had a prototype running for months before the review. If you look in the update rs closure (G1UpdateRSOrPushRefOopClosure::do_oop_work()), it uses "to->in_collection_set()" in the condition to either remember the reference for a possible evacuation failure, or adding the reference to the correct remembered set. *If* we really temporarily added humongous into the cset, this would be a problem. However the current implementation is correct, because the humongous objects are never even added temporarily to the collection set as stated in that comment. They have their own value (-1) in the in_cset_fast_table. As long as the new code uses only G1CollectedHeap::is_in_cset() instead of G1Collectedheap::is_in_cset_or_humongous(), it is fine. Sorry for the misleading comment, I will add another one about the current implementation. It was more a very late answer about the to the previous one (that predates the recent one by four months, i.e. differnet implementation). Thanks, Thomas From stefan.johansson at oracle.com Mon Feb 2 13:28:25 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 02 Feb 2015 14:28:25 +0100 Subject: RFR: 8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure In-Reply-To: <1422872107.3346.5.camel@oracle.com> References: <54CA1FCB.4050403@oracle.com> <1422872107.3346.5.camel@oracle.com> Message-ID: <54CF7B79.2090506@oracle.com> Hi Thomas, On 2015-02-02 11:15, Thomas Schatzl wrote: > Hi all, > > On Thu, 2015-01-29 at 12:55 +0100, Stefan Johansson wrote: >> Hi, >> >> Please review this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8069034 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8069034/hotspot.00/ >> >> Summary: >> While looking for humongous objects to reclaim we unconditionally >> dirtied cards, some of those might belong to freed regions and if so the >> card table verification will fail. The simple fix is to avoid this by >> checking that the card belong to live regions before dirtying. A more >> robust fix would be to have the iterator avoid returning invalid cards, >> but that is a bigger change and I will file an RFE for this. > I would prefer if the comment were more detailed in why this check is > required, e.g. something like "The remembered set might contain > references to already freed region. Filter them out to to avoid failing > assertions." or so. I changed it to: // The remembered set might contain references to already freed // regions. Filter out such entries to avoid failing card table // verification. New webrev: http://cr.openjdk.java.net/~sjohanss/8069034/hotspot.01 > Also, just in case somebody is interested why this only fails now: there > has always been the possibility of remembered sets containing references > to regions that have been freed. Until JDK-8048179 no code used the > remembered sets to mark the card table - we only spend time to scan > through such regions at this time, which seems day one behavior. > > Btw, the RFE number filed by Stefan is > > https://bugs.openjdk.java.net/browse/JDK-8071913 > > There I added a pointer to this change to remove this change as soon as > any more involved change has been implemented. Thanks for updating the RFE with more information, Stefan > Looks okay otherwise. > > Thanks, > Thomas > > From yasuenag at gmail.com Mon Feb 2 15:51:13 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 Feb 2015 00:51:13 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Message-ID: Hi, I need more reviewer. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ Thanks, Yasumasa 2015/01/28 17:24 "Staffan Larsen" : > Looks good! > > Thanks, > /Staffan > > > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: > > > > Hi Staffan, Kirk, > > > > I agree to set "Diagnostic Command" to GCCause. > > So I applied it to new patch. > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > > > Could you review it again? > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/28 5:06, Kirk Pepperdine wrote: > >> Hi Staffan, > >> > >>>> > >>>> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. > Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the > context. > >>> > >>> Let?s go with ?Diagnostic Command?, then. > >> > >> Thank you! > >> > >> Regards, > >> Kirk > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Feb 2 16:58:23 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Feb 2015 17:58:23 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <54CC1142.7030200@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC1142.7030200@oracle.com> Message-ID: <1422896303.3346.18.camel@oracle.com> Hi, there have been multiple questions about this because my explanation was too confusing. Sorry. I will try to clear this up in the following. The main reason as to why there is the limitation of requiring large page alignment of auxiliary data structures is that it simplifies management of the pages a lot with little downside. Very long, sorry. On Fri, 2015-01-30 at 15:18 -0800, Jon Masamitsu wrote: > On 1/29/2015 2:30 AM, Thomas Schatzl wrote: > > ... > > AAAAAA AAAAAA AAAAAA // heap area, each AAAAAA is a single region > > | | | // area covered by auxilary pages > > 1 2 // auxiliary data pages > > Are bitmaps an example of the auxiliary data? Prev/next bitmaps, BOT, card table, and card counts table (some helper structure for the hot card cache). > AAAAAA are 6 regions? > Yes, as an example. > And the preferred layout would be > > AAAAAA AAAAAA AAAAAA // heap area, each AAAAAA is a single region > > | | | | // area covered by auxilary pages > > 1 2 // auxiliary data pages > > so that (regions replace by 0 have been uncommitted) > > AA00AA 000000 A000AA // heap area, each AAAAAA is a single region > > | | | | // area covered by auxilary pages > > 1 2 // auxiliary data pages > > > then the page for 2 can be uncommitted. Yes. > > So if auxiliary data pages were unaligned, so that they correspond to > > uneven multiples of the heap, when uncommitting e.g. the second region > > (second set of AAAAAA), we would have to split the auxiliary data pages > > 1 and 2 into smaller ones. > > You mean we would have to use small pages for the auxiliary data? > So we could uncommit the auxiliary data pages corresponding to the > heap uncommit more easily? This is option (1). Which is bad performance-wise and caused the regression. ---------- The other is option (2) that is to track to which pages a particular region corresponds to (which might be a mix of small and large pages) in detail, and commit and uncommit them accordingly. Example that shows a mix of small/large pages used: (I will use the BOT as representative for one of the auxiliary data structures mentioned above in the following. The problem is the same for them). 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 // heap region layout | S | L | L | // area covered by BOT page below b1 b2 b3 // BOT page number I.e. the first row shows heap regions, the same numbers indicate that this is the same region. I.e. the first six "1" represent the memory of region 1. The second row is how the pages representing e.g. the BOT map to heap regions. In our setup there is one small region (S) followed by a sequence of large regions. (For simplicity I made small regions exactly the half the size of large ones). The third row is the BOT page number. E.g. page b1 is small, covering half of region 1, page b2 covers half of region 1 and 2, and so on. Now, if I uncommit region 1, I can only uncommit b1, and need to remember that half of b2 is also unused. Then, when trying to uncommit b2, you need not only check whether region 2 is uncommitted, but also whether it might be in use for region 1 or 3. (This might lead into situation where we cannot uncommit anything btw as there might always something holding on to the BOT pages if only every other region is committed). At the same time, when uncommitting b3, it might also cascade into b2 and any following b4, i.e. need to uncommit that too. The reverse situation, when committing new regions, we also add complexity. E.g. assume that everything is uncommitted, and we want to commit region 2. Now I need to make sure to commit b2 and b3. In the same way, if you then want to commit region 3, you must make sure that you do not commit b2 again. ---------- Another option (3) would be to always use small pages in the border areas between heap regions to avoid a single page in the BOT corresponding to some heap region. Still you need to do some address calculations, splitting all regions into left/middle/right areas that need to be (un-)committed separately. That increases the number of required TLB entries by at least a factor of 33 (32M pages, 15 large pages + 512 small pages/region vs. 16 large pages) compared to being aligned. Much worse for smaller region sizes. (e.g. 4M region size, 1 large + 512 small vs. 2 large pages, factor 256 2M region size, 512 small vs. 1 large, factor 512 1M region size, 512 small vs. 1/2 large) I do not think option (3) is a good trade-off. It would particularly hurt small heaps (e.g. 1 or 2M region size, eg. on 32 bit systems), making enabling large pages basically useless because due to splitting we only use small pages anyway there as shown above. On large heaps (e.g. using 64 bit systems) it should not matter to waste at most one large page in committed and reserved space. Now we could play tricks like splitting/merging pages on demand, but that is even more complicated for no particular gain imo. ---------- Option (4): Align the reserved space to a multiple of the large page size, ie. what is implemented right now. Examples for this case: 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 // heap region layout | L | L | L | // area covered by BOT page below b1 b2 b3 // BOT page number So in this case the operations on the auxiliary data is too simple, but the other cases are simple too: One BOT page corresponds to multiple regions: 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 // heap region layout | L | L | L | // area covered by BOT page below b1 b2 b3 // BOT page number or if one region corresponds to multiple BOT pages: 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2... // heap region layout | L | L | L | // area covered by BOT page below b1 b2 b3 // BOT page number In both of these cases there is absolutely no need to do any sort of complicated calculations about what to commit or uncommit. ------------ Maybe there are more possibilities. > > That does not seem to be a good tradeoff in complexity, given that the > > waste is at most one large page in reserved space (and unfortunately, > > due to the Linux large page implementation also in actually used space). > > The waste is 1 large page for each auxiliary data structure? Yes, at most. Here is a summary of the downsides of this approach to align the start of the auxiliary memory to large page size (if large page enabled): - on Solaris (or everything else that does not use the Linux large page code): the _reserved_ space is be one large page too large (if large pages used). The change never commits the additional reserved space. E.g.: we need a BOT of 2M+4k size, so we reserve a space of 4M, and only ever commit the 2M+4k. I can see if I can optimize this a little; the problem is that when trying to reserve memory, the code paths in the linux code have asserts that fail if the passed size is not aligned to the required alignment (UseHugeTLBFS) and requesting large pages, or just silently fall back to small pages (UseSHM). I did not want to have a Solaris specific code path in the g1 code and imo the larger reservation does not really matter. - on Linux: - when SHM is used: we reserve and possibly commit up to a single large page too much (actually large page - commit granularity page size). The code in G1CollectedHeap::create_aux_memory_mapper() tries to always get large pages by aligning up the requested size to large page size, because otherwise, if the requested size is not aligned to commit size, it falls back to the small pages code (i.e. ignores the request to get large page memory outright). - when HugeTLBFS is used (default): we reserve and commit up to a single large page too much. There is no code path to actually get large page granularity address aligned memory without having the size aligned to that granularity without asserts failing. --------------- Worst case memory impact: The BOT (and other similar sized data structures) only try to use large pages if the heap is >= 1G (on x86, large page size * 512), so only in case of such large heaps, you waste almost large page size (times three for the three data structures) - in Solaris only reserved space, on Linux also committed space. I.e. 0.6% of memory in total. The bitmaps only try to use large pages if >= 128M heap. This means that if you allocate a 129M heap, you waste almost 2M, i.e. additional 3% of heap for the two bitmaps. We might want to tune that by e.g. only using large pages if there are at least X full large pages to use. Currently this X is one (the same value as before). Also, the question is whether it is extremely useful to use large pages with a 128M heap. Not sure, I would guess it does not matter. Difference to previous behavior: Before that change of virtual space handling (<9b29), on Solaris, we reserved and committed only the exact amount of memory afaics. On Linux, we reserved and committed an exact number of large pages, or used small pages in fallback paths. That means, if the size of a particular data structure was not aligned to large page size, on Linux we always used small pages. This difference in behavior could be changed back if wanted, i.e. if the size we want to allocate is not aligned to large page size, use small pages (and not spend extra memory). ------------------- Performance impact analysis: - on Solaris: we are back to original performance at least. - on Linux: if large pages are available, G1 should be faster than before as G1 uses large pages more aggressively now. ------------------- Summarizing, I think the alignment requirement does not have a lot of impact on committed memory while keeping the code reasonably simple (and maybe somebody knows why it is not possible to get a reservation which address is large page aligned but is not a multiple of large page size). There is the problem that G1 uses slightly more reserved memory, i.e. an extra large page at the end of the heap at most. This does not seem to be a problem. On 64 bit systems reservations are not an issue. On 32 bit systems I do not consider this a problem either as the increase is small in absolute terms (at most one large page). The gain to implement option (2) or (3) above seems too small to me considering the downsides listed. I think the open question is on if and how to handle Linux better, i.e. either (on Linux only?) falling back to small pages on memory sizes that are not divisible by large page size (old behavior), or improving the Linux ReservedSpace code to allow "special" kind aligned reservations using large pages at the beginning and small pages at the end (that are pre-committed as before). Thanks, Thomas From jon.masamitsu at oracle.com Mon Feb 2 21:21:23 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 02 Feb 2015 13:21:23 -0800 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1422896303.3346.18.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC1142.7030200@oracle.com> <1422896303.3346.18.camel@oracle.com> Message-ID: <54CFEA53.8030507@oracle.com> Thomas, Thank you for the very detailed explanation. You answered all my questions and more. Jon On 02/02/2015 08:58 AM, Thomas Schatzl wrote: > Hi, > > there have been multiple questions about this because my explanation > was too confusing. Sorry. I will try to clear this up in the following. > > The main reason as to why there is the limitation of requiring large > page alignment of auxiliary data structures is that it simplifies > management of the pages a lot with little downside. > > Very long, sorry. > > On Fri, 2015-01-30 at 15:18 -0800, Jon Masamitsu wrote: >> On 1/29/2015 2:30 AM, Thomas Schatzl wrote: >>> ... >>> AAAAAA AAAAAA AAAAAA // heap area, each AAAAAA is a single region >>> | | | // area covered by auxilary pages >>> 1 2 // auxiliary data pages >> Are bitmaps an example of the auxiliary data? > Prev/next bitmaps, BOT, card table, and card counts table (some helper > structure for the hot card cache). > >> AAAAAA are 6 regions? >> > Yes, as an example. > >> And the preferred layout would be >> >> AAAAAA AAAAAA AAAAAA // heap area, each AAAAAA is a single region >> >> | | | | // area covered by auxilary pages >> >> 1 2 // auxiliary data pages >> >> so that (regions replace by 0 have been uncommitted) >> >> AA00AA 000000 A000AA // heap area, each AAAAAA is a single region >> >> | | | | // area covered by auxilary pages >> >> 1 2 // auxiliary data pages >> >> >> then the page for 2 can be uncommitted. > Yes. > >>> So if auxiliary data pages were unaligned, so that they correspond to >>> uneven multiples of the heap, when uncommitting e.g. the second region >>> (second set of AAAAAA), we would have to split the auxiliary data pages >>> 1 and 2 into smaller ones. >> You mean we would have to use small pages for the auxiliary data? >> So we could uncommit the auxiliary data pages corresponding to the >> heap uncommit more easily? > This is option (1). Which is bad performance-wise and caused the > regression. > > ---------- > > The other is option (2) that is to track to which pages a particular > region corresponds to (which might be a mix of small and large pages) in > detail, and commit and uncommit them accordingly. > > Example that shows a mix of small/large pages used: > > (I will use the BOT as representative for one of the auxiliary data > structures mentioned above in the following. The problem is the same for > them). > > 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 // heap region layout > | S | L | L | // area covered by BOT page below > b1 b2 b3 // BOT page number > > I.e. the first row shows heap regions, the same numbers indicate that > this is the same region. I.e. the first six "1" represent the memory of > region 1. > The second row is how the pages representing e.g. the BOT map to heap > regions. In our setup there is one small region (S) followed by a > sequence of large regions. (For simplicity I made small regions exactly > the half the size of large ones). > The third row is the BOT page number. E.g. page b1 is small, covering > half of region 1, page b2 covers half of region 1 and 2, and so on. > > Now, if I uncommit region 1, I can only uncommit b1, and need to > remember that half of b2 is also unused. > > Then, when trying to uncommit b2, you need not only check whether region > 2 is uncommitted, but also whether it might be in use for region 1 or 3. > (This might lead into situation where we cannot uncommit anything btw as > there might always something holding on to the BOT pages if only every > other region is committed). > > At the same time, when uncommitting b3, it might also cascade into b2 > and any following b4, i.e. need to uncommit that too. > > The reverse situation, when committing new regions, we also add > complexity. > > E.g. assume that everything is uncommitted, and we want to commit region > 2. Now I need to make sure to commit b2 and b3. In the same way, if you > then want to commit region 3, you must make sure that you do not commit > b2 again. > > ---------- > > Another option (3) would be to always use small pages in the border > areas between heap regions to avoid a single page in the BOT > corresponding to some heap region. > > Still you need to do some address calculations, splitting all regions > into left/middle/right areas that need to be (un-)committed separately. > > That increases the number of required TLB entries by at least a factor > of 33 (32M pages, 15 large pages + 512 small pages/region vs. 16 large > pages) compared to being aligned. Much worse for smaller region sizes. > > (e.g. > 4M region size, 1 large + 512 small vs. 2 large pages, factor 256 > 2M region size, 512 small vs. 1 large, factor 512 > 1M region size, 512 small vs. 1/2 large) > > I do not think option (3) is a good trade-off. It would particularly > hurt small heaps (e.g. 1 or 2M region size, eg. on 32 bit systems), > making enabling large pages basically useless because due to splitting > we only use small pages anyway there as shown above. On large heaps > (e.g. using 64 bit systems) it should not matter to waste at most one > large page in committed and reserved space. > > Now we could play tricks like splitting/merging pages on demand, but > that is even more complicated for no particular gain imo. > > ---------- > > Option (4): Align the reserved space to a multiple of the large page > size, ie. what is implemented right now. > > Examples for this case: > > 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 // heap region layout > | L | L | L | // area covered by BOT page below > b1 b2 b3 // BOT page number > > > So in this case the operations on the auxiliary data is too simple, but > the other cases are simple too: > > One BOT page corresponds to multiple regions: > > 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 // heap region layout > | L | L | L | // area covered by BOT page below > b1 b2 b3 // BOT page number > > or if one region corresponds to multiple BOT pages: > > 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2... // heap region layout > | L | L | L | // area covered by BOT page below > b1 b2 b3 // BOT page number > > In both of these cases there is absolutely no need to do any sort of > complicated calculations about what to commit or uncommit. > > ------------ > > Maybe there are more possibilities. > >>> That does not seem to be a good tradeoff in complexity, given that the >>> waste is at most one large page in reserved space (and unfortunately, >>> due to the Linux large page implementation also in actually used space). >> The waste is 1 large page for each auxiliary data structure? > Yes, at most. > > Here is a summary of the downsides of this approach to align the start > of the auxiliary memory to large page size (if large page enabled): > > - on Solaris (or everything else that does not use the Linux large page > code): the _reserved_ space is be one large page too large (if large > pages used). The change never commits the additional reserved space. > > E.g.: we need a BOT of 2M+4k size, so we reserve a space of 4M, and only > ever commit the 2M+4k. > > I can see if I can optimize this a little; the problem is that when > trying to reserve memory, the code paths in the linux code have asserts > that fail if the passed size is not aligned to the required alignment > (UseHugeTLBFS) and requesting large pages, or just silently fall back to > small pages (UseSHM). > > I did not want to have a Solaris specific code path in the g1 code and > imo the larger reservation does not really matter. > > - on Linux: > - when SHM is used: we reserve and possibly commit up to a single > large page too much (actually large page - commit granularity page > size). > The code in G1CollectedHeap::create_aux_memory_mapper() tries to always > get large pages by aligning up the requested size to large page size, > because otherwise, if the requested size is not aligned to commit size, > it falls back to the small pages code (i.e. ignores the request to get > large page memory outright). > > - when HugeTLBFS is used (default): we reserve and commit up to a > single large page too much. > > There is no code path to actually get large page granularity address > aligned memory without having the size aligned to that granularity > without asserts failing. > > --------------- > > Worst case memory impact: > > The BOT (and other similar sized data structures) only try to use large > pages if the heap is >= 1G (on x86, large page size * 512), so only in > case of such large heaps, you waste almost large page size (times three > for the three data structures) - in Solaris only reserved space, on > Linux also committed space. I.e. 0.6% of memory in total. > > The bitmaps only try to use large pages if >= 128M heap. This means that > if you allocate a 129M heap, you waste almost 2M, i.e. additional 3% of > heap for the two bitmaps. > > We might want to tune that by e.g. only using large pages if there are > at least X full large pages to use. Currently this X is one (the same > value as before). > > Also, the question is whether it is extremely useful to use large pages > with a 128M heap. Not sure, I would guess it does not matter. > > Difference to previous behavior: > > Before that change of virtual space handling (<9b29), on Solaris, we > reserved and committed only the exact amount of memory afaics. > On Linux, we reserved and committed an exact number of large pages, or > used small pages in fallback paths. That means, if the size of a > particular data structure was not aligned to large page size, on Linux > we always used small pages. > > This difference in behavior could be changed back if wanted, i.e. if the > size we want to allocate is not aligned to large page size, use small > pages (and not spend extra memory). > > ------------------- > > Performance impact analysis: > > - on Solaris: we are back to original performance at least. > > - on Linux: if large pages are available, G1 should be faster than > before as G1 uses large pages more aggressively now. > > ------------------- > > Summarizing, I think the alignment requirement does not have a lot of > impact on committed memory while keeping the code reasonably simple (and > maybe somebody knows why it is not possible to get a reservation which > address is large page aligned but is not a multiple of large page size). > > There is the problem that G1 uses slightly more reserved memory, i.e. an > extra large page at the end of the heap at most. This does not seem to > be a problem. On 64 bit systems reservations are not an issue. On 32 bit > systems I do not consider this a problem either as the increase is small > in absolute terms (at most one large page). > > The gain to implement option (2) or (3) above seems too small to me > considering the downsides listed. > > I think the open question is on if and how to handle Linux better, i.e. > either (on Linux only?) falling back to small pages on memory sizes that > are not divisible by large page size (old behavior), or improving the > Linux ReservedSpace code to allow "special" kind aligned reservations > using large pages at the beginning and small pages at the end (that are > pre-committed as before). > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Feb 3 00:06:08 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Feb 2015 01:06:08 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1422896303.3346.18.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC1142.7030200@oracle.com> <1422896303.3346.18.camel@oracle.com> Message-ID: <1422921968.3071.1.camel@oracle.com> Some correction: On Mon, 2015-02-02 at 17:58 +0100, Thomas Schatzl wrote: > Hi, > > there have been multiple questions about this because my explanation > was too confusing. Sorry. I will try to clear this up in the following. > > The main reason as to why there is the limitation of requiring large > page alignment of auxiliary data structures is that it simplifies > management of the pages a lot with lit [...] > > Another option (3) would be to always use small pages in the border > areas between heap regions to avoid a single page in the BOT > corresponding to some heap region. Forget that option, that does not work, and does not make sense given the context. A small page on the BOT corresponds to 2M on the heap, if you have the wrong region size (e.g. 1M) you can never do that and need to implement (2). And large pages cover a too large area to split anything (1G). This splitting stuff would only be an option if you allowed an unaligned heap. We do not. Sorry, Thomas From kim.barrett at oracle.com Tue Feb 3 01:25:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 2 Feb 2015 20:25:36 -0500 Subject: RFR: 8030646: Track collection set membership in one place In-Reply-To: <1422874290.3346.7.camel@oracle.com> References: <20150126110251.GB2775@ehelin.jrpg.bea.com> <1422874290.3346.7.camel@oracle.com> Message-ID: <42B592D7-07FF-4AA7-9F6C-EBB43DD4D260@oracle.com> On Feb 2, 2015, at 5:51 AM, Thomas Schatzl wrote: > > Hi Kim, > >> Coming in late: >> >> In the comments for JDK-8027959 >> https://bugs.openjdk.java.net/browse/JDK-8027959 >> Early reclamation of large objects in G1 >> >> Thomas said: >> >> ------------------------------------------------------------------------------ >>> In reply to the previous comment: >>> >>> Putting the humongous objects (even temporarily) into the collection >>> set gives issues with remembered set updates not occurring any more. >>> >>> Current prototype changes in_cset_fast_test to include humongous >>> objects ( >> >> There are no issues with remembered set updates when temporarily >> putting the humongous object into the _in_cset_fast_test collection >> set test because during rset update we use the _in_collection_set >> member of the heapregion, not the in_cset_fast_test. > > This mentions an older version of the change, that has not even been out > for review. > As the date of the original comment suggests, we had a prototype running > for months before the review. > > If you look in the update rs closure > (G1UpdateRSOrPushRefOopClosure::do_oop_work()), it uses > "to->in_collection_set()" in the condition to either remember the > reference for a possible evacuation failure, or adding the reference to > the correct remembered set. > *If* we really temporarily added humongous into the cset, this would be > a problem. > > However the current implementation is correct, because the humongous > objects are never even added temporarily to the collection set as stated > in that comment. They have their own value (-1) in the > in_cset_fast_table. > > As long as the new code uses only G1CollectedHeap::is_in_cset() instead > of G1Collectedheap::is_in_cset_or_humongous(), it is fine. > > Sorry for the misleading comment, I will add another one about the > current implementation. It was more a very late answer about the to the > previous one (that predates the recent one by four months, i.e. > differnet implementation). Thanks for the explanation, Thomas. That cleared things up for me quite well. From thomas.schatzl at oracle.com Tue Feb 3 09:35:39 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Feb 2015 10:35:39 +0100 Subject: RFR: 8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure In-Reply-To: <54CF7B79.2090506@oracle.com> References: <54CA1FCB.4050403@oracle.com> <1422872107.3346.5.camel@oracle.com> <54CF7B79.2090506@oracle.com> Message-ID: <1422956139.3368.2.camel@oracle.com> Hi Stefan, On Mon, 2015-02-02 at 14:28 +0100, Stefan Johansson wrote: > Hi Thomas, > > On 2015-02-02 11:15, Thomas Schatzl wrote: > > Hi all, > > > > On Thu, 2015-01-29 at 12:55 +0100, Stefan Johansson wrote: > >> Hi, > >> > >> Please review this fix for: > >> https://bugs.openjdk.java.net/browse/JDK-8069034 > >> > >> Webrev: > >> http://cr.openjdk.java.net/~sjohanss/8069034/hotspot.00/ > >> > >> Summary: > >> While looking for humongous objects to reclaim we unconditionally > >> dirtied cards, some of those might belong to freed regions and if so the > >> card table verification will fail. The simple fix is to avoid this by > >> checking that the card belong to live regions before dirtying. A more > >> robust fix would be to have the iterator avoid returning invalid cards, > >> but that is a bigger change and I will file an RFE for this. > > I would prefer if the comment were more detailed in why this check is > > required, e.g. something like "The remembered set might contain > > references to already freed region. Filter them out to to avoid failing > > assertions." or so. > > I changed it to: > // The remembered set might contain references to already freed > // regions. Filter out such entries to avoid failing card table > // verification. Looks good, thanks. Thomas From kirk at kodewerk.com Tue Feb 3 09:57:41 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 3 Feb 2015 10:57:41 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Message-ID: Hi, Not an official review but it?s a simple patch that looks good. Kind regards, Kirk On Feb 2, 2015, at 4:51 PM, Yasumasa Suenaga wrote: > Hi, > > I need more reviewer. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > Thanks, > > Yasumasa > > 2015/01/28 17:24 "Staffan Larsen" : > Looks good! > > Thanks, > /Staffan > > > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: > > > > Hi Staffan, Kirk, > > > > I agree to set "Diagnostic Command" to GCCause. > > So I applied it to new patch. > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > > > Could you review it again? > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/28 5:06, Kirk Pepperdine wrote: > >> Hi Staffan, > >> > >>>> > >>>> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. > >>> > >>> Let?s go with ?Diagnostic Command?, then. > >> > >> Thank you! > >> > >> Regards, > >> Kirk > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From thomas.schatzl at oracle.com Tue Feb 3 10:27:02 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Feb 2015 11:27:02 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <54CC0BCC.2090009@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> Message-ID: <1422959222.3368.4.camel@oracle.com> Hi Jon, thanks for the comments. I incorporated all of them in the latest webrev at http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1/ (full) http://cr.openjdk.java.net/~tschatzl/8058354/webrev.0_to_1/ (diff) There is also a small change to the WhiteBox class that I originally forgot to ask reviews for because it is tracked in the root directory: http://cr.openjdk.java.net/~tschatzl/8058354/webrev.hs-gc.1/ One comment further down. On Fri, 2015-01-30 at 14:55 -0800, Jon Masamitsu wrote: > Thomas, > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html > > Please verify that this should be a call to the _unaligned version. > > > 1840 size_t const commit_size = os::page_size_for_region_unaligned(size, 1); Yes. It ensures that as soon as the given size is larger than a large page, try to use large pages (if they are enabled). This is the same behavior as in 9b28. If we used os::page_size_for_region_aligned(), we would only try to use large pages in case the given size is exactly a multiple of large page size. Thanks, Thomas From sergei.kovalev at oracle.com Tue Feb 3 13:19:09 2015 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 03 Feb 2015 16:19:09 +0300 Subject: RFR(S): 8071811 gc/arguments/TestG1ConcRefinementThreads.java failed on Exception: java.lang.RuntimeException: Actual G1ConcRefinementThreads(0) is not equal to expected value(23) Message-ID: <54D0CACD.5080401@oracle.com> Hello All, Please review the fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8071811 Webrev: http://cr.openjdk.java.net/~eistepan/~skovalev/8071811/webrev.00/ Synopsis: Test failed on embedded Root cause: G1 GC is not supported on embedded. But G1 related tests were launched. Solution: Add test name to appropriate group: *needs_g1gc*. embedded group have below definition: embedded_jdk = :jdk \ -:not_embedded and not_embedded = :needs_g1gc \ :needs_debug Therefore if we add the test in G1GC group they automatically will be excluded from embedded execution. -- With best regards, Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Feb 3 14:45:08 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 03 Feb 2015 15:45:08 +0100 Subject: RFR: 8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure In-Reply-To: <1422956139.3368.2.camel@oracle.com> References: <54CA1FCB.4050403@oracle.com> <1422872107.3346.5.camel@oracle.com> <54CF7B79.2090506@oracle.com> <1422956139.3368.2.camel@oracle.com> Message-ID: <54D0DEF4.6090603@oracle.com> On 2015-02-03 10:35, Thomas Schatzl wrote: > Hi Stefan, > > On Mon, 2015-02-02 at 14:28 +0100, Stefan Johansson wrote: >> Hi Thomas, >> >> On 2015-02-02 11:15, Thomas Schatzl wrote: >>> Hi all, >>> >>> On Thu, 2015-01-29 at 12:55 +0100, Stefan Johansson wrote: >>>> Hi, >>>> >>>> Please review this fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8069034 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8069034/hotspot.00/ >>>> >>>> Summary: >>>> While looking for humongous objects to reclaim we unconditionally >>>> dirtied cards, some of those might belong to freed regions and if so the >>>> card table verification will fail. The simple fix is to avoid this by >>>> checking that the card belong to live regions before dirtying. A more >>>> robust fix would be to have the iterator avoid returning invalid cards, >>>> but that is a bigger change and I will file an RFE for this. >>> I would prefer if the comment were more detailed in why this check is >>> required, e.g. something like "The remembered set might contain >>> references to already freed region. Filter them out to to avoid failing >>> assertions." or so. >> I changed it to: >> // The remembered set might contain references to already freed >> // regions. Filter out such entries to avoid failing card table >> // verification. > Looks good, thanks. Looks good to me too. Bengt > > Thomas > From stefan.johansson at oracle.com Tue Feb 3 14:59:05 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 03 Feb 2015 15:59:05 +0100 Subject: RFR: 8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure In-Reply-To: <54D0DEF4.6090603@oracle.com> References: <54CA1FCB.4050403@oracle.com> <1422872107.3346.5.camel@oracle.com> <54CF7B79.2090506@oracle.com> <1422956139.3368.2.camel@oracle.com> <54D0DEF4.6090603@oracle.com> Message-ID: <54D0E239.8020903@oracle.com> Thanks Thomas and Bengt for the reviews, Stefan On 2015-02-03 15:45, Bengt Rutisson wrote: > > On 2015-02-03 10:35, Thomas Schatzl wrote: >> Hi Stefan, >> >> On Mon, 2015-02-02 at 14:28 +0100, Stefan Johansson wrote: >>> Hi Thomas, >>> >>> On 2015-02-02 11:15, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> On Thu, 2015-01-29 at 12:55 +0100, Stefan Johansson wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8069034 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sjohanss/8069034/hotspot.00/ >>>>> >>>>> Summary: >>>>> While looking for humongous objects to reclaim we unconditionally >>>>> dirtied cards, some of those might belong to freed regions and if >>>>> so the >>>>> card table verification will fail. The simple fix is to avoid this by >>>>> checking that the card belong to live regions before dirtying. A more >>>>> robust fix would be to have the iterator avoid returning invalid >>>>> cards, >>>>> but that is a bigger change and I will file an RFE for this. >>>> I would prefer if the comment were more detailed in why this check is >>>> required, e.g. something like "The remembered set might contain >>>> references to already freed region. Filter them out to to avoid >>>> failing >>>> assertions." or so. >>> I changed it to: >>> // The remembered set might contain references to already freed >>> // regions. Filter out such entries to avoid failing card table >>> // verification. >> Looks good, thanks. > > Looks good to me too. > > Bengt > >> >> Thomas >> > From yiyeguhu at gmail.com Tue Feb 3 16:53:19 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Tue, 3 Feb 2015 08:53:19 -0800 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Message-ID: Looks good. -Tao (tamao) On Mon, Feb 2, 2015 at 7:51 AM, Yasumasa Suenaga wrote: > Hi, > > I need more reviewer. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > Thanks, > > Yasumasa > 2015/01/28 17:24 "Staffan Larsen" : > > Looks good! >> >> Thanks, >> /Staffan >> >> > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: >> > >> > Hi Staffan, Kirk, >> > >> > I agree to set "Diagnostic Command" to GCCause. >> > So I applied it to new patch. >> > >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ >> > >> > Could you review it again? >> > >> > >> > Thanks, >> > >> > Yasumasa >> > >> > >> > On 2015/01/28 5:06, Kirk Pepperdine wrote: >> >> Hi Staffan, >> >> >> >>>> >> >>>> Anyway, it?s a record in a GC log so I don?t see the value of >> GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient >> given the context. >> >>> >> >>> Let?s go with ?Diagnostic Command?, then. >> >> >> >> Thank you! >> >> >> >> Regards, >> >> Kirk >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From michail.chernov at oracle.com Tue Feb 3 17:12:51 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Tue, 03 Feb 2015 20:12:51 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54CBA45D.8090503@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> Message-ID: <54D10193.3060407@oracle.com> Hi, Can someone take a look on these changes, please? Thanks, Michail On 30.01.2015 18:33, Michail Chernov wrote: > Hi Leonid, > > Issues were fixed: > http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ > > Now all testcases are executed from the same VM. > > Thanks, > Michail > > On 28.01.2015 18:28, Leonid Mesnik wrote: >> Hi >> >> Why is it needed to start VM twice for each test. It is very >> expensive especially for low-end devices. >> >> Is it possible to have driver which starts VM several times with >> different combinations of options and check it output/exit code etc? >> Also it would be much easier to read such test. >> >> >> Leonid >> >> On 27.01.2015 18:35, Michail Chernov wrote: >>> Hi all, >>> >>> Please review the fix with new test for DisableExplicitGC VM flag. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>> >>> There is one scenario with 6 parameters combinations. >>> >>> 1,2,3 scenarios test default value for DisableExplicitGC, >>> DisableExplicitGC=true and DisableExplicitGC=false >>> 4,5,6 scenarios check how VM works when VM changes DisableExplicitGC >>> flag using WhiteBox. >>> >>> Test tries to call System.gc() and check that VM puts message to >>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>> DisableExplicitGC value and calls System.gc() twice. >>> >>> Test was executed locally on linux-i586 with all available GC and >>> several GC-related flags. Also it was executed using Aurora on other >>> platforms. >>> >>> Thanks, >>> Michail >> >> >> > > > From jesper.wilhelmsson at oracle.com Tue Feb 3 17:44:47 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 03 Feb 2015 18:44:47 +0100 Subject: RFR(S): 8071811 gc/arguments/TestG1ConcRefinementThreads.java failed on Exception: java.lang.RuntimeException: Actual G1ConcRefinementThreads(0) is not equal to expected value(23) In-Reply-To: <54D0CACD.5080401@oracle.com> References: <54D0CACD.5080401@oracle.com> Message-ID: <54D1090F.3010507@oracle.com> Looks good! /Jesper Sergei Kovalev skrev den 3/2/15 14:19: > Hello All, > > Please review the fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071811 > Webrev: http://cr.openjdk.java.net/~eistepan/~skovalev/8071811/webrev.00/ > > Synopsis: Test failed on embedded > Root cause: G1 GC is not supported on embedded. But G1 related tests were launched. > > Solution: > Add test name to appropriate group: *needs_g1gc*. > > embedded group have below definition: > > embedded_jdk = > :jdk \ > -:not_embedded > > and > > not_embedded = :needs_g1gc \ > :needs_debug > > Therefore if we add the test in G1GC group they automatically will be excluded > from embedded execution. > > -- > With best regards, > Sergei > From jon.masamitsu at oracle.com Tue Feb 3 18:32:18 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 03 Feb 2015 10:32:18 -0800 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1422959222.3368.4.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> Message-ID: <54D11432.5050006@oracle.com> On 02/03/2015 02:27 AM, Thomas Schatzl wrote: > Hi Jon, > > thanks for the comments. I incorporated all of them in the latest > webrev at > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1/ (full) > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.0_to_1/ (diff) Looks good. > > There is also a small change to the WhiteBox class that I originally > forgot to ask reviews for because it is tracked in the root directory: > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.hs-gc.1/ Also looks good. > > One comment further down. > > On Fri, 2015-01-30 at 14:55 -0800, Jon Masamitsu wrote: >> Thomas, >> >> http://cr.openjdk.java.net/~tschatzl/8058354/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html >> >> Please verify that this should be a call to the _unaligned version. >> >>> 1840 size_t const commit_size = os::page_size_for_region_unaligned(size, 1); > Yes. It ensures that as soon as the given size is larger than a large > page, try to use large pages (if they are enabled). > > This is the same behavior as in 9b28. > > If we used os::page_size_for_region_aligned(), we would only try to use > large pages in case the given size is exactly a multiple of large page > size. Thanks for checking. Reviewed. Jon > > Thanks, > Thomas > > From jesper.wilhelmsson at oracle.com Tue Feb 3 21:37:53 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 03 Feb 2015 22:37:53 +0100 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54CF0267.4080308@oracle.com> References: <54CF0267.4080308@oracle.com> Message-ID: <54D13FB1.4000700@oracle.com> Looks good! /Jesper David Holmes skrev den 2/2/15 05:51: > http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ > > Original bug is confidential but the backport issue is not: > > https://bugs.openjdk.java.net/browse/JDK-8072057 > > Simple fix to ensure header inclusion is guarded based on all GCs being included. > > This fix is not applicable to 9 due to the changes there that have removed the > parNew and defNew support. In fact inclusion of this header is no longer needed > in 9 and I've filed > > https://bugs.openjdk.java.net/browse/JDK-8072056 > > to clean that up. > > Thanks, > David From bllhastings at gmail.com Tue Feb 3 23:20:02 2015 From: bllhastings at gmail.com (Bill Hastings) Date: Tue, 3 Feb 2015 15:20:02 -0800 Subject: JNI Weak Reference Message-ID: Periodically get this in my CMS GC log: 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: 17917.113: [PhantomReference, 0 refs, 0.0008860 secs]2015-02-03T03:24:27.486-0800: 17917.114: [*JNI Weak Reference, 6.1104040 secs], 6.1148360 secs*]2015-02-03T03:24:33.596-0800: 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 sys=0.00, real=6.18 secs] JNI Weak References processing take several seconds. How do I remedy this? I use JNA but I do not use any WeakReference classes in my application. Regards Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Tue Feb 3 23:30:19 2015 From: derek.white at oracle.com (Derek White) Date: Tue, 03 Feb 2015 18:30:19 -0500 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> Message-ID: <54D15A0B.6030501@oracle.com> Request for review (again): - Updated with Kim's suggestion. - Stopped double-printing warnings in some cases. - Initial caps on warning() messages. Webrev: http://cr.openjdk.java.net/~drwhite/8066821/webrev.04/ CR: https://bugs.openjdk.java.net/browse/JDK-8066821 Tests: jtreg, jprt Thanks for looking! - Derek On 1/28/15 3:47 PM, Kim Barrett wrote: > On Jan 15, 2015, at 6:34 PM, Derek White wrote: >> Hi All, >> >> I need another review, especially someone from runtime. Coleen, do you want crack at it or can you forward as needed? >> >> Another version for review: >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.01 > I noticed a bunch of formatting changes that were in the previous > webrev have been eliminated in the .01 webrev. Since I was going to > comment or complain about at least some of them, I have no objection > to having them backed out. > > This is not a complete review; I've only gotten part way through the > first file! Unfortunately, I'm swamped with other things right now > and don't seem to be making progress toward finishing. So here's what > I've got so far. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 132 int len = (int)strlen(name); > > Pre-existing issue. > > Why is this using int and casting to int, rather than just using > size_t? The return type for strlen is size_t, as is the argument for > strncmp where len is used, and the other use of len also can/should be > size_t. > > [I only noticed this because an earlier webrev tweaked the formatting > of this line.] > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 235 const char* spec_vendor = "Sun Microsystems Inc."; > 236 uint32_t spec_version = 0; > > Dead initializers; the variables are immediately reassigned new > values. > > This is a pre-existing defect that I wouldn't have even noticed had > the enum for bufsz not been reformatted in a previous webrev. (How's > that for a lesson in being lazy. :-) > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 253 * -XX arguments are usually defined in globals.hpp, globals_.hpp, globals_.hpp, _globals.hpp, or _globals.hpp. > > Rather than "are usually defined in" I think better would be something > like "are defined several places, such as". > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 251 * -XX argument processing: > > While the Hotspot style guidelines explicitly don't specify a line > length limit, I find lines that are long enough that they don't fit in > one side of a side-by-side webrev on a reasonable-sized landscape > monitor with a font size I can read without having to scroll the frame > back and forth to be pretty annoying. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 419 if (((strncmp(flag_status.name, s, len) == 0) && > 420 (strlen(s) == len)) || > 421 ((s[0] == '+' || s[0] == '-') && > 422 (strncmp(flag_status.name, &s[1], len) == 0) && > 423 (strlen(&s[1]) == len))) { > > Pre-existing issue. > > The calls to strlen and comparisons to len on lines 420 and 423 could > be replaced with > > 420: s[len] == '\0' > > 423: s[len+1] == '\0' > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 449 size_t len = strlen(flag_status.alias_name); > 450 if (((strncmp(flag_status.alias_name, flag_name, len) == 0) && > 451 (strlen(flag_name) == len))) { > > There is no point to using strlen() and strncmp() here. Just use > strcmp(), e.g. > > if (strcmp(flag_status.alias_name, flag_name) == 0) { > > http://stackoverflow.com/questions/14885000/does-strlen-in-a-strncmp-expression-defeat-the-purpose-of-using-strncmp-ov > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 412 int i = 0; > 413 assert(version != NULL, "Must provide a version buffer"); > 414 while (special_table[i].name != NULL) { > ... > 432 i++; > > Pre-existing issue. > > More readable would be to use a for-loop, e.g. > > for (size_t i = 0; special_table[i].name != NULL; ++i) { > ... > } > > size_t is a better type for i too. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 446 int i = 0; > 447 while (aliased_jvm_flags[i].alias_name != NULL) { > ... > 454 i++; > > As above, a for-loop would be more readable. > > ------------------------------------------------------------------------------ > From charlie.hunt at oracle.com Wed Feb 4 00:09:24 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Tue, 03 Feb 2015 18:09:24 -0600 Subject: JNI Weak Reference In-Reply-To: References: Message-ID: <54D16334.90503@oracle.com> An HTML attachment was scrubbed... URL: From bllhastings at gmail.com Wed Feb 4 00:19:28 2015 From: bllhastings at gmail.com (Bill Hastings) Date: Tue, 3 Feb 2015 16:19:28 -0800 Subject: JNI Weak Reference In-Reply-To: <54D16334.90503@oracle.com> References: <54D16334.90503@oracle.com> Message-ID: Yes -XX:+ParallelRefProcEnabled is enabled. Thanks Bill. On Tue, Feb 3, 2015 at 4:09 PM, charlie hunt wrote: > You might try enabling -XX:+ParallelRefProcEnabled. > > This will enable multi-threaded reference processing. > > User CPU time vs real time coupled with the JNI Weak Reference time > suggests single threaded reference processing. > > hths, > > charlie > > > On 02/03/2015 05:20 PM, Bill Hastings wrote: > > Periodically get this in my CMS GC log: > > 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 > secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs > processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, > 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 > refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: > [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: > 17917.113: [PhantomReference, 0 refs, 0.0008860 > secs]2015-02-03T03:24:27.486-0800: 17917.114: [*JNI Weak Reference, > 6.1104040 secs], 6.1148360 secs*]2015-02-03T03:24:33.596-0800: 17923.225: > [scrub string table, 0.0006670 secs] [1 CMS-remark: 531682K(5242880K)] > 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 sys=0.00, real=6.18 > secs] > > JNI Weak References processing take several seconds. How do I remedy > this? I use JNA but I do not use any WeakReference classes in my > application. > > Regards > Bill > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Wed Feb 4 01:03:26 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 3 Feb 2015 17:03:26 -0800 Subject: JNI Weak Reference In-Reply-To: References: <54D16334.90503@oracle.com> Message-ID: <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> Yes, unfortunately, I don't think Jni refs procsing is parallelized, but should be. Please file a bug... --- Ramki ysr1729 > On Feb 3, 2015, at 16:19, Bill Hastings wrote: > > Yes -XX:+ParallelRefProcEnabled is enabled. > > Thanks > Bill. > >> On Tue, Feb 3, 2015 at 4:09 PM, charlie hunt wrote: >> You might try enabling -XX:+ParallelRefProcEnabled. >> >> This will enable multi-threaded reference processing. >> >> User CPU time vs real time coupled with the JNI Weak Reference time suggests single threaded reference processing. >> >> hths, >> >> charlie >> >> >>> On 02/03/2015 05:20 PM, Bill Hastings wrote: >>> Periodically get this in my CMS GC log: >>> >>> 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: 17917.113: [PhantomReference, 0 refs, 0.0008860 secs]2015-02-03T03:24:27.486-0800: 17917.114: [JNI Weak Reference, 6.1104040 secs], 6.1148360 secs]2015-02-03T03:24:33.596-0800: 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 sys=0.00, real=6.18 secs] >>> >>> JNI Weak References processing take several seconds. How do I remedy this? I use JNA but I do not use any WeakReference classes in my application. >>> >>> Regards >>> Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 4 01:31:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 11:31:31 +1000 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54D13FB1.4000700@oracle.com> References: <54CF0267.4080308@oracle.com> <54D13FB1.4000700@oracle.com> Message-ID: <54D17673.3020006@oracle.com> Thanks Jesper! Do I need a second GC reviewer for this? David On 4/02/2015 7:37 AM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > David Holmes skrev den 2/2/15 05:51: >> http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ >> >> Original bug is confidential but the backport issue is not: >> >> https://bugs.openjdk.java.net/browse/JDK-8072057 >> >> Simple fix to ensure header inclusion is guarded based on all GCs >> being included. >> >> This fix is not applicable to 9 due to the changes there that have >> removed the >> parNew and defNew support. In fact inclusion of this header is no >> longer needed >> in 9 and I've filed >> >> https://bugs.openjdk.java.net/browse/JDK-8072056 >> >> to clean that up. >> >> Thanks, >> David From jesper.wilhelmsson at oracle.com Wed Feb 4 01:44:15 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 04 Feb 2015 02:44:15 +0100 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54D17673.3020006@oracle.com> References: <54CF0267.4080308@oracle.com> <54D13FB1.4000700@oracle.com> <54D17673.3020006@oracle.com> Message-ID: <54D1796F.9090902@oracle.com> Unfortunately yes. We haven't decided to allow small changes to go in with only one reviewer yet. Also, I'm only committer so you need someone more experienced than me to study this change ;) /Jesper David Holmes skrev den 4/2/15 02:31: > Thanks Jesper! Do I need a second GC reviewer for this? > > David > > On 4/02/2015 7:37 AM, Jesper Wilhelmsson wrote: >> Looks good! >> /Jesper >> >> David Holmes skrev den 2/2/15 05:51: >>> http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ >>> >>> Original bug is confidential but the backport issue is not: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8072057 >>> >>> Simple fix to ensure header inclusion is guarded based on all GCs >>> being included. >>> >>> This fix is not applicable to 9 due to the changes there that have >>> removed the >>> parNew and defNew support. In fact inclusion of this header is no >>> longer needed >>> in 9 and I've filed >>> >>> https://bugs.openjdk.java.net/browse/JDK-8072056 >>> >>> to clean that up. >>> >>> Thanks, >>> David From david.holmes at oracle.com Wed Feb 4 08:15:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 18:15:28 +1000 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54D1796F.9090902@oracle.com> References: <54CF0267.4080308@oracle.com> <54D13FB1.4000700@oracle.com> <54D17673.3020006@oracle.com> <54D1796F.9090902@oracle.com> Message-ID: <54D1D520.9020108@oracle.com> On 4/02/2015 11:44 AM, Jesper Wilhelmsson wrote: > Unfortunately yes. We haven't decided to allow small changes to go in > with only one reviewer yet. Also, I'm only committer so you need someone > more experienced than me to study this change ;) Yes although we have already applied to this to a non-OpenJDK repo this still needs a Reviewer for 8u. Can someone from GC please Review. Thanks, David > /Jesper > > David Holmes skrev den 4/2/15 02:31: >> Thanks Jesper! Do I need a second GC reviewer for this? >> >> David >> >> On 4/02/2015 7:37 AM, Jesper Wilhelmsson wrote: >>> Looks good! >>> /Jesper >>> >>> David Holmes skrev den 2/2/15 05:51: >>>> http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ >>>> >>>> Original bug is confidential but the backport issue is not: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8072057 >>>> >>>> Simple fix to ensure header inclusion is guarded based on all GCs >>>> being included. >>>> >>>> This fix is not applicable to 9 due to the changes there that have >>>> removed the >>>> parNew and defNew support. In fact inclusion of this header is no >>>> longer needed >>>> in 9 and I've filed >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8072056 >>>> >>>> to clean that up. >>>> >>>> Thanks, >>>> David From thomas.schatzl at oracle.com Wed Feb 4 09:10:04 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 04 Feb 2015 10:10:04 +0100 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54D1D520.9020108@oracle.com> References: <54CF0267.4080308@oracle.com> <54D13FB1.4000700@oracle.com> <54D17673.3020006@oracle.com> <54D1796F.9090902@oracle.com> <54D1D520.9020108@oracle.com> Message-ID: <1423041004.3354.2.camel@oracle.com> Hi, On Wed, 2015-02-04 at 18:15 +1000, David Holmes wrote: > On 4/02/2015 11:44 AM, Jesper Wilhelmsson wrote: > > Unfortunately yes. We haven't decided to allow small changes to go in > > with only one reviewer yet. Also, I'm only committer so you need someone > > more experienced than me to study this change ;) > > Yes although we have already applied to this to a non-OpenJDK repo this > still needs a Reviewer for 8u. Can someone from GC please Review. looks good. I am a "R"eviewer. Thanks, Thomas From stefan.karlsson at oracle.com Wed Feb 4 09:12:56 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 04 Feb 2015 10:12:56 +0100 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54CF0267.4080308@oracle.com> References: <54CF0267.4080308@oracle.com> Message-ID: <54D1E298.9090800@oracle.com> Hi David, On 2015-02-02 05:51, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ Looks fine. Some bikeshedding: we usually don't add newlines between the sections in the include list: 35 #include "utilities/macros.hpp" 36 37 #if INCLUDE_ALL_GCS 38 #include "gc_implementation/shared/parGCAllocBuffer.hpp" 39 #endif so I'd prefer if you removed lined 36. Thanks, StefanK > > Original bug is confidential but the backport issue is not: > > https://bugs.openjdk.java.net/browse/JDK-8072057 > > Simple fix to ensure header inclusion is guarded based on all GCs > being included. > > This fix is not applicable to 9 due to the changes there that have > removed the parNew and defNew support. In fact inclusion of this > header is no longer needed in 9 and I've filed > > https://bugs.openjdk.java.net/browse/JDK-8072056 > > to clean that up. > > Thanks, > David From david.holmes at oracle.com Wed Feb 4 09:27:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 19:27:23 +1000 Subject: [8u60] (XS) RFR: 8071972: Minimal VM is broken In-Reply-To: <54D1E298.9090800@oracle.com> References: <54CF0267.4080308@oracle.com> <54D1E298.9090800@oracle.com> Message-ID: <54D1E5FB.7020507@oracle.com> Hi Stefan, On 4/02/2015 7:12 PM, Stefan Karlsson wrote: > Hi David, > > On 2015-02-02 05:51, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/8071972/webrev.8u60/ > > Looks fine. > > Some bikeshedding: we usually don't add newlines between the sections in > the include list: > > 35 #include "utilities/macros.hpp" > 36 > 37 #if INCLUDE_ALL_GCS > 38 #include "gc_implementation/shared/parGCAllocBuffer.hpp" > 39 #endif > > so I'd prefer if you removed lined 36. Fixed. Thanks for the Reviews. David > Thanks, > StefanK > >> >> Original bug is confidential but the backport issue is not: >> >> https://bugs.openjdk.java.net/browse/JDK-8072057 >> >> Simple fix to ensure header inclusion is guarded based on all GCs >> being included. >> >> This fix is not applicable to 9 due to the changes there that have >> removed the parNew and defNew support. In fact inclusion of this >> header is no longer needed in 9 and I've filed >> >> https://bugs.openjdk.java.net/browse/JDK-8072056 >> >> to clean that up. >> >> Thanks, >> David > From igor.ignatyev at oracle.com Wed Feb 4 11:52:31 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 04 Feb 2015 14:52:31 +0300 Subject: RFR(S): 8071811 gc/arguments/TestG1ConcRefinementThreads.java failed on Exception: java.lang.RuntimeException: Actual G1ConcRefinementThreads(0) is not equal to expected value(23) In-Reply-To: <54D1090F.3010507@oracle.com> References: <54D0CACD.5080401@oracle.com> <54D1090F.3010507@oracle.com> Message-ID: <54D207FF.2000205@oracle.com> Hi Sergei, Looks good to me too. Thanks, Igor On 02/03/2015 08:44 PM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Sergei Kovalev skrev den 3/2/15 14:19: >> Hello All, >> >> Please review the fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8071811 >> Webrev: http://cr.openjdk.java.net/~eistepan/~skovalev/8071811/webrev.00/ >> >> Synopsis: Test failed on embedded >> Root cause: G1 GC is not supported on embedded. But G1 related tests >> were launched. >> >> Solution: >> Add test name to appropriate group: *needs_g1gc*. >> >> embedded group have below definition: >> >> embedded_jdk = >> :jdk \ >> -:not_embedded >> >> and >> >> not_embedded = :needs_g1gc \ >> :needs_debug >> >> Therefore if we add the test in G1GC group they automatically will be >> excluded >> from embedded execution. >> >> -- >> With best regards, >> Sergei >> From sergei.kovalev at oracle.com Wed Feb 4 12:55:12 2015 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 04 Feb 2015 14:55:12 +0200 Subject: RFR(S): 8071811 gc/arguments/TestG1ConcRefinementThreads.java failed on Exception: java.lang.RuntimeException: Actual G1ConcRefinementThreads(0) is not equal to expected value(23) In-Reply-To: <54D207FF.2000205@oracle.com> References: <54D0CACD.5080401@oracle.com> <54D1090F.3010507@oracle.com> <54D207FF.2000205@oracle.com> Message-ID: <54D216B0.30503@oracle.com> Thank you On 04.02.15 13:52, Igor Ignatyev wrote: > Hi Sergei, > > Looks good to me too. > > Thanks, > Igor > > On 02/03/2015 08:44 PM, Jesper Wilhelmsson wrote: >> Looks good! >> /Jesper >> >> Sergei Kovalev skrev den 3/2/15 14:19: >>> Hello All, >>> >>> Please review the fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071811 >>> Webrev: >>> http://cr.openjdk.java.net/~eistepan/~skovalev/8071811/webrev.00/ >>> >>> Synopsis: Test failed on embedded >>> Root cause: G1 GC is not supported on embedded. But G1 related tests >>> were launched. >>> >>> Solution: >>> Add test name to appropriate group: *needs_g1gc*. >>> >>> embedded group have below definition: >>> >>> embedded_jdk = >>> :jdk \ >>> -:not_embedded >>> >>> and >>> >>> not_embedded = :needs_g1gc \ >>> :needs_debug >>> >>> Therefore if we add the test in G1GC group they automatically will be >>> excluded >>> from embedded execution. >>> >>> -- >>> With best regards, >>> Sergei >>> > > -- With best regards, Sergei From marcus.larsson at oracle.com Wed Feb 4 15:30:17 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 04 Feb 2015 16:30:17 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54858DEC.5080604@oracle.com> References: <54858DEC.5080604@oracle.com> Message-ID: <54D23B09.9060006@oracle.com> Hello again, Still looking for reviews for this old forgotten change. Thanks, Marcus On 08/12/14 12:39, Marcus Larsson wrote: > Hi, > > I would like reviews for the following patch, cleaning up and > refactoring VM GC operations for failed allocations. > > Summary: > Different GCs have specialized VM_GC_Operations for collecting due to > allocation failure. Part of this code is duplicated. The patch adds a > VM_CollectForAllocation class that removes this duplicated code and > handles the allocation size and result for such operations. It also > serves as a common base where tracing can easily be added for these > operations, regardless of which GC is used. > > In addition to the above refactoring, the patch also cleans up around > the VM GC operations. These changes include: > * Indentation and whitespace fixes > * Change 'unsigned int' to 'uint' > * Change some ints to uint, where it makes more sense > (gclocker_stalled_count for example) > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8066771 > > Testing: > jprt, local jtreg (test/gc) > > Thanks, > Marcus From alexander.harlap at oracle.com Wed Feb 4 18:46:11 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Wed, 04 Feb 2015 13:46:11 -0500 Subject: Need a sponsor for push into jdk9/hs-gc Message-ID: <54D268F3.10602@oracle.com> I need a sponsor to push fix for JDK-806746 Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # HG changeset patch # User aharlap # Date 1423074128 18000 # Node ID de01bdc06cffb5f4f39ca73284c22c296522364d # Parent 2e0533911320a3ad32b266a4d513c097c7d75deb 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java failed on embedded platform Reviewed-by: dholmes, aharlap diff -r 2e0533911320 -r de01bdc06cff share/vm/runtime/arguments_ext.hpp --- a/share/vm/runtime/arguments_ext.hpp Tue Jan 27 22:06:44 2015 +0100 +++ b/share/vm/runtime/arguments_ext.hpp Wed Feb 04 13:22:08 2015 -0500 @@ -20,6 +20,7 @@ // no additional parsing needed in Arguments::parse() open code // for the option. Otherwise returns false. static inline bool process_options(const JavaVMOption *option); + static inline void report_unsupported_options(); private: static void report_error(const char * msg); @@ -51,6 +52,19 @@ return true; } +void ArgumentsExt::report_unsupported_options() { +#if INCLUDE_ALL_GCS + #if (defined JAVASE_EMBEDDED || defined ARM) + // Resource Management needs G1 GC which is not available in this case + UNSUPPORTED_OPTION(ResourceManagement, "Resource Management"); + #endif // (defined JAVASE_EMBEDDED || defined ARM) +#else + // Resource Management needs G1 GC which is not available in this case + UNSUPPORTED_OPTION(ResourceManagement, "Resource Management"); +#endif // INCLUDE_ALL_GCS +} + + bool ArgumentsExt::check_gc_consistency_ergo() { return Arguments::check_gc_consistency_ergo() && check_resource_management(); } -------------- next part -------------- # HG changeset patch # User aharlap # Date 1423073667 18000 # Node ID eca97ddf09401f2fdd3bb0ba4ca9ccd7947e47da # Parent 0f8fc58bc5a2bea4bedd4ed35aaff7018a1d33a5 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java failed on embedded platform Reviewed-by: dholmes, bdelsart diff -r 0f8fc58bc5a2 -r eca97ddf0940 src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Mon Jan 26 17:00:39 2015 -0800 +++ b/src/share/vm/runtime/arguments.cpp Wed Feb 04 13:14:27 2015 -0500 @@ -57,18 +57,6 @@ #define DEFAULT_VENDOR_URL_BUG "http://bugreport.java.com/bugreport/crash.jsp" #define DEFAULT_JAVA_LAUNCHER "generic" -// Disable options not supported in this release, with a warning if they -// were explicitly requested on the command-line -#define UNSUPPORTED_OPTION(opt, description) \ -do { \ - if (opt) { \ - if (FLAG_IS_CMDLINE(opt)) { \ - warning(description " is disabled in this release."); \ - } \ - FLAG_SET_DEFAULT(opt, false); \ - } \ -} while(0) - #define UNSUPPORTED_GC_OPTION(gc) \ do { \ if (gc) { \ @@ -3851,6 +3839,8 @@ #endif #endif + ArgumentsExt::report_unsupported_options(); + #ifndef PRODUCT if (TraceBytecodesAt != 0) { TraceBytecodes = true; diff -r 0f8fc58bc5a2 -r eca97ddf0940 src/share/vm/runtime/arguments.hpp --- a/src/share/vm/runtime/arguments.hpp Mon Jan 26 17:00:39 2015 -0800 +++ b/src/share/vm/runtime/arguments.hpp Wed Feb 04 13:14:27 2015 -0500 @@ -632,4 +632,16 @@ return check_gc_consistency_user(); } +// Disable options not supported in this release, with a warning if they +// were explicitly requested on the command-line +#define UNSUPPORTED_OPTION(opt, description) \ +do { \ + if (opt) { \ + if (FLAG_IS_CMDLINE(opt)) { \ + warning(description " is disabled in this release."); \ + } \ + FLAG_SET_DEFAULT(opt, false); \ + } \ +} while(0) + #endif // SHARE_VM_RUNTIME_ARGUMENTS_HPP diff -r 0f8fc58bc5a2 -r eca97ddf0940 src/share/vm/runtime/arguments_ext.hpp --- a/src/share/vm/runtime/arguments_ext.hpp Mon Jan 26 17:00:39 2015 -0800 +++ b/src/share/vm/runtime/arguments_ext.hpp Wed Feb 04 13:14:27 2015 -0500 @@ -37,6 +37,7 @@ // no additional parsing needed in Arguments::parse() for the option. // Otherwise returns false. static inline bool process_options(const JavaVMOption *option) { return false; } + static inline void report_unsupported_options() { } }; void ArgumentsExt::select_gc_ergonomically() { From jesper.wilhelmsson at oracle.com Wed Feb 4 19:56:32 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 4 Feb 2015 20:56:32 +0100 Subject: Need a sponsor for push into jdk9/hs-gc In-Reply-To: <54D268F3.10602@oracle.com> References: <54D268F3.10602@oracle.com> Message-ID: I'll push it unless someone else has already taken care of it. /Jesper > 4 feb 2015 kl. 19:46 skrev Alexander Harlap : > > I need a sponsor to push fix for JDK-806746 > > Alex > <8067460.closed.patch> > <8067460.hotspot.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlie.hunt at oracle.com Wed Feb 4 20:46:22 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Wed, 4 Feb 2015 14:46:22 -0600 Subject: JNI Weak Reference In-Reply-To: <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> References: <54D16334.90503@oracle.com> <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> Message-ID: <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> Filed as: https://bugs.openjdk.java.net/browse/JDK-8072498 charlie > On Feb 3, 2015, at 7:03 PM, Srinivas Ramakrishna wrote: > > Yes, unfortunately, I don't think Jni refs procsing is parallelized, but should be. Please file a bug... > > --- Ramki > > > ysr1729 > > On Feb 3, 2015, at 16:19, Bill Hastings > wrote: > >> Yes -XX:+ParallelRefProcEnabled is enabled. >> >> Thanks >> Bill. >> >> On Tue, Feb 3, 2015 at 4:09 PM, charlie hunt > wrote: >> You might try enabling -XX:+ParallelRefProcEnabled. >> >> This will enable multi-threaded reference processing. >> >> User CPU time vs real time coupled with the JNI Weak Reference time suggests single threaded reference processing. >> >> hths, >> >> charlie >> >> >> On 02/03/2015 05:20 PM, Bill Hastings wrote: >>> Periodically get this in my CMS GC log: >>> >>> 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: 17917.113: [PhantomReference, 0 refs, 0.0008860 secs]2015-02-03T03:24:27.486-0800: 17917.114: [JNI Weak Reference, 6.1104040 secs], 6.1148360 secs]2015-02-03T03:24:33.596-0800: 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 sys=0.00, real=6.18 secs] >>> >>> JNI Weak References processing take several seconds. How do I remedy this? I use JNA but I do not use any WeakReference classes in my application. >>> >>> Regards >>> Bill >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Feb 4 20:48:51 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 4 Feb 2015 15:48:51 -0500 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <54885DF8.9010907@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> Message-ID: Sorry for the delay; I lost track of this. On Dec 10, 2014, at 9:51 AM, Marcus Larsson wrote: > > Hi again, > > Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01-02/ src/share/vm/gc_implementation/parNew/parNewGeneration.cpp 417 const ParNewTracer* gc_tracer() const { 418 return &_gc_tracer; 419 } All present calls are in the providing class's implementation, and could just as easily be replaced with "&_gc_tracer". Returning a pointer into the implementation of an object is generally best avoided, and in this case it's unnecessary. Promoting it to a public API just adds to the burden. Other than that, looks good. Regarding the issue of using references vs pointers that came up in later discussion, I think it would be better to make that a separate conversation, and allow this change to proceed. [And I was the person who brought up the references vs pointers issue.] From jon.masamitsu at oracle.com Wed Feb 4 21:21:15 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 04 Feb 2015 13:21:15 -0800 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D23B09.9060006@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> Message-ID: <54D28D4B.8010105@oracle.com> Marcus, Many of the changes seem not to relate directly to the CR. For example the change "unsigned int -> uint" are the only changes is some files. Though that would be bearable in a code review, it makes more work for sustaining when they go hunting for a change that lead to a bug. Please consider integrating those under a different CR. Please create a CR to rename the sub-classes of VM_CollectForAllocation with synopsis "Regularize name of VM_CollectForAllocation and subclasses". Assign it to me. The changes themselves look good. Pending your decision of separating out the unrelated changes, consider it reviewed. Jon On 2/4/2015 7:30 AM, Marcus Larsson wrote: > Hello again, > > Still looking for reviews for this old forgotten change. > > Thanks, > Marcus > > On 08/12/14 12:39, Marcus Larsson wrote: >> Hi, >> >> I would like reviews for the following patch, cleaning up and >> refactoring VM GC operations for failed allocations. >> >> Summary: >> Different GCs have specialized VM_GC_Operations for collecting due to >> allocation failure. Part of this code is duplicated. The patch adds a >> VM_CollectForAllocation class that removes this duplicated code and >> handles the allocation size and result for such operations. It also >> serves as a common base where tracing can easily be added for these >> operations, regardless of which GC is used. >> >> In addition to the above refactoring, the patch also cleans up around >> the VM GC operations. These changes include: >> * Indentation and whitespace fixes >> * Change 'unsigned int' to 'uint' >> * Change some ints to uint, where it makes more sense >> (gclocker_stalled_count for example) >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8066771 >> >> Testing: >> jprt, local jtreg (test/gc) >> >> Thanks, >> Marcus > From bllhastings at gmail.com Wed Feb 4 23:51:23 2015 From: bllhastings at gmail.com (Bill Hastings) Date: Wed, 4 Feb 2015 15:51:23 -0800 Subject: JNI Weak Reference In-Reply-To: <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> References: <54D16334.90503@oracle.com> <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> Message-ID: Can this be patched? Because we see this very often in our environment. Regards Avinash On Wed, Feb 4, 2015 at 12:46 PM, charlie hunt wrote: > Filed as: https://bugs.openjdk.java.net/browse/JDK-8072498 > > charlie > > On Feb 3, 2015, at 7:03 PM, Srinivas Ramakrishna > wrote: > > Yes, unfortunately, I don't think Jni refs procsing is parallelized, but > should be. Please file a bug... > > --- Ramki > > > ysr1729 > > On Feb 3, 2015, at 16:19, Bill Hastings wrote: > > Yes -XX:+ParallelRefProcEnabled is enabled. > > Thanks > Bill. > > On Tue, Feb 3, 2015 at 4:09 PM, charlie hunt > wrote: > >> You might try enabling -XX:+ParallelRefProcEnabled. >> >> This will enable multi-threaded reference processing. >> >> User CPU time vs real time coupled with the JNI Weak Reference time >> suggests single threaded reference processing. >> >> hths, >> >> charlie >> >> >> On 02/03/2015 05:20 PM, Bill Hastings wrote: >> >> Periodically get this in my CMS GC log: >> >> 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 >> secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs >> processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, >> 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 >> refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: >> [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: >> 17917.113: [PhantomReference, 0 refs, 0.0008860 >> secs]2015-02-03T03:24:27.486-0800: 17917.114: [*JNI Weak Reference, >> 6.1104040 secs], 6.1148360 secs*]2015-02-03T03:24:33.596-0800: >> 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: >> 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 >> sys=0.00, real=6.18 secs] >> >> JNI Weak References processing take several seconds. How do I remedy >> this? I use JNA but I do not use any WeakReference classes in my >> application. >> >> Regards >> Bill >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Thu Feb 5 08:20:22 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 05 Feb 2015 09:20:22 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> Message-ID: <54D327C6.7040802@oracle.com> Hi Kim, Thanks for looking at this. On 04/02/15 21:48, Kim Barrett wrote: > Sorry for the delay; I lost track of this. > > On Dec 10, 2014, at 9:51 AM, Marcus Larsson wrote: >> Hi again, >> >> Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8066566/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01-02/ > src/share/vm/gc_implementation/parNew/parNewGeneration.cpp > 417 const ParNewTracer* gc_tracer() const { > 418 return &_gc_tracer; > 419 } > > All present calls are in the providing class's implementation, and > could just as easily be replaced with "&_gc_tracer". Returning a > pointer into the implementation of an object is generally best > avoided, and in this case it's unnecessary. Promoting it to a public > API just adds to the burden. As I mentioned in the original email, this getter for the field is added although it is currently unnecessary. However, it is added in preparation for https://bugs.openjdk.java.net/browse/JDK-8066444 and will soon be required. Arguably the addition of this getter belongs to that CR, but I thought I might as well add it here while doing the refactoring. > > Other than that, looks good. > > Regarding the issue of using references vs pointers that came up in > later discussion, I think it would be better to make that a separate > conversation, and allow this change to proceed. [And I was the person > who brought up the references vs pointers issue.] > Thanks, Marcus From charlie.hunt at oracle.com Thu Feb 5 13:14:23 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 05 Feb 2015 07:14:23 -0600 Subject: JNI Weak Reference In-Reply-To: References: <54D16334.90503@oracle.com> <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> Message-ID: <54D36CAF.5010200@oracle.com> An HTML attachment was scrubbed... URL: From thomas.viessmann at oracle.com Thu Feb 5 14:44:11 2015 From: thomas.viessmann at oracle.com (Thomas Viessmann) Date: Thu, 05 Feb 2015 15:44:11 +0100 Subject: Any plans to increase G1 max region size to 64m? Message-ID: <54D381BB.2080203@oracle.com> Hi, currently maximum value is -XX:G1HeapRegionSize=32m. Are there plans to increase that number as there are applications which allocate bigger objects which then result in slow humongous allocations which in turn typically exceed the target pause time. Thanks and Regards Thomas -- Oracle THOMAS VIESSMANN | Senior Principal Technical Support Engineer - Java Phone: +498914302496 | Mobile: +491743005467 Oracle Customer Technical Support - Java ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992 Muenchen ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 Muenchen Registergericht: Amtsgericht Muenchen, HRA 95603 Gesch?ftsf?hrere: Juergen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher ------------------------------------------------------------------------ ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From marcus.larsson at oracle.com Thu Feb 5 15:49:32 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 05 Feb 2015 16:49:32 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D28D4B.8010105@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> Message-ID: <54D3910C.8040000@oracle.com> Hi Jon, On 04/02/15 22:21, Jon Masamitsu wrote: > Marcus, > > Many of the changes seem not to relate directly to the > CR. For example the change "unsigned int -> uint" are > the only changes is some files. Though that would be > bearable in a code review, it makes more work for > sustaining when they go hunting for a change that lead > to a bug. Please consider integrating those under > a different CR. > I made the cleanup changes a separate CR. Cleanup issue: https://bugs.openjdk.java.net/browse/JDK-8072621 Cleanup webrev: http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ New refactoring webrev: http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ > Please create a CR to rename the sub-classes of > VM_CollectForAllocation with synopsis "Regularize > name of VM_CollectForAllocation and subclasses". > Assign it to me. Done! > > The changes themselves look good. > > Pending your decision of separating out the unrelated > changes, consider it reviewed. > > Jon Thank you for reviewing! Marcus > > On 2/4/2015 7:30 AM, Marcus Larsson wrote: >> Hello again, >> >> Still looking for reviews for this old forgotten change. >> >> Thanks, >> Marcus >> >> On 08/12/14 12:39, Marcus Larsson wrote: >>> Hi, >>> >>> I would like reviews for the following patch, cleaning up and >>> refactoring VM GC operations for failed allocations. >>> >>> Summary: >>> Different GCs have specialized VM_GC_Operations for collecting due >>> to allocation failure. Part of this code is duplicated. The patch >>> adds a VM_CollectForAllocation class that removes this duplicated >>> code and handles the allocation size and result for such operations. >>> It also serves as a common base where tracing can easily be added >>> for these operations, regardless of which GC is used. >>> >>> In addition to the above refactoring, the patch also cleans up >>> around the VM GC operations. These changes include: >>> * Indentation and whitespace fixes >>> * Change 'unsigned int' to 'uint' >>> * Change some ints to uint, where it makes more sense >>> (gclocker_stalled_count for example) >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>> >>> Testing: >>> jprt, local jtreg (test/gc) >>> >>> Thanks, >>> Marcus >> > From michail.chernov at oracle.com Thu Feb 5 18:05:59 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 05 Feb 2015 21:05:59 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54D10193.3060407@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> Message-ID: <54D3B107.9050901@oracle.com> Hi, Still waiting for reviews! Thanks, Michail On 03.02.2015 20:12, Michail Chernov wrote: > Hi, > > Can someone take a look on these changes, please? > > Thanks, > Michail > > On 30.01.2015 18:33, Michail Chernov wrote: >> Hi Leonid, >> >> Issues were fixed: >> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >> >> Now all testcases are executed from the same VM. >> >> Thanks, >> Michail >> >> On 28.01.2015 18:28, Leonid Mesnik wrote: >>> Hi >>> >>> Why is it needed to start VM twice for each test. It is very >>> expensive especially for low-end devices. >>> >>> Is it possible to have driver which starts VM several times with >>> different combinations of options and check it output/exit code etc? >>> Also it would be much easier to read such test. >>> >>> >>> Leonid >>> >>> On 27.01.2015 18:35, Michail Chernov wrote: >>>> Hi all, >>>> >>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>> >>>> There is one scenario with 6 parameters combinations. >>>> >>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>> DisableExplicitGC=true and DisableExplicitGC=false >>>> 4,5,6 scenarios check how VM works when VM changes >>>> DisableExplicitGC flag using WhiteBox. >>>> >>>> Test tries to call System.gc() and check that VM puts message to >>>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>>> DisableExplicitGC value and calls System.gc() twice. >>>> >>>> Test was executed locally on linux-i586 with all available GC and >>>> several GC-related flags. Also it was executed using Aurora on >>>> other platforms. >>>> >>>> Thanks, >>>> Michail >>> >>> >>> >> >> >> > > > From jon.masamitsu at oracle.com Thu Feb 5 20:03:46 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 05 Feb 2015 12:03:46 -0800 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D3910C.8040000@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> <54D3910C.8040000@oracle.com> Message-ID: <54D3CCA2.2070302@oracle.com> On 02/05/2015 07:49 AM, Marcus Larsson wrote: > Hi Jon, > > On 04/02/15 22:21, Jon Masamitsu wrote: >> Marcus, >> >> Many of the changes seem not to relate directly to the >> CR. For example the change "unsigned int -> uint" are >> the only changes is some files. Though that would be >> bearable in a code review, it makes more work for >> sustaining when they go hunting for a change that lead >> to a bug. Please consider integrating those under >> a different CR. >> > > I made the cleanup changes a separate CR. > > Cleanup issue: > https://bugs.openjdk.java.net/browse/JDK-8072621 Thanks. > > Cleanup webrev: > http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ Looks good. Reviewed. > > New refactoring webrev: > http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html 305 // G1's incremental collections are not always caused by an allocation, which is indicated by word_size = 0. 306 assert(_word_size != 0 || UseG1GC, "word_size = 0 should only happen with G1"); Can the assert check that the GCCause is VM_G1IncCollectionPause (I'm guessing that's what it would be) as well as UseG1GC? And expand the message to something like err_msg("word_size is 0 and GC cause is %s", GCCause::to_string(cause)) Otherwise, looks good. Reviewed. Jon > >> Please create a CR to rename the sub-classes of >> VM_CollectForAllocation with synopsis "Regularize >> name of VM_CollectForAllocation and subclasses". >> Assign it to me. > > Done! > >> >> The changes themselves look good. >> >> Pending your decision of separating out the unrelated >> changes, consider it reviewed. >> >> Jon > > Thank you for reviewing! > Marcus > >> >> On 2/4/2015 7:30 AM, Marcus Larsson wrote: >>> Hello again, >>> >>> Still looking for reviews for this old forgotten change. >>> >>> Thanks, >>> Marcus >>> >>> On 08/12/14 12:39, Marcus Larsson wrote: >>>> Hi, >>>> >>>> I would like reviews for the following patch, cleaning up and >>>> refactoring VM GC operations for failed allocations. >>>> >>>> Summary: >>>> Different GCs have specialized VM_GC_Operations for collecting due >>>> to allocation failure. Part of this code is duplicated. The patch >>>> adds a VM_CollectForAllocation class that removes this duplicated >>>> code and handles the allocation size and result for such >>>> operations. It also serves as a common base where tracing can >>>> easily be added for these operations, regardless of which GC is used. >>>> >>>> In addition to the above refactoring, the patch also cleans up >>>> around the VM GC operations. These changes include: >>>> * Indentation and whitespace fixes >>>> * Change 'unsigned int' to 'uint' >>>> * Change some ints to uint, where it makes more sense >>>> (gclocker_stalled_count for example) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>>> >>>> Testing: >>>> jprt, local jtreg (test/gc) >>>> >>>> Thanks, >>>> Marcus >>> >> > From joseph.provino at oracle.com Thu Feb 5 23:51:58 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 05 Feb 2015 18:51:58 -0500 Subject: RFR (S):8067891 Remove vestigal G1SATBCT barrier set kind Message-ID: <54D4021E.4050500@oracle.com> Please review these changes: webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.00/ Thanks. joe From bllhastings at gmail.com Fri Feb 6 00:26:03 2015 From: bllhastings at gmail.com (Bill Hastings) Date: Thu, 5 Feb 2015 16:26:03 -0800 Subject: JNI Weak Reference In-Reply-To: <54D36CAF.5010200@oracle.com> References: <54D16334.90503@oracle.com> <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> <54D36CAF.5010200@oracle.com> Message-ID: Perhaps changing it in a JDK8 update release would be great. I have not Oracle support. On Thu, Feb 5, 2015 at 5:14 AM, charlie hunt wrote: > I don't know much about how "patching" works, or if "patching" is > something that is offered. :-( > > Perhaps someone else on this mailing list knows? > > Or, perhaps you are asking for a change to be introduced in a JDK 8 update > release? > > My first reaction was that I was assuming you have an Oracle support > contract. If that's the case, then talking to your Oracle sales rep may be > the place to start? Caveat: I also do not know much about how the support > contract or sustaining side of the house works. > > Sorry to be of little help! > > charlie > > > On 02/04/2015 05:51 PM, Bill Hastings wrote: > > Can this be patched? Because we see this very often in our environment. > > Regards > Avinash > > On Wed, Feb 4, 2015 at 12:46 PM, charlie hunt > wrote: > >> Filed as: https://bugs.openjdk.java.net/browse/JDK-8072498 >> >> charlie >> >> On Feb 3, 2015, at 7:03 PM, Srinivas Ramakrishna >> wrote: >> >> Yes, unfortunately, I don't think Jni refs procsing is parallelized, >> but should be. Please file a bug... >> >> --- Ramki >> >> >> ysr1729 >> >> On Feb 3, 2015, at 16:19, Bill Hastings wrote: >> >> Yes -XX:+ParallelRefProcEnabled is enabled. >> >> Thanks >> Bill. >> >> On Tue, Feb 3, 2015 at 4:09 PM, charlie hunt >> wrote: >> >>> You might try enabling -XX:+ParallelRefProcEnabled. >>> >>> This will enable multi-threaded reference processing. >>> >>> User CPU time vs real time coupled with the JNI Weak Reference time >>> suggests single threaded reference processing. >>> >>> hths, >>> >>> charlie >>> >>> >>> On 02/03/2015 05:20 PM, Bill Hastings wrote: >>> >>> Periodically get this in my CMS GC log: >>> >>> 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 >>> secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs >>> processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, >>> 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 >>> refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: >>> [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: >>> 17917.113: [PhantomReference, 0 refs, 0.0008860 >>> secs]2015-02-03T03:24:27.486-0800: 17917.114: [*JNI Weak Reference, >>> 6.1104040 secs], 6.1148360 secs*]2015-02-03T03:24:33.596-0800: >>> 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: >>> 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 >>> sys=0.00, real=6.18 secs] >>> >>> JNI Weak References processing take several seconds. How do I remedy >>> this? I use JNA but I do not use any WeakReference classes in my >>> application. >>> >>> Regards >>> Bill >>> >>> >>> >> >> > > -- Cheers Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Feb 6 08:05:36 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 06 Feb 2015 09:05:36 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D3910C.8040000@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> <54D3910C.8040000@oracle.com> Message-ID: <54D475D0.6060902@oracle.com> Hi Marcus, Both webrevs look good to me. Bengt On 2/5/15 4:49 PM, Marcus Larsson wrote: > Hi Jon, > > On 04/02/15 22:21, Jon Masamitsu wrote: >> Marcus, >> >> Many of the changes seem not to relate directly to the >> CR. For example the change "unsigned int -> uint" are >> the only changes is some files. Though that would be >> bearable in a code review, it makes more work for >> sustaining when they go hunting for a change that lead >> to a bug. Please consider integrating those under >> a different CR. >> > > I made the cleanup changes a separate CR. > > Cleanup issue: > https://bugs.openjdk.java.net/browse/JDK-8072621 > > Cleanup webrev: > http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ > > New refactoring webrev: > http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ > >> Please create a CR to rename the sub-classes of >> VM_CollectForAllocation with synopsis "Regularize >> name of VM_CollectForAllocation and subclasses". >> Assign it to me. > > Done! > >> >> The changes themselves look good. >> >> Pending your decision of separating out the unrelated >> changes, consider it reviewed. >> >> Jon > > Thank you for reviewing! > Marcus > >> >> On 2/4/2015 7:30 AM, Marcus Larsson wrote: >>> Hello again, >>> >>> Still looking for reviews for this old forgotten change. >>> >>> Thanks, >>> Marcus >>> >>> On 08/12/14 12:39, Marcus Larsson wrote: >>>> Hi, >>>> >>>> I would like reviews for the following patch, cleaning up and >>>> refactoring VM GC operations for failed allocations. >>>> >>>> Summary: >>>> Different GCs have specialized VM_GC_Operations for collecting due >>>> to allocation failure. Part of this code is duplicated. The patch >>>> adds a VM_CollectForAllocation class that removes this duplicated >>>> code and handles the allocation size and result for such >>>> operations. It also serves as a common base where tracing can >>>> easily be added for these operations, regardless of which GC is used. >>>> >>>> In addition to the above refactoring, the patch also cleans up >>>> around the VM GC operations. These changes include: >>>> * Indentation and whitespace fixes >>>> * Change 'unsigned int' to 'uint' >>>> * Change some ints to uint, where it makes more sense >>>> (gclocker_stalled_count for example) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>>> >>>> Testing: >>>> jprt, local jtreg (test/gc) >>>> >>>> Thanks, >>>> Marcus >>> >> > From bengt.rutisson at oracle.com Fri Feb 6 08:15:27 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 06 Feb 2015 09:15:27 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D3CCA2.2070302@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> <54D3910C.8040000@oracle.com> <54D3CCA2.2070302@oracle.com> Message-ID: <54D4781F.2070807@oracle.com> Hi Jon and Marcus, One comment inlined below... On 2/5/15 9:03 PM, Jon Masamitsu wrote: > > On 02/05/2015 07:49 AM, Marcus Larsson wrote: >> Hi Jon, >> >> On 04/02/15 22:21, Jon Masamitsu wrote: >>> Marcus, >>> >>> Many of the changes seem not to relate directly to the >>> CR. For example the change "unsigned int -> uint" are >>> the only changes is some files. Though that would be >>> bearable in a code review, it makes more work for >>> sustaining when they go hunting for a change that lead >>> to a bug. Please consider integrating those under >>> a different CR. >>> >> >> I made the cleanup changes a separate CR. >> >> Cleanup issue: >> https://bugs.openjdk.java.net/browse/JDK-8072621 > > Thanks. > >> >> Cleanup webrev: >> http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ > > Looks good. > > Reviewed. > >> >> New refactoring webrev: >> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ > http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html > > > 305 // G1's incremental collections are not always caused by an > allocation, which is indicated by word_size = 0. > 306 assert(_word_size != 0 || UseG1GC, "word_size = 0 should only > happen with G1"); > > > Can the assert check that the GCCause is VM_G1IncCollectionPause (I'm > guessing that's what it would be) as well as UseG1GC? And expand the > message to something like > > err_msg("word_size is 0 and GC cause is %s", > GCCause::to_string(cause)) Jon, is inside vmGCOperations.cpp the correct place to be verifying that G1 works properly? Maybe we should just remove this assert and instead replace it with one assert each in the constructors for VM_ParallelGCFailedAllocation and VM_G1OperationWithAllocRequest. The assert in VM_ParallelGCFailedAllocation can always check for _word_sz != 0 and the assert in VM_G1OperationWithAllocRequest can check that _word_size != 0 || GCCause is VM_G1IncCollectionPause. Thanks, Bengt > > Otherwise, looks good. > > Reviewed. > > Jon > > >> >>> Please create a CR to rename the sub-classes of >>> VM_CollectForAllocation with synopsis "Regularize >>> name of VM_CollectForAllocation and subclasses". >>> Assign it to me. >> >> Done! >> >>> >>> The changes themselves look good. >>> >>> Pending your decision of separating out the unrelated >>> changes, consider it reviewed. >>> >>> Jon >> >> Thank you for reviewing! >> Marcus >> >>> >>> On 2/4/2015 7:30 AM, Marcus Larsson wrote: >>>> Hello again, >>>> >>>> Still looking for reviews for this old forgotten change. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 08/12/14 12:39, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> I would like reviews for the following patch, cleaning up and >>>>> refactoring VM GC operations for failed allocations. >>>>> >>>>> Summary: >>>>> Different GCs have specialized VM_GC_Operations for collecting due >>>>> to allocation failure. Part of this code is duplicated. The patch >>>>> adds a VM_CollectForAllocation class that removes this duplicated >>>>> code and handles the allocation size and result for such >>>>> operations. It also serves as a common base where tracing can >>>>> easily be added for these operations, regardless of which GC is used. >>>>> >>>>> In addition to the above refactoring, the patch also cleans up >>>>> around the VM GC operations. These changes include: >>>>> * Indentation and whitespace fixes >>>>> * Change 'unsigned int' to 'uint' >>>>> * Change some ints to uint, where it makes more sense >>>>> (gclocker_stalled_count for example) >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>>>> >>>>> Testing: >>>>> jprt, local jtreg (test/gc) >>>>> >>>>> Thanks, >>>>> Marcus >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Fri Feb 6 09:21:50 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 6 Feb 2015 09:21:50 +0000 Subject: comments in globals.hpp Message-ID: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> Hi, We have this from g1CollectedHeap.cpp bool G1CollectedHeap::should_do_concurrent_full_gc(GCCause::Cause cause) { switch (cause) { case GCCause::_gc_locker: return GCLockerInvokesConcurrent; case GCCause::_java_lang_system_gc: return ExplicitGCInvokesConcurrent; case GCCause::_g1_humongous_allocation: return true; default: return false; } } and this from globals.hpp product(bool, ExplicitGCInvokesConcurrent, false, \ "A System.gc() request invokes a concurrent collection; " \ "(effective only when UseConcMarkSweepGC)?) Looks like the comment isn?t in sync with the code? Kind Regards, Kirk Pepperdine -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Fri Feb 6 13:27:48 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 06 Feb 2015 14:27:48 +0100 Subject: Any plans to increase G1 max region size to 64m? In-Reply-To: <54D381BB.2080203@oracle.com> References: <54D381BB.2080203@oracle.com> Message-ID: <1423229268.3186.13.camel@oracle.com> Hi Thomas, On Thu, 2015-02-05 at 15:44 +0100, Thomas Viessmann wrote: > Hi, > > currently maximum value is -XX:G1HeapRegionSize=32m. > Are there plans to increase that number as there are applications > which allocate bigger objects which then result in slow humongous > allocations which in turn typically exceed the target pause time. I have to disagree a little here: while humongous allocations are much slower than regular applications, any application allocating too many of them too quickly will lead to out-of-memory situations anyway. I.e. before you are concerned about the performance of humongous allocations (you are going to actually do something with them?), you will most likely first get troubles with available memory. These are my observations though, feel free to give yours. Allocations for humongous objects have no impact on pause time, except if they continuously trigger garbage collections, and then you will probably run into the previously mentioned full gcs anyway. Unless you count the time the GC takes to the allocation time. We have tried maximum increasing humongous object size on some very large heap (>=100G) applications, without good results. The main problem is, a heap region size of X results in maximum regular object size of at most X/2. This results in some or all of these issues: - generally, large objects are very slow to copy around during young gc. Just copying a 16M object (at region size 32M) takes long, and then processing up to 16M/sizeof(pointer) references is very slow. (At the moment there is no load-balancing of the copying across threads, so a lot of threads may be waiting for another thread for a long time during that; we have seen balancing issues because of that. That's an implementation issue and could be fixed of course). - copying around large objects tends to fragment the survivor and old gen space. I.e. at the moment, there is just a single current allocation region for all threads during GC. So if, due to timing, you copy such a large object, and another thread allocates only 16 bytes into that same region, there is not enough space left for another such large object, throwing away the entire remainder region. This is also an implementation issue, and will likely be improved soon, but still relevant at least for 8u40. - allocation granularity during GC (and also for the TLABs, ie. during mutator time) is a region. This may lead to waste of a lot of space at the start and end of GC because of the single allocation region rule above. - the remembered set management overhead decrease from going from 32M to 64M is of course significant (roughly halves it), but overall it does not seem that much better in the cases we tried. We have found that it is often much better to keep humongous objects humongous, and then try to reclaim at every GC. This works extremely well already, and is hopefully going to get better in the future :) [Ignoring the fact that applications could help GC a little in that respect by better initial sizing or managing of their large objects in the first place.] Given all this, to me there does not seem to be a case right now to increase this limit. You can try yourselves if it makes sense for your application if you increase HeapRegionBounds::MAX_REGION_SIZE. It seems to work (although not officially supported) as far as I am concerned. Thanks, Thomas From marcus.larsson at oracle.com Fri Feb 6 14:23:56 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 06 Feb 2015 15:23:56 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D4781F.2070807@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> <54D3910C.8040000@oracle.com> <54D3CCA2.2070302@oracle.com> <54D4781F.2070807@oracle.com> Message-ID: <54D4CE7C.1030207@oracle.com> Hi Bengt, On 06/02/15 09:15, Bengt Rutisson wrote: > > Hi Jon and Marcus, > > One comment inlined below... > > On 2/5/15 9:03 PM, Jon Masamitsu wrote: >> >> On 02/05/2015 07:49 AM, Marcus Larsson wrote: >>> Hi Jon, >>> >>> On 04/02/15 22:21, Jon Masamitsu wrote: >>>> Marcus, >>>> >>>> Many of the changes seem not to relate directly to the >>>> CR. For example the change "unsigned int -> uint" are >>>> the only changes is some files. Though that would be >>>> bearable in a code review, it makes more work for >>>> sustaining when they go hunting for a change that lead >>>> to a bug. Please consider integrating those under >>>> a different CR. >>>> >>> >>> I made the cleanup changes a separate CR. >>> >>> Cleanup issue: >>> https://bugs.openjdk.java.net/browse/JDK-8072621 >> >> Thanks. >> >>> >>> Cleanup webrev: >>> http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ >> >> Looks good. >> >> Reviewed. >> >>> >>> New refactoring webrev: >>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ >> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >> >> >> 305 // G1's incremental collections are not always caused by an >> allocation, which is indicated by word_size = 0. >> 306 assert(_word_size != 0 || UseG1GC, "word_size = 0 should only >> happen with G1"); >> >> >> Can the assert check that the GCCause is VM_G1IncCollectionPause (I'm >> guessing that's what it would be) as well as UseG1GC? And expand the >> message to something like >> >> err_msg("word_size is 0 and GC cause is %s", >> GCCause::to_string(cause)) > > Jon, is inside vmGCOperations.cpp the correct place to be verifying > that G1 works properly? Maybe we should just remove this assert and > instead replace it with one assert each in the constructors for > VM_ParallelGCFailedAllocation and VM_G1OperationWithAllocRequest. The > assert in VM_ParallelGCFailedAllocation can always check for _word_sz > != 0 and the assert in VM_G1OperationWithAllocRequest can check that > _word_size != 0 || GCCause is VM_G1IncCollectionPause. > > Thanks, > Bengt > I think that's a good idea, having that extra G1 logic in the G1 code, so I moved the assert to subclasses of VM_CollectForAllocation instead. Also found that one of the G1 operations already had a guarantee for this condition, and streamlined the assert messages for these different cases. Not sure if I should convert the guarantee in the G1 case into an assert, so I left it as a guarantee to be safe. VM_G1IncCollectionPause seems to have multiple GCCauses for when allocation size can be 0, so I don't think it's worth making an assert for, it will now be the only CollectForAllocation-op that allows size = 0 anyway. New webrev: http://cr.openjdk.java.net/~mlarsson/8066771/webrev.02/ Incremental: http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01-02/ Thanks, Marcus > > >> >> Otherwise, looks good. >> >> Reviewed. >> >> Jon >> >> >>> >>>> Please create a CR to rename the sub-classes of >>>> VM_CollectForAllocation with synopsis "Regularize >>>> name of VM_CollectForAllocation and subclasses". >>>> Assign it to me. >>> >>> Done! >>> >>>> >>>> The changes themselves look good. >>>> >>>> Pending your decision of separating out the unrelated >>>> changes, consider it reviewed. >>>> >>>> Jon >>> >>> Thank you for reviewing! >>> Marcus >>> >>>> >>>> On 2/4/2015 7:30 AM, Marcus Larsson wrote: >>>>> Hello again, >>>>> >>>>> Still looking for reviews for this old forgotten change. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 08/12/14 12:39, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> I would like reviews for the following patch, cleaning up and >>>>>> refactoring VM GC operations for failed allocations. >>>>>> >>>>>> Summary: >>>>>> Different GCs have specialized VM_GC_Operations for collecting >>>>>> due to allocation failure. Part of this code is duplicated. The >>>>>> patch adds a VM_CollectForAllocation class that removes this >>>>>> duplicated code and handles the allocation size and result for >>>>>> such operations. It also serves as a common base where tracing >>>>>> can easily be added for these operations, regardless of which GC >>>>>> is used. >>>>>> >>>>>> In addition to the above refactoring, the patch also cleans up >>>>>> around the VM GC operations. These changes include: >>>>>> * Indentation and whitespace fixes >>>>>> * Change 'unsigned int' to 'uint' >>>>>> * Change some ints to uint, where it makes more sense >>>>>> (gclocker_stalled_count for example) >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>>>>> >>>>>> Testing: >>>>>> jprt, local jtreg (test/gc) >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Fri Feb 6 14:30:02 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 06 Feb 2015 15:30:02 +0100 Subject: comments in globals.hpp In-Reply-To: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> Message-ID: <54D4CFEA.5000502@oracle.com> Hi Kirk, Thanks for reporting this! I filed a bug: https://bugs.openjdk.java.net/browse/JDK-8072688 and have a fix out for review: http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ Thanks, /Jesper Kirk Pepperdine skrev den 6/2/15 10:21: > Hi, > > We have this from g1CollectedHeap.cpp > > bool G1CollectedHeap::should_do_concurrent_full_gc(GCCause::Cause cause) { > switch (cause) { > case GCCause::_gc_locker: return GCLockerInvokesConcurrent; > case GCCause::_java_lang_system_gc: return ExplicitGCInvokesConcurrent; > case GCCause::_g1_humongous_allocation: return true; > default: return false; > } > } > > and this from globals.hpp > > product(bool, ExplicitGCInvokesConcurrent, false, \ > "A System.gc() request invokes a concurrent collection; " \ > "(effective only when UseConcMarkSweepGC)?) > > Looks like the comment isn?t in sync with the code? > > Kind Regards, > Kirk Pepperdine From michail.chernov at oracle.com Fri Feb 6 14:30:29 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Fri, 06 Feb 2015 17:30:29 +0300 Subject: RFR: 8072681: serviceability/dcmd/gc/RunGCTest.java looks for old output from System.gc() Message-ID: <54D4D005.2050303@oracle.com> Hi, Can I have reviews for next small change in one test: Issue: https://bugs.openjdk.java.net/browse/JDK-8072681 Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8072681/webrev.00/ Test searches for "Full GC (Diagnostic Command)" string instead of "Full GC (System.gc())". Added requirement for DisableExplicitGC flag. Test does not work as expected with DisableExplicitGC=true : System.gc() does not trigger a full GC. Thanks, Michail From mikael.gerdin at oracle.com Fri Feb 6 14:32:58 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 06 Feb 2015 15:32:58 +0100 Subject: RFR: 8072681: serviceability/dcmd/gc/RunGCTest.java looks for old output from System.gc() In-Reply-To: <54D4D005.2050303@oracle.com> References: <54D4D005.2050303@oracle.com> Message-ID: <54D4D09A.9060304@oracle.com> Hi Michail On 2015-02-06 15:30, Michail Chernov wrote: > Hi, > > Can I have reviews for next small change in one test: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8072681 > Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8072681/webrev.00/ Looks good to me. /Mikael > > Test searches for "Full GC (Diagnostic Command)" string instead of "Full > GC (System.gc())". > Added requirement for DisableExplicitGC flag. Test does not work as > expected with DisableExplicitGC=true : System.gc() does not trigger a > full GC. > > Thanks, > Michail From kirk.pepperdine at gmail.com Fri Feb 6 14:33:19 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 6 Feb 2015 15:33:19 +0100 Subject: comments in globals.hpp In-Reply-To: <54D4CFEA.5000502@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> Message-ID: <0A401038-E4AF-4A47-8B2F-8CD8E1340D71@gmail.com> Hi, I would have provided the obvious patch but I don?t have a contributors agreement in place? thanks! Regards, Kirk On Feb 6, 2015, at 3:30 PM, Jesper Wilhelmsson wrote: > Hi Kirk, > > Thanks for reporting this! > I filed a bug: > https://bugs.openjdk.java.net/browse/JDK-8072688 > > and have a fix out for review: > http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ > > Thanks, > /Jesper > > > Kirk Pepperdine skrev den 6/2/15 10:21: >> Hi, >> >> We have this from g1CollectedHeap.cpp >> >> bool G1CollectedHeap::should_do_concurrent_full_gc(GCCause::Cause cause) { >> switch (cause) { >> case GCCause::_gc_locker: return GCLockerInvokesConcurrent; >> case GCCause::_java_lang_system_gc: return ExplicitGCInvokesConcurrent; >> case GCCause::_g1_humongous_allocation: return true; >> default: return false; >> } >> } >> >> and this from globals.hpp >> >> product(bool, ExplicitGCInvokesConcurrent, false, \ >> "A System.gc() request invokes a concurrent collection; " \ >> "(effective only when UseConcMarkSweepGC)?) >> >> Looks like the comment isn?t in sync with the code? >> >> Kind Regards, >> Kirk Pepperdine From jesper.wilhelmsson at oracle.com Fri Feb 6 14:40:13 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 06 Feb 2015 15:40:13 +0100 Subject: RFR: 8072681: serviceability/dcmd/gc/RunGCTest.java looks for old output from System.gc() In-Reply-To: <54D4D005.2050303@oracle.com> References: <54D4D005.2050303@oracle.com> Message-ID: <54D4D24D.7020203@oracle.com> Looks good! /Jesper Michail Chernov skrev den 6/2/15 15:30: > Hi, > > Can I have reviews for next small change in one test: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8072681 > Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8072681/webrev.00/ > > Test searches for "Full GC (Diagnostic Command)" string instead of "Full GC > (System.gc())". > Added requirement for DisableExplicitGC flag. Test does not work as expected > with DisableExplicitGC=true : System.gc() does not trigger a full GC. > > Thanks, > Michail From bengt.rutisson at oracle.com Fri Feb 6 15:06:07 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 6 Feb 2015 16:06:07 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D4CE7C.1030207@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> <54D3910C.8040000@oracle.com> <54D3CCA2.2070302@oracle.com> <54D4781F.2070807@oracle.com> <54D4CE7C.1030207@oracle.com> Message-ID: <91874AD0-859B-4014-80DC-080EC896AED6@oracle.com> Hi Marcus, Latest webrev looks good to me. Thanks for fixing the asserts/guarantees. Bengt > 6 feb 2015 kl. 15:23 skrev Marcus Larsson : > > Hi Bengt, > >> On 06/02/15 09:15, Bengt Rutisson wrote: >> >> Hi Jon and Marcus, >> >> One comment inlined below... >> >>> On 2/5/15 9:03 PM, Jon Masamitsu wrote: >>> >>>> On 02/05/2015 07:49 AM, Marcus Larsson wrote: >>>> Hi Jon, >>>> >>>>> On 04/02/15 22:21, Jon Masamitsu wrote: >>>>> Marcus, >>>>> >>>>> Many of the changes seem not to relate directly to the >>>>> CR. For example the change "unsigned int -> uint" are >>>>> the only changes is some files. Though that would be >>>>> bearable in a code review, it makes more work for >>>>> sustaining when they go hunting for a change that lead >>>>> to a bug. Please consider integrating those under >>>>> a different CR. >>>> >>>> I made the cleanup changes a separate CR. >>>> >>>> Cleanup issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8072621 >>> >>> Thanks. >>> >>>> >>>> Cleanup webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ >>> >>> Looks good. >>> >>> Reviewed. >>> >>>> >>>> New refactoring webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ >>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >>> >>> 305 // G1's incremental collections are not always caused by an allocation, which is indicated by word_size = 0. >>> 306 assert(_word_size != 0 || UseG1GC, "word_size = 0 should only happen with G1"); >>> >>> >>> Can the assert check that the GCCause is VM_G1IncCollectionPause (I'm >>> guessing that's what it would be) as well as UseG1GC? And expand the >>> message to something like >>> >>> err_msg("word_size is 0 and GC cause is %s", >>> GCCause::to_string(cause)) >> >> Jon, is inside vmGCOperations.cpp the correct place to be verifying that G1 works properly? Maybe we should just remove this assert and instead replace it with one assert each in the constructors for VM_ParallelGCFailedAllocation and VM_G1OperationWithAllocRequest. The assert in VM_ParallelGCFailedAllocation can always check for _word_sz != 0 and the assert in VM_G1OperationWithAllocRequest can check that _word_size != 0 || GCCause is VM_G1IncCollectionPause. >> >> Thanks, >> Bengt > > I think that's a good idea, having that extra G1 logic in the G1 code, so I moved the assert to subclasses of VM_CollectForAllocation instead. Also found that one of the G1 operations already had a guarantee for this condition, and streamlined the assert messages for these different cases. Not sure if I should convert the guarantee in the G1 case into an assert, so I left it as a guarantee to be safe. VM_G1IncCollectionPause seems to have multiple GCCauses for when allocation size can be 0, so I don't think it's worth making an assert for, it will now be the only CollectForAllocation-op that allows size = 0 anyway. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8066771/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01-02/ > > Thanks, > Marcus > >> >> >>> >>> Otherwise, looks good. >>> >>> Reviewed. >>> >>> Jon >>> >>> >>>> >>>>> Please create a CR to rename the sub-classes of >>>>> VM_CollectForAllocation with synopsis "Regularize >>>>> name of VM_CollectForAllocation and subclasses". >>>>> Assign it to me. >>>> >>>> Done! >>>> >>>>> >>>>> The changes themselves look good. >>>>> >>>>> Pending your decision of separating out the unrelated >>>>> changes, consider it reviewed. >>>>> >>>>> Jon >>>> >>>> Thank you for reviewing! >>>> Marcus >>>> >>>>> >>>>>> On 2/4/2015 7:30 AM, Marcus Larsson wrote: >>>>>> Hello again, >>>>>> >>>>>> Still looking for reviews for this old forgotten change. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> On 08/12/14 12:39, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like reviews for the following patch, cleaning up and refactoring VM GC operations for failed allocations. >>>>>>> >>>>>>> Summary: >>>>>>> Different GCs have specialized VM_GC_Operations for collecting due to allocation failure. Part of this code is duplicated. The patch adds a VM_CollectForAllocation class that removes this duplicated code and handles the allocation size and result for such operations. It also serves as a common base where tracing can easily be added for these operations, regardless of which GC is used. >>>>>>> >>>>>>> In addition to the above refactoring, the patch also cleans up around the VM GC operations. These changes include: >>>>>>> * Indentation and whitespace fixes >>>>>>> * Change 'unsigned int' to 'uint' >>>>>>> * Change some ints to uint, where it makes more sense >>>>>>> (gclocker_stalled_count for example) >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>>>>>> >>>>>>> Testing: >>>>>>> jprt, local jtreg (test/gc) >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Fri Feb 6 15:10:31 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 06 Feb 2015 16:10:31 +0100 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() Message-ID: <54D4D967.7030205@oracle.com> Hi all, There are some problems with the Diagnostic Command GCCause change, I suggest that we back out the change and reconsider its implementation. [from the bug] The change is incomplete since several places in the GC code assumes that explicit gcs have the _java_lang_system_gc GCCause value in order to determine the behavior. For example: ParallelGC does not apply policy decisions on user-invoked GCs (decided by the GCCause) G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. This could cause problems for people expecting concurrent gcs when running the diagnostic command instead of a possibly several-second full gc pause. Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ /Mikael From jesper.wilhelmsson at oracle.com Fri Feb 6 15:22:04 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 6 Feb 2015 16:22:04 +0100 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54D4D967.7030205@oracle.com> References: <54D4D967.7030205@oracle.com> Message-ID: <9038D8C3-DCA4-42DD-8839-18BF97E39A46@oracle.com> Looks good. /Jesper > 6 feb 2015 kl. 16:10 skrev Mikael Gerdin : > > Hi all, > > There are some problems with the Diagnostic Command GCCause change, I suggest that we back out the change and reconsider its implementation. > > [from the bug] > The change is incomplete since several places in the GC code assumes that explicit gcs have the _java_lang_system_gc GCCause value in order to determine the behavior. > For example: > ParallelGC does not apply policy decisions on user-invoked GCs (decided by the GCCause) > G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. > This could cause problems for people expecting concurrent gcs when running the diagnostic command instead of a possibly several-second full gc pause. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 > Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ > > /Mikael From thomas.schatzl at oracle.com Fri Feb 6 15:23:42 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 06 Feb 2015 16:23:42 +0100 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54D4D967.7030205@oracle.com> References: <54D4D967.7030205@oracle.com> Message-ID: <1423236222.11345.1.camel@oracle.com> Hi Mikael, On Fri, 2015-02-06 at 16:10 +0100, Mikael Gerdin wrote: > Hi all, > > There are some problems with the Diagnostic Command GCCause change, I > suggest that we back out the change and reconsider its implementation. > > [from the bug] > The change is incomplete since several places in the GC code assumes > that explicit gcs have the _java_lang_system_gc GCCause value in order > to determine the behavior. > For example: > ParallelGC does not apply policy decisions on user-invoked GCs (decided > by the GCCause) > G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. > This could cause problems for people expecting concurrent gcs when > running the diagnostic command instead of a possibly several-second full > gc pause. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 > Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ looks like a clean inverse of the original change (http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/5abc906fe3a8). Ship it :) Thanks, Thomas From mikael.gerdin at oracle.com Fri Feb 6 16:00:13 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 06 Feb 2015 17:00:13 +0100 Subject: RFR: 8072681: serviceability/dcmd/gc/RunGCTest.java looks for old output from System.gc() In-Reply-To: <54D4D005.2050303@oracle.com> References: <54D4D005.2050303@oracle.com> Message-ID: <54D4E50D.3070001@oracle.com> Hi Michail, For now we decided to back out the change causing this problem. We'll revisit this test fix once the change is ready again. /Mikael On 2015-02-06 15:30, Michail Chernov wrote: > Hi, > > Can I have reviews for next small change in one test: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8072681 > Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8072681/webrev.00/ > > Test searches for "Full GC (Diagnostic Command)" string instead of "Full > GC (System.gc())". > Added requirement for DisableExplicitGC flag. Test does not work as > expected with DisableExplicitGC=true : System.gc() does not trigger a > full GC. > > Thanks, > Michail From jon.masamitsu at oracle.com Fri Feb 6 16:57:11 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 06 Feb 2015 08:57:11 -0800 Subject: RFR (S):8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <54D4021E.4050500@oracle.com> References: <54D4021E.4050500@oracle.com> Message-ID: <54D4F267.4020401@oracle.com> Changes look good. Reviewed. Jon On 2/5/2015 3:51 PM, Joseph Provino wrote: > Please review these changes: > > webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.00/ > > Thanks. > > joe From kim.barrett at oracle.com Fri Feb 6 20:38:24 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 6 Feb 2015 15:38:24 -0500 Subject: RFR (S):8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <54D4021E.4050500@oracle.com> References: <54D4021E.4050500@oracle.com> Message-ID: <74B9CE55-AE03-4529-AA24-DF290D8D8DDC@oracle.com> On Feb 5, 2015, at 6:51 PM, Joseph Provino wrote: > > Please review these changes: > > webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.00/ Not a review, but rather a "please wait" request. src/cpu/ppc/vm/macroAssembler_ppc.cpp 2313 G1SATBCardTableModRefBS* bs = (G1SATBCardTableModRefBS*) Universe::heap()->barrier_set(); 2314 assert(bs->kind() == BarrierSet::G1SATBCTLogging, "wrong barrier"); Pre-existing bug: The assertion after the cast is wrong; if the barrier set is not of the indicated type, the preceding cast has already invoked undefined behavior. There are more of these. I would *really* like to deal with https://bugs.openjdk.java.net/browse/JDK-8069016 first, before having BarrierSet::G1SATBCT addressed. I have a fix that works, but need a little time to tidy it up and then get it reviewed. I've been distracted by other things recently, but hoped to get this out for review in the next couple of days. Unfortunately, I forgot to make JDK-8069016 a blocker for JDK-8067891. From joseph.provino at oracle.com Fri Feb 6 21:45:39 2015 From: joseph.provino at oracle.com (joe provino) Date: Fri, 06 Feb 2015 16:45:39 -0500 Subject: RFR (S):8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <74B9CE55-AE03-4529-AA24-DF290D8D8DDC@oracle.com> References: <54D4021E.4050500@oracle.com> <74B9CE55-AE03-4529-AA24-DF290D8D8DDC@oracle.com> Message-ID: <54D53603.9020207@oracle.com> Okay, I'll wait and take a look at https://bugs.openjdk.java.net/browse/JDK-8069016 joe On 02/06/2015 03:38 PM, Kim Barrett wrote: > On Feb 5, 2015, at 6:51 PM, Joseph Provino wrote: >> Please review these changes: >> >> webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.00/ > Not a review, but rather a "please wait" request. > > src/cpu/ppc/vm/macroAssembler_ppc.cpp > 2313 G1SATBCardTableModRefBS* bs = (G1SATBCardTableModRefBS*) Universe::heap()->barrier_set(); > 2314 assert(bs->kind() == BarrierSet::G1SATBCTLogging, "wrong barrier"); > > Pre-existing bug: > > The assertion after the cast is wrong; if the barrier set is not of > the indicated type, the preceding cast has already invoked undefined > behavior. There are more of these. > > I would *really* like to deal with > https://bugs.openjdk.java.net/browse/JDK-8069016 first, before having > BarrierSet::G1SATBCT addressed. I have a fix that works, but need a > little time to tidy it up and then get it reviewed. I've been > distracted by other things recently, but hoped to get this out for > review in the next couple of days. > > Unfortunately, I forgot to make JDK-8069016 a blocker for JDK-8067891. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Feb 6 23:49:14 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 06 Feb 2015 15:49:14 -0800 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure In-Reply-To: <54D4781F.2070807@oracle.com> References: <54858DEC.5080604@oracle.com> <54D23B09.9060006@oracle.com> <54D28D4B.8010105@oracle.com> <54D3910C.8040000@oracle.com> <54D3CCA2.2070302@oracle.com> <54D4781F.2070807@oracle.com> Message-ID: <54D552FA.8000808@oracle.com> On 2/6/2015 12:15 AM, Bengt Rutisson wrote: > > Hi Jon and Marcus, > > One comment inlined below... > > On 2/5/15 9:03 PM, Jon Masamitsu wrote: >> >> On 02/05/2015 07:49 AM, Marcus Larsson wrote: >>> Hi Jon, >>> >>> On 04/02/15 22:21, Jon Masamitsu wrote: >>>> Marcus, >>>> >>>> Many of the changes seem not to relate directly to the >>>> CR. For example the change "unsigned int -> uint" are >>>> the only changes is some files. Though that would be >>>> bearable in a code review, it makes more work for >>>> sustaining when they go hunting for a change that lead >>>> to a bug. Please consider integrating those under >>>> a different CR. >>>> >>> >>> I made the cleanup changes a separate CR. >>> >>> Cleanup issue: >>> https://bugs.openjdk.java.net/browse/JDK-8072621 >> >> Thanks. >> >>> >>> Cleanup webrev: >>> http://cr.openjdk.java.net/~mlarsson/8072621/webrev.00/ >> >> Looks good. >> >> Reviewed. >> >>> >>> New refactoring webrev: >>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/ >> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.01/src/share/vm/gc_implementation/shared/vmGCOperations.cpp.frames.html >> >> >> 305 // G1's incremental collections are not always caused by an >> allocation, which is indicated by word_size = 0. >> 306 assert(_word_size != 0 || UseG1GC, "word_size = 0 should only >> happen with G1"); >> >> >> Can the assert check that the GCCause is VM_G1IncCollectionPause (I'm >> guessing that's what it would be) as well as UseG1GC? And expand the >> message to something like >> >> err_msg("word_size is 0 and GC cause is %s", >> GCCause::to_string(cause)) > > Jon, is inside vmGCOperations.cpp the correct place to be verifying > that G1 works properly? Maybe we should just Good point. Not the place to be checking G1. > remove this assert and instead replace it with one assert each in the > constructors for VM_ParallelGCFailedAllocation and > VM_G1OperationWithAllocRequest. The assert in > VM_ParallelGCFailedAllocation can always check for _word_sz != 0 and > the assert in VM_G1OperationWithAllocRequest can check that _word_size > != 0 || GCCause is VM_G1IncCollectionPause. I like that. Jon > > Thanks, > Bengt > > > >> >> Otherwise, looks good. >> >> Reviewed. >> >> Jon >> >> >>> >>>> Please create a CR to rename the sub-classes of >>>> VM_CollectForAllocation with synopsis "Regularize >>>> name of VM_CollectForAllocation and subclasses". >>>> Assign it to me. >>> >>> Done! >>> >>>> >>>> The changes themselves look good. >>>> >>>> Pending your decision of separating out the unrelated >>>> changes, consider it reviewed. >>>> >>>> Jon >>> >>> Thank you for reviewing! >>> Marcus >>> >>>> >>>> On 2/4/2015 7:30 AM, Marcus Larsson wrote: >>>>> Hello again, >>>>> >>>>> Still looking for reviews for this old forgotten change. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 08/12/14 12:39, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> I would like reviews for the following patch, cleaning up and >>>>>> refactoring VM GC operations for failed allocations. >>>>>> >>>>>> Summary: >>>>>> Different GCs have specialized VM_GC_Operations for collecting >>>>>> due to allocation failure. Part of this code is duplicated. The >>>>>> patch adds a VM_CollectForAllocation class that removes this >>>>>> duplicated code and handles the allocation size and result for >>>>>> such operations. It also serves as a common base where tracing >>>>>> can easily be added for these operations, regardless of which GC >>>>>> is used. >>>>>> >>>>>> In addition to the above refactoring, the patch also cleans up >>>>>> around the VM GC operations. These changes include: >>>>>> * Indentation and whitespace fixes >>>>>> * Change 'unsigned int' to 'uint' >>>>>> * Change some ints to uint, where it makes more sense >>>>>> (gclocker_stalled_count for example) >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066771 >>>>>> >>>>>> Testing: >>>>>> jprt, local jtreg (test/gc) >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Sat Feb 7 02:11:00 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 6 Feb 2015 18:11:00 -0800 Subject: JNI Weak Reference In-Reply-To: <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> References: <54D16334.90503@oracle.com> <93C65E10-9BAE-4DED-818F-3A2356D4A067@gmail.com> <16569522-5783-45A8-A50F-A26D21EA8ABB@oracle.com> Message-ID: Thanks for filing this ticket, Charlie! On Wed, Feb 4, 2015 at 12:46 PM, charlie hunt wrote: > Filed as: https://bugs.openjdk.java.net/browse/JDK-8072498 > > charlie > > On Feb 3, 2015, at 7:03 PM, Srinivas Ramakrishna > wrote: > > Yes, unfortunately, I don't think Jni refs procsing is parallelized, but > should be. Please file a bug... > > --- Ramki > > > ysr1729 > > On Feb 3, 2015, at 16:19, Bill Hastings wrote: > > Yes -XX:+ParallelRefProcEnabled is enabled. > > Thanks > Bill. > > On Tue, Feb 3, 2015 at 4:09 PM, charlie hunt > wrote: > >> You might try enabling -XX:+ParallelRefProcEnabled. >> >> This will enable multi-threaded reference processing. >> >> User CPU time vs real time coupled with the JNI Weak Reference time >> suggests single threaded reference processing. >> >> hths, >> >> charlie >> >> >> On 02/03/2015 05:20 PM, Bill Hastings wrote: >> >> Periodically get this in my CMS GC log: >> >> 2015-02-03T03:24:27.419-0800: 17917.047: [Rescan (parallel) , 0.0625400 >> secs]2015-02-03T03:24:27.482-0800: 17917.110: [weak refs >> processing2015-02-03T03:24:27.482-0800: 17917.110: [SoftReference, 1 refs, >> 0.0010820 secs]2015-02-03T03:24:27.483-0800: 17917.111: [WeakReference, 0 >> refs, 0.0015340 secs]2015-02-03T03:24:27.484-0800: 17917.112: >> [FinalReference, 0 refs, 0.0007930 secs]2015-02-03T03:24:27.485-0800: >> 17917.113: [PhantomReference, 0 refs, 0.0008860 >> secs]2015-02-03T03:24:27.486-0800: 17917.114: [*JNI Weak Reference, >> 6.1104040 secs], 6.1148360 secs*]2015-02-03T03:24:33.596-0800: >> 17923.225: [scrub string table, 0.0006670 secs] [1 CMS-remark: >> 531682K(5242880K)] 1827698K(7759488K), 6.1785190 secs] [Times: user=7.22 >> sys=0.00, real=6.18 secs] >> >> JNI Weak References processing take several seconds. How do I remedy >> this? I use JNA but I do not use any WeakReference classes in my >> application. >> >> Regards >> Bill >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.viessmann at oracle.com Mon Feb 9 11:41:00 2015 From: thomas.viessmann at oracle.com (Thomas Viessmann) Date: Mon, 09 Feb 2015 12:41:00 +0100 Subject: Any plans to increase G1 max region size to 64m? In-Reply-To: <1423229268.3186.13.camel@oracle.com> References: <54D381BB.2080203@oracle.com> <1423229268.3186.13.camel@oracle.com> Message-ID: <54D89CCC.70600@oracle.com> Hi Thomas, many thanks for your detailed explanation. Here are some more details about the background. It seems that a humongous allocation triggers a (long) evacuation pause although the eden is still (almost) empty. Such long pauses could only be observed during a humongous allocation. Is this what you meant when you said:/ / / - copying around large objects tends to fragment the survivor and old gen space. I.e. at the moment, there is just a single current allocation region for all threads during GC. So if, due to timing, you copy such a large object, and another thread allocates only 16 bytes into that same region, there is not enough space left for another such large object, throwing away the entire remainder region. This is also an implementation issue, and will likely be improved soon, but still relevant at least for 8u40./ Here is an example from the gc.log 173913.719: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 11710496768 bytes, allocation request: 33554448 bytes, threshold: 11596411665 bytes (45.00 %), source: concurrent humongous allocation] 173913.721: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: requested by GC cause, GC cause: G1 Humongous Allocation] {Heap before GC invocations=11416 (full 0): garbage-first heap total 25165824K, used 11532190K [0x00000001e0000000, 0x00000007e0000000, 0x00000007e0000000) region size 32768K, 6 young (196608K), 5 survivors (163840K) compacting perm gen total 262144K, used 72815K [0x00000007e0000000, 0x00000007f0000000, 0x0000000800000000) the space 262144K, 27% used [0x00000007e0000000, 0x00000007e471bd28, 0x00000007e471be00, 0x00000007f0000000) No shared spaces configured. 173913.721: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested] 2014-12-13T00:34:06.802-0600: 173913.721: [GC pause (G1 Humongous Allocation) (young) (initial-mark) 173913.721: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 3141273, predicted base time: 925.47 ms, remaining time: 0.00 ms, target pause time: 400.00 ms] 173913.721: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 1 regions, survivors: 5 regions, predicted young region time: 49.96 ms] 173913.721: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 1 regions, survivors: 5 regions, old: 0 regions, predicted pause time: 975.43 ms, target pause time: 400.00 ms] , 1.0386970 secs] [Parallel Time: 1019.3 ms, GC Workers: 18] [GC Worker Start (ms): Min: 173913721.2, Avg: 173913721.5, Max: 173913721.8, Diff: 0.5] [Ext Root Scanning (ms): Min: 3.8, Avg: 4.2, Max: 5.1, Diff: 1.3, Sum: 76.1] [Code Root Marking (ms): Min: 0.0, Avg: 0.6, Max: 3.9, Diff: 3.9, Sum: 11.0] [Update RS (ms): Min: 954.6, Avg: 957.4, Max: 958.0, Diff: 3.5, Sum: 17232.4] [Processed Buffers: Min: 601, Avg: 682.2, Max: 852, Diff: 251, Sum: 12279] [Scan RS (ms): Min: 1.5, Avg: 1.9, Max: 2.3, Diff: 0.7, Sum: 35.0] [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Object Copy (ms): Min: 54.0, Avg: 54.5, Max: 54.8, Diff: 0.7, Sum: 980.1] [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.3] [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 1.1] [GC Worker Total (ms): Min: 1018.4, Avg: 1018.7, Max: 1019.0, Diff: 0.5, Sum: 18336.1] [GC Worker End (ms): Min: 173914740.1, Avg: 173914740.2, Max: 173914740.2, Diff: 0.1] [Code Root Fixup: 0.1 ms] [Code Root Migration: 0.0 ms] [Clear CT: 0.4 ms] [Other: 18.9 ms] [Choose CSet: 0.0 ms] [Ref Proc: 10.7 ms] [Ref Enq: 0.4 ms] [Free CSet: 0.2 ms] [Eden: 32.0M(1056.0M)->0.0B(1056.0M) Survivors: 160.0M->160.0M Heap: 11.0G(24.0G)->11.5G(24.0G)] Heap after GC invocations=11417 (full 0): garbage-first heap total 25165824K, used 12101473K [0x00000001e0000000, 0x00000007e0000000, 0x00000007e0000000) region size 32768K, 5 young (163840K), 5 survivors (163840K) compacting perm gen total 262144K, used 72815K [0x00000007e0000000, 0x00000007f0000000, 0x0000000800000000) the space 262144K, 27% used [0x00000007e0000000, 0x00000007e471bd28, 0x00000007e471be00, 0x00000007f0000000) No shared spaces configured. } [Times: user=18.39 sys=0.01, real=1.04 secs] Thanks and Regards Thomas On 02/06/15 14:27, Thomas Schatzl wrote: > Hi Thomas, > > On Thu, 2015-02-05 at 15:44 +0100, Thomas Viessmann wrote: >> Hi, >> >> currently maximum value is -XX:G1HeapRegionSize=32m. >> Are there plans to increase that number as there are applications >> which allocate bigger objects which then result in slow humongous >> allocations which in turn typically exceed the target pause time. > I have to disagree a little here: while humongous allocations are much > slower than regular applications, any application allocating too many of > them too quickly will lead to out-of-memory situations anyway. > > I.e. before you are concerned about the performance of humongous > allocations (you are going to actually do something with them?), you > will most likely first get troubles with available memory. > > These are my observations though, feel free to give yours. > > Allocations for humongous objects have no impact on pause time, except > if they continuously trigger garbage collections, and then you will > probably run into the previously mentioned full gcs anyway. Unless you > count the time the GC takes to the allocation time. > > We have tried maximum increasing humongous object size on some very > large heap (>=100G) applications, without good results. > > The main problem is, a heap region size of X results in maximum regular > object size of at most X/2. > > This results in some or all of these issues: > > - generally, large objects are very slow to copy around during young > gc. Just copying a 16M object (at region size 32M) takes long, and then > processing up to 16M/sizeof(pointer) references is very slow. > > (At the moment there is no load-balancing of the copying across threads, > so a lot of threads may be waiting for another thread for a long time > during that; we have seen balancing issues because of that. That's an > implementation issue and could be fixed of course). > > - copying around large objects tends to fragment the survivor and old > gen space. I.e. at the moment, there is just a single current allocation > region for all threads during GC. > So if, due to timing, you copy such a large object, and another thread > allocates only 16 bytes into that same region, there is not enough space > left for another such large object, throwing away the entire remainder > region. > This is also an implementation issue, and will likely be improved soon, > but still relevant at least for 8u40. > > - allocation granularity during GC (and also for the TLABs, ie. during > mutator time) is a region. This may lead to waste of a lot of space at > the start and end of GC because of the single allocation region rule > above. > > - the remembered set management overhead decrease from going from 32M > to 64M is of course significant (roughly halves it), but overall it does > not seem that much better in the cases we tried. > > We have found that it is often much better to keep humongous objects > humongous, and then try to reclaim at every GC. This works extremely > well already, and is hopefully going to get better in the future :) > > [Ignoring the fact that applications could help GC a little in that > respect by better initial sizing or managing of their large objects in > the first place.] > > Given all this, to me there does not seem to be a case right now to > increase this limit. > > You can try yourselves if it makes sense for your application if you > increase HeapRegionBounds::MAX_REGION_SIZE. It seems to work (although > not officially supported) as far as I am concerned. > > Thanks, > Thomas > > -- Oracle THOMAS VIESSMANN | Senior Principal Technical Support Engineer - Java Phone: +498914302496 | Mobile: +491743005467 Oracle Customer Technical Support - Java ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992 Muenchen ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 Muenchen Registergericht: Amtsgericht Muenchen, HRA 95603 Gesch?ftsf?hrere: Juergen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher ------------------------------------------------------------------------ ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From thomas.schatzl at oracle.com Mon Feb 9 15:01:49 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Feb 2015 16:01:49 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <54D4CFEA.5000502@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> Message-ID: <1423494109.3104.5.camel@oracle.com> Hi Jesper, On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: > Hi Kirk, > > Thanks for reporting this! > I filed a bug: > https://bugs.openjdk.java.net/browse/JDK-8072688 > > and have a fix out for review: > http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ > looks good - not sure if the explicit mention of the two collectors is necessary. We do not do it for many other flags either. Maybe if you waited a little more if somebody else feels strongly about this. You do not need to hide the review request too :) Thanks, Thomas From mikael.gerdin at oracle.com Mon Feb 9 15:08:23 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 09 Feb 2015 16:08:23 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <1423494109.3104.5.camel@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> <1423494109.3104.5.camel@oracle.com> Message-ID: <54D8CD67.6030202@oracle.com> On 2015-02-09 16:01, Thomas Schatzl wrote: > Hi Jesper, > > On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: >> Hi Kirk, >> >> Thanks for reporting this! >> I filed a bug: >> https://bugs.openjdk.java.net/browse/JDK-8072688 >> >> and have a fix out for review: >> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ >> > > looks good - not sure if the explicit mention of the two collectors is > necessary. We do not do it for many other flags either. I agree that it would be better to not mention any specific GC: "effective only when a concurrent GC is enabled" is my suggestion. /Mikael > > Maybe if you waited a little more if somebody else feels strongly about > this. > > You do not need to hide the review request too :) > > Thanks, > Thomas > > From jesper.wilhelmsson at oracle.com Mon Feb 9 15:17:05 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 09 Feb 2015 16:17:05 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <54D8CD67.6030202@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> <1423494109.3104.5.camel@oracle.com> <54D8CD67.6030202@oracle.com> Message-ID: <54D8CF71.4050702@oracle.com> Mikael Gerdin skrev den 9/2/15 16:08: > On 2015-02-09 16:01, Thomas Schatzl wrote: >> Hi Jesper, >> >> On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: >>> Hi Kirk, >>> >>> Thanks for reporting this! >>> I filed a bug: >>> https://bugs.openjdk.java.net/browse/JDK-8072688 >>> >>> and have a fix out for review: >>> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ >>> >> >> looks good - not sure if the explicit mention of the two collectors is >> necessary. We do not do it for many other flags either. > > I agree that it would be better to not mention any specific GC: > "effective only when a concurrent GC is enabled" > is my suggestion. > Since I already changed it to "(effective only when using concurrent collectors)" and published the new webrev, that is my suggestion :) http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.01/ /Jesper > /Mikael > >> >> Maybe if you waited a little more if somebody else feels strongly about >> this. >> >> You do not need to hide the review request too :) >> >> Thanks, >> Thomas >> >> From mikael.gerdin at oracle.com Mon Feb 9 15:30:59 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 09 Feb 2015 16:30:59 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <54D8CF71.4050702@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> <1423494109.3104.5.camel@oracle.com> <54D8CD67.6030202@oracle.com> <54D8CF71.4050702@oracle.com> Message-ID: <54D8D2B3.6040903@oracle.com> On 2015-02-09 16:17, Jesper Wilhelmsson wrote: > Mikael Gerdin skrev den 9/2/15 16:08: >> On 2015-02-09 16:01, Thomas Schatzl wrote: >>> Hi Jesper, >>> >>> On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: >>>> Hi Kirk, >>>> >>>> Thanks for reporting this! >>>> I filed a bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8072688 >>>> >>>> and have a fix out for review: >>>> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ >>>> >>> >>> looks good - not sure if the explicit mention of the two >>> collectors is >>> necessary. We do not do it for many other flags either. >> >> I agree that it would be better to not mention any specific GC: >> "effective only when a concurrent GC is enabled" >> is my suggestion. >> > > Since I already changed it to "(effective only when using concurrent > collectors)" and published the new webrev, that is my suggestion :) > > http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.01/ That's fine with me. /Mikael > > /Jesper > >> /Mikael >> >>> >>> Maybe if you waited a little more if somebody else feels strongly about >>> this. >>> >>> You do not need to hide the review request too :) >>> >>> Thanks, >>> Thomas >>> >>> From kirk.pepperdine at gmail.com Mon Feb 9 15:32:04 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 9 Feb 2015 16:32:04 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <54D8D2B3.6040903@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> <1423494109.3104.5.camel@oracle.com> <54D8CD67.6030202@oracle.com> <54D8CF71.4050702@oracle.com> <54D8D2B3.6040903@oracle.com> Message-ID: <8F311DA6-DDDA-4FDE-BC86-451336CF5ACC@gmail.com> seems reasonable! Regards, Kirk On Feb 9, 2015, at 4:30 PM, Mikael Gerdin wrote: > > > On 2015-02-09 16:17, Jesper Wilhelmsson wrote: >> Mikael Gerdin skrev den 9/2/15 16:08: >>> On 2015-02-09 16:01, Thomas Schatzl wrote: >>>> Hi Jesper, >>>> >>>> On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: >>>>> Hi Kirk, >>>>> >>>>> Thanks for reporting this! >>>>> I filed a bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8072688 >>>>> >>>>> and have a fix out for review: >>>>> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ >>>>> >>>> >>>> looks good - not sure if the explicit mention of the two >>>> collectors is >>>> necessary. We do not do it for many other flags either. >>> >>> I agree that it would be better to not mention any specific GC: >>> "effective only when a concurrent GC is enabled" >>> is my suggestion. >>> >> >> Since I already changed it to "(effective only when using concurrent >> collectors)" and published the new webrev, that is my suggestion :) >> >> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.01/ > > That's fine with me. > > /Mikael > >> >> /Jesper >> >>> /Mikael >>> >>>> >>>> Maybe if you waited a little more if somebody else feels strongly about >>>> this. >>>> >>>> You do not need to hide the review request too :) >>>> >>>> Thanks, >>>> Thomas >>>> >>>> From thomas.schatzl at oracle.com Mon Feb 9 16:06:20 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Feb 2015 17:06:20 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <54D8CF71.4050702@oracle.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> <1423494109.3104.5.camel@oracle.com> <54D8CD67.6030202@oracle.com> <54D8CF71.4050702@oracle.com> Message-ID: <1423497980.3104.7.camel@oracle.com> Hi, On Mon, 2015-02-09 at 16:17 +0100, Jesper Wilhelmsson wrote: > Mikael Gerdin skrev den 9/2/15 16:08: > > On 2015-02-09 16:01, Thomas Schatzl wrote: > >> Hi Jesper, > >> > >> On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: > >>> Hi Kirk, > >>> > >>> Thanks for reporting this! > >>> I filed a bug: > >>> https://bugs.openjdk.java.net/browse/JDK-8072688 > >>> > >>> and have a fix out for review: > >>> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ > >>> > >> > >> looks good - not sure if the explicit mention of the two collectors is > >> necessary. We do not do it for many other flags either. > > > > I agree that it would be better to not mention any specific GC: > > "effective only when a concurrent GC is enabled" > > is my suggestion. looks good. Thanks, Thomas From jesper.wilhelmsson at oracle.com Mon Feb 9 16:47:22 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 09 Feb 2015 17:47:22 +0100 Subject: RFR (XXS): 8072688: Description of flag ExplicitGCInvokesConcurrent should mantion G1 as well [Was: Re: comments in globals.hpp] In-Reply-To: <8F311DA6-DDDA-4FDE-BC86-451336CF5ACC@gmail.com> References: <631ED8F4-1AEB-4B0E-9B42-C3678863CFF4@gmail.com> <54D4CFEA.5000502@oracle.com> <1423494109.3104.5.camel@oracle.com> <54D8CD67.6030202@oracle.com> <54D8CF71.4050702@oracle.com> <54D8D2B3.6040903@oracle.com> <8F311DA6-DDDA-4FDE-BC86-451336CF5ACC@gmail.com> Message-ID: <54D8E49A.1050704@oracle.com> Thanks Mikael, Thomas, and Kirk for reviewing this fix! /Jesper Kirk Pepperdine skrev den 9/2/15 16:32: > seems reasonable! > > Regards, > Kirk > > On Feb 9, 2015, at 4:30 PM, Mikael Gerdin wrote: > >> >> >> On 2015-02-09 16:17, Jesper Wilhelmsson wrote: >>> Mikael Gerdin skrev den 9/2/15 16:08: >>>> On 2015-02-09 16:01, Thomas Schatzl wrote: >>>>> Hi Jesper, >>>>> >>>>> On Fri, 2015-02-06 at 15:30 +0100, Jesper Wilhelmsson wrote: >>>>>> Hi Kirk, >>>>>> >>>>>> Thanks for reporting this! >>>>>> I filed a bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8072688 >>>>>> >>>>>> and have a fix out for review: >>>>>> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.00/ >>>>>> >>>>> >>>>> looks good - not sure if the explicit mention of the two >>>>> collectors is >>>>> necessary. We do not do it for many other flags either. >>>> >>>> I agree that it would be better to not mention any specific GC: >>>> "effective only when a concurrent GC is enabled" >>>> is my suggestion. >>>> >>> >>> Since I already changed it to "(effective only when using concurrent >>> collectors)" and published the new webrev, that is my suggestion :) >>> >>> http://cr.openjdk.java.net/~jwilhelm/8072688/webrev.01/ >> >> That's fine with me. >> >> /Mikael >> >>> >>> /Jesper >>> >>>> /Mikael >>>> >>>>> >>>>> Maybe if you waited a little more if somebody else feels strongly about >>>>> this. >>>>> >>>>> You do not need to hide the review request too :) >>>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> > From kim.barrett at oracle.com Mon Feb 9 20:05:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 9 Feb 2015 15:05:43 -0500 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54CA0F41.3090909@oracle.com> References: <54CA0F41.3090909@oracle.com> Message-ID: On Jan 29, 2015, at 5:45 AM, Jesper Wilhelmsson wrote: > > Hi, > > Please review this second attempt to remove the generations array. > > There were two bugs that caused this patch to be backed out the last time: > > 1. Collection of the old generation was always run even if the young collection freed up enough to satisfy the allocation need. This was due to an unexpected use of the size variable and stopped working when the code that changed the variable was broken out into a separate function. > > 2. The new _young_generation and _old_generation fields was missing from the declarations in vm_structs.cpp. Cut'n'paste error when the original huge change was split into smaller parts for easier review. > > I have resolved these issues. I also moved the BiasedLocking::preserve_marks() since the previous change didn't preserve exactly the same behavior. And I added a comment in a test that caused some issues when I was debugging this. > > Testing: AdHoc run of the nightly GC tests, JPRT, and JTREG > > > RFE: https://bugs.openjdk.java.net/browse/JDK-8061802 > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01/ > > I also made an incremental webrev based on the old patch applied to a fresh version of the GC repo. Please note that the old patch do not apply cleanly to a current GC repo, but the changes in the incremental diff should cover what has been changed with regards to this RFE. Please refer to the full webrevs if in doubt. > > Incremental webrev: > http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01.incremental/ > > Old (buggy) webrev: http://cr.openjdk.java.net/~jwilhelm/8055702/webrev.01/ > > > For reference, as I mentioned above the original huge change was split into several smaller parts. This is the first of those parts. The other can be found here: > > http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.01/ > > Please note that these are the old patches that applies on top of the old (buggy) patch above. They will not apply cleanly on top of the new patch. I'll update these once the first part is finalized. > > Thanks, > /Jesper ------------------------------------------------------------------------------ Throughout, copyrights need to be updated. ------------------------------------------------------------------------------ agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java 71 public Generation getGen(int i) { 72 if (Assert.ASSERTS_ENABLED) { 73 Assert.that((i >= 0) && (i < nGens()), "Index " + i + 74 " out of range (should be between 0 and " + nGens() + ")"); 75 } 76 77 switch (i) { 78 case 0: 79 return genFactory.newObject(youngGenField.getAddress()); 80 case 1: 81 return genFactory.newObject(oldGenField.getAddress()); 82 default: 83 // no generation for i, and assertions disabled. 84 return null; 85 } 86 } With the replacement of the old code with the switch statement, the assertion seems both poorly placed and not entirely sufficient. The code is now assuming that nGens() == 2, for example. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 131 ReservedSpace young_rs = heap_rs.first_part(_gen_specs[0]->max_size(), false, false); 132 _young_gen = _gen_specs[0]->init(young_rs, 0, rem_set()); 133 heap_rs = heap_rs.last_part(_gen_specs[0]->max_size()); 134 135 ReservedSpace old_rs = heap_rs.first_part(_gen_specs[1]->max_size(), false, false); 136 _old_gen = _gen_specs[1]->init(old_rs, 1, rem_set()); 137 heap_rs = heap_rs.last_part(_gen_specs[1]->max_size()); I feel like there should be an assertion somewhere before here that _n_gens == 2. Also, I think line 137 is unnecessary. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 216 void GenCollectedHeap::save_used_regions(int level) { 217 assert(level < _n_gens, "Illegal level parameter"); 218 if (level == 1) { 219 _old_gen->save_used_region(); 220 } 221 _young_gen->save_used_region(); 222 } Assumes level >= 0. Old code would do nothing with negative level. Probably negative level is a bug, and should be asserted against. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp collect_generation and do_collection I tried to give the changes here a thorough look, but the diffs are very messy. I hope I didn't miss anything. I think the review of this would have been noticably easier if the extraction of collect_generation into a separate function had happened before and independently of the generation array changes. Oh well. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 574 void GenCollectedHeap:: 575 gen_process_roots(int level, I think the proposed changes maintain the previous behavior, as desired. However ... This is probably something for a future (but soon, I hope) cleanup. GenCollectedHeap::gen_process_roots() is a bit of a mess now. It first calls SharedHeap::process_roots. It then does completely different things, depending on the value of the first (level) argument. That's not at all obvious from the way the code is written though. Retaining the structure from the old iteration through _gens[] is not helpful in the new world where we have exactly two generations. (I was surprised to note that the old code seems to do nothing for _gens[level]. I wonder if that was a lurking bug?) There are two overloads for gen_process_roots(). The first does most of the work. The second constructs an additional closure and calls the first with that closure plus some other argument adjustments. I think all client callers call the second; the first could be hoisted into the second and eliminated as a separate function. I also suspect that, with some careful analysis, we could determine the level value for all callers. This and the fact that this function does very different things according to the level suggests splitting this function into two distinct functions. Here's what I came up with for the level values being provided: - MarkSweep always calls with level == 1 (assertion) - CMS always calls with level == _cmsGen->level() presumably _cmsGen->level() is 1, since _cmsGen is old_gen? - ParNewGeneration::work calls with level == _gen->level() _gen is the young generation, so level is always 0 here? - DefNewGeneration::collect calls with level == _level _level is 0, since this is young generation? The two callers apparently providing 0 as the level also always provide true as the second (younger_gens_as_roots) argument. I suspect there are other argument simplifications that would result from splitting. I'm ok with the proposed change as is, as part of that change set. But please make sure there's a follow-on cleanup RFE. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 837 // This might be sped up with a cache of the last generation that 838 // answered yes. 839 if (_young_gen->is_in(p) || _old_gen->is_in(p)) { 840 return true; 841 } 842 // Otherwise... 843 return false; The comment on line 837 seems mostly relevant to the old code that iterated through the generations array. Is it still relevant? Especially since it seems to bottom out in Space::is_in(), which is documented as being potentially slow and so only to be used in assert. Also, with only the two generations now, I'd probably write this as return _young_gen->is_in(p) || _old_gen->is_in(p); ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 1046 void GenCollectedHeap::prepare_for_compaction() { 1047 guarantee(_n_gens = 2, "Wrong number of generations"); 1048 Generation* old_gen = _old_gen; 1049 // Start by compacting into same gen. 1050 CompactPoint cp(old_gen); 1051 old_gen->prepare_for_compaction(&cp); 1052 Generation* young_gen = _young_gen; 1053 young_gen->prepare_for_compaction(&cp); 1054 } The old_gen and young_gen local variables just add clutter after the rewrite. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.hpp 387 Generation* get_gen(int i) const { 388 guarantee(i >= 0 && i < _n_gens, "Out of bounds"); 389 if (i == 0) { 390 return _young_gen; 391 } else { 392 return _old_gen; 393 } 394 } The assertion here now ought to be (level == 0 || level == 1). And _n_gens must be 2. ------------------------------------------------------------------------------ From tom.benson at oracle.com Tue Feb 10 02:01:05 2015 From: tom.benson at oracle.com (Tom Benson) Date: Mon, 09 Feb 2015 21:01:05 -0500 Subject: RFR: (XXS): 8072056: Remove unnecessary header file #include Message-ID: <54D96661.2020405@oracle.com> Hi, I need reviewers and a commit sponsor for the tiny clean-up described in bug 8072056, which removes an unnecessary header file #include. Webrev: http://cr.openjdk.java.net/~jprovino/8072056/webrev.00 JBS bug: https://bugs.openjdk.java.net/browse/JDK-8072056 jprt url: http://scaaa637.us.oracle.com/archive/2015/02/2015-02-09-154643.trbenson.hs-gc/ Thanks, Tom From kim.barrett at oracle.com Tue Feb 10 04:25:31 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 9 Feb 2015 23:25:31 -0500 Subject: RFR: (XXS): 8072056: Remove unnecessary header file #include In-Reply-To: <54D96661.2020405@oracle.com> References: <54D96661.2020405@oracle.com> Message-ID: <3815DE77-3CA7-46AD-822A-193499719A1A@oracle.com> On Feb 9, 2015, at 9:01 PM, Tom Benson wrote: > > Hi, > I need reviewers and a commit sponsor for the tiny clean-up described in bug 8072056, which removes an unnecessary header file #include. > > Webrev: http://cr.openjdk.java.net/~jprovino/8072056/webrev.00 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8072056 > jprt url: http://scaaa637.us.oracle.com/archive/2015/02/2015-02-09-154643.trbenson.hs-gc/ The copyright year in the header comment needs to be updated. Looks good, other than that. From kim.barrett at oracle.com Tue Feb 10 05:24:56 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Feb 2015 00:24:56 -0500 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <54D327C6.7040802@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> <54D327C6.7040802@oracle.com> Message-ID: <0C4ACE66-50C0-41A9-A71C-C31A08584148@oracle.com> On Feb 5, 2015, at 3:20 AM, Marcus Larsson wrote: > > Hi Kim, > > Thanks for looking at this. > > On 04/02/15 21:48, Kim Barrett wrote: >> Sorry for the delay; I lost track of this. >> >> On Dec 10, 2014, at 9:51 AM, Marcus Larsson wrote: >>> Hi again, >>> >>> Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8066566/webrev.02/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01-02/ >> src/share/vm/gc_implementation/parNew/parNewGeneration.cpp >> 417 const ParNewTracer* gc_tracer() const { >> 418 return &_gc_tracer; >> 419 } >> >> All present calls are in the providing class's implementation, and >> could just as easily be replaced with "&_gc_tracer". Returning a >> pointer into the implementation of an object is generally best >> avoided, and in this case it's unnecessary. Promoting it to a public >> API just adds to the burden. > > As I mentioned in the original email, this getter for the field is added although it is currently unnecessary. > However, it is added in preparation for https://bugs.openjdk.java.net/browse/JDK-8066444 and will soon be required. > Arguably the addition of this getter belongs to that CR, but I thought I might as well add it here while doing the refactoring. Sorry, forgot that. In a different code base I would expect return of const reference. But as Erik noted, Hotspot is very ?pointy?. Looks good. From thomas.schatzl at oracle.com Tue Feb 10 11:24:59 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Feb 2015 12:24:59 +0100 Subject: RFR: (XXS): 8072056: Remove unnecessary header file #include In-Reply-To: <54D96661.2020405@oracle.com> References: <54D96661.2020405@oracle.com> Message-ID: <1423567499.3436.2.camel@oracle.com> Hi, On Mon, 2015-02-09 at 21:01 -0500, Tom Benson wrote: > Hi, > I need reviewers and a commit sponsor for the tiny clean-up described in > bug 8072056, which removes an unnecessary header file #include. > > Webrev: http://cr.openjdk.java.net/~jprovino/8072056/webrev.00 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8072056 looks good. I can sponsor the change. Thanks, Thomas From thomas.schatzl at oracle.com Tue Feb 10 13:03:44 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Feb 2015 14:03:44 +0100 Subject: Review request for JDK-8030815: Code roots are not accounted for in region efficiency In-Reply-To: <54B5518B.8010800@oracle.com> References: <54B5518B.8010800@oracle.com> Message-ID: <1423573424.3436.7.camel@oracle.com> Hi, On Tue, 2015-01-13 at 12:10 -0500, Alexander Harlap wrote: > Please help to code review the change for the following CR: > JDK-8030815 - Code roots are not accounted for in region efficiency > > The webrev is located at > http://cr.openjdk.java.net/~aharlap/8030815/webrev.00/ > > Testing completed: JPRT - in TraceYoungGenTimeData::print_summary_sd(): please call the added entry like the one in PrintGCDetails output, i.e. "Code Root Scanning" instead of "Scan Code Root RS". - in G1CollectoryPolicy::1148: please move the "+" sign to the end of the previous line like everywhere else but this statement. (I know this has been the case before, it would be nice to make the code more uniform). - I would prefer if the cost of scanning code roots would not be conflated with the cost of scanning rset entries, but predicted and tracked separately from remembered set entries. I.e. in G1CollectorPolicy::predict_region_elapsed_time_ms() the region_elapsed_time (the predicted time for evacuating the region) would consist of double region_elapsed_time_ms = predict_rs_scan_time_ms(card_num) + predict_code_root_scan_time_ms(hr->num_code_roots()) + // new predict_object_copy_time(bytes_to_copy); This needs an additional prediction code of code roots for the young gen; look at young_cards_per_entry_ratio_seq for the predictor for the number of cards to see how its done for the regular remembered set. Thanks, Thomas From joseph.provino at oracle.com Tue Feb 10 14:55:16 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 10 Feb 2015 09:55:16 -0500 Subject: RFR: (XXS): 8072056: Remove unnecessary header file #include In-Reply-To: <54D96661.2020405@oracle.com> References: <54D96661.2020405@oracle.com> Message-ID: <54DA1BD4.4050309@oracle.com> Looks good. joe On 2/9/2015 9:01 PM, Tom Benson wrote: > Hi, > I need reviewers and a commit sponsor for the tiny clean-up described > in bug 8072056, which removes an unnecessary header file #include. > > Webrev: http://cr.openjdk.java.net/~jprovino/8072056/webrev.00 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8072056 > jprt url: > http://scaaa637.us.oracle.com/archive/2015/02/2015-02-09-154643.trbenson.hs-gc/ > > Thanks, > Tom From goetz.lindenmaier at sap.com Tue Feb 10 15:43:09 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Feb 2015 15:43:09 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Message-ID: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.benson at oracle.com Tue Feb 10 17:56:22 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 10 Feb 2015 12:56:22 -0500 Subject: RFR: (XXS): 8072056: Remove unnecessary header file #include In-Reply-To: <3815DE77-3CA7-46AD-822A-193499719A1A@oracle.com> References: <54D96661.2020405@oracle.com> <3815DE77-3CA7-46AD-822A-193499719A1A@oracle.com> Message-ID: <54DA4646.3000709@oracle.com> > The copyright year in the header comment needs to be updated. Will do. Thanks, Tom On 2/9/2015 11:25 PM, Kim Barrett wrote: > On Feb 9, 2015, at 9:01 PM, Tom Benson wrote: >> Hi, >> I need reviewers and a commit sponsor for the tiny clean-up described in bug 8072056, which removes an unnecessary header file #include. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8072056/webrev.00 >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8072056 >> jprt url: http://scaaa637.us.oracle.com/archive/2015/02/2015-02-09-154643.trbenson.hs-gc/ > The copyright year in the header comment needs to be updated. > > Looks good, other than that. > From tom.benson at oracle.com Tue Feb 10 20:26:55 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 10 Feb 2015 15:26:55 -0500 Subject: RFR: (XXS): 8065093: Remove unused variable/output argument Message-ID: <54DA698F.7060308@oracle.com> Hi, I need reviewers and a commit sponsor for another small clean-up task. Bug 8065093 points out that total_reserved can be removed from GenCollectedHeap::initialize and ::allocate. Webrev: http://cr.openjdk.java.net/~jprovino/8065093/webrev.01 JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065093 jprt url: http://scaaa637.us.oracle.com//archive/2015/02/2015-02-09-195058.trbenson.hs-gc Thanks, Tom From jesper.wilhelmsson at oracle.com Tue Feb 10 20:38:26 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 10 Feb 2015 21:38:26 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: References: <54CA0F41.3090909@oracle.com> Message-ID: <54DA6C42.7060209@oracle.com> Hi Kim, Thanks for taking another close look at this change! Some of these issues are the result of this being a part of a bigger change, but I have addressed your concerns to make sure this intermediate version is of decent quality even without the following cleanups. (Even though I hope we will get the rest in asap. Those will be a lot easier to review). For example anything related to levels and _n_gens will be removed in later patches when the entire level concept is removed. A new webrev is available here: http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.02/ Some replies inline. Kim Barrett skrev den 9/2/15 21:05: > On Jan 29, 2015, at 5:45 AM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review this second attempt to remove the generations array. >> >> There were two bugs that caused this patch to be backed out the last time: >> >> 1. Collection of the old generation was always run even if the young collection freed up enough to satisfy the allocation need. This was due to an unexpected use of the size variable and stopped working when the code that changed the variable was broken out into a separate function. >> >> 2. The new _young_generation and _old_generation fields was missing from the declarations in vm_structs.cpp. Cut'n'paste error when the original huge change was split into smaller parts for easier review. >> >> I have resolved these issues. I also moved the BiasedLocking::preserve_marks() since the previous change didn't preserve exactly the same behavior. And I added a comment in a test that caused some issues when I was debugging this. >> >> Testing: AdHoc run of the nightly GC tests, JPRT, and JTREG >> >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8061802 >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01/ >> >> I also made an incremental webrev based on the old patch applied to a fresh version of the GC repo. Please note that the old patch do not apply cleanly to a current GC repo, but the changes in the incremental diff should cover what has been changed with regards to this RFE. Please refer to the full webrevs if in doubt. >> >> Incremental webrev: >> http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01.incremental/ >> >> Old (buggy) webrev: http://cr.openjdk.java.net/~jwilhelm/8055702/webrev.01/ >> >> >> For reference, as I mentioned above the original huge change was split into several smaller parts. This is the first of those parts. The other can be found here: >> >> http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.01/ >> >> Please note that these are the old patches that applies on top of the old (buggy) patch above. They will not apply cleanly on top of the new patch. I'll update these once the first part is finalized. >> >> Thanks, >> /Jesper > > ------------------------------------------------------------------------------ > Throughout, copyrights need to be updated. > > ------------------------------------------------------------------------------ > agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java > 71 public Generation getGen(int i) { > 72 if (Assert.ASSERTS_ENABLED) { > 73 Assert.that((i >= 0) && (i < nGens()), "Index " + i + > 74 " out of range (should be between 0 and " + nGens() + ")"); > 75 } > 76 > 77 switch (i) { > 78 case 0: > 79 return genFactory.newObject(youngGenField.getAddress()); > 80 case 1: > 81 return genFactory.newObject(oldGenField.getAddress()); > 82 default: > 83 // no generation for i, and assertions disabled. > 84 return null; > 85 } > 86 } > > With the replacement of the old code with the switch statement, the > assertion seems both poorly placed and not entirely sufficient. The > code is now assuming that nGens() == 2, for example. I updated the assertion and removed the usage of nGens() in this method. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 131 ReservedSpace young_rs = heap_rs.first_part(_gen_specs[0]->max_size(), false, false); > 132 _young_gen = _gen_specs[0]->init(young_rs, 0, rem_set()); > 133 heap_rs = heap_rs.last_part(_gen_specs[0]->max_size()); > 134 > 135 ReservedSpace old_rs = heap_rs.first_part(_gen_specs[1]->max_size(), false, false); > 136 _old_gen = _gen_specs[1]->init(old_rs, 1, rem_set()); > 137 heap_rs = heap_rs.last_part(_gen_specs[1]->max_size()); > > I feel like there should be an assertion somewhere before here that > _n_gens == 2. > > Also, I think line 137 is unnecessary. Assertion added and line removed. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 216 void GenCollectedHeap::save_used_regions(int level) { > 217 assert(level < _n_gens, "Illegal level parameter"); > 218 if (level == 1) { > 219 _old_gen->save_used_region(); > 220 } > 221 _young_gen->save_used_region(); > 222 } > > Assumes level >= 0. Old code would do nothing with negative level. > Probably negative level is a bug, and should be asserted against. Assertion added. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > collect_generation and do_collection > > I tried to give the changes here a thorough look, but the diffs are > very messy. I hope I didn't miss anything. > > I think the review of this would have been noticably easier if the > extraction of collect_generation into a separate function had happened > before and independently of the generation array changes. Oh well. That may be true, even though I believe that the only major difference if this would have been done separately would be that the call sites would use get_gen(0/1) instead of young/old_gen. This is clearly the most difficult part of removing the generation array and also this is where we saw a few bugs in the last version. According to our tests it should be fine now. :) > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 574 void GenCollectedHeap:: > 575 gen_process_roots(int level, > > I think the proposed changes maintain the previous behavior, as > desired. However ... > > This is probably something for a future (but soon, I hope) cleanup. > > GenCollectedHeap::gen_process_roots() is a bit of a mess now. It first > calls SharedHeap::process_roots. It then does completely different > things, depending on the value of the first (level) argument. That's > not at all obvious from the way the code is written though. Retaining > the structure from the old iteration through _gens[] is not helpful in > the new world where we have exactly two generations. > > (I was surprised to note that the old code seems to do nothing for > _gens[level]. I wonder if that was a lurking bug?) > > There are two overloads for gen_process_roots(). The first does most > of the work. The second constructs an additional closure and calls > the first with that closure plus some other argument adjustments. I > think all client callers call the second; the first could be hoisted > into the second and eliminated as a separate function. > > I also suspect that, with some careful analysis, we could determine > the level value for all callers. This and the fact that this function > does very different things according to the level suggests splitting > this function into two distinct functions. > > Here's what I came up with for the level values being provided: > > - MarkSweep always calls with level == 1 (assertion) > - CMS always calls with level == _cmsGen->level() > presumably _cmsGen->level() is 1, since _cmsGen is old_gen? > - ParNewGeneration::work calls with level == _gen->level() > _gen is the young generation, so level is always 0 here? > - DefNewGeneration::collect calls with level == _level > _level is 0, since this is young generation? > > The two callers apparently providing 0 as the level also always > provide true as the second (younger_gens_as_roots) argument. I > suspect there are other argument simplifications that would result > from splitting. > > I'm ok with the proposed change as is, as part of that change set. > But please make sure there's a follow-on cleanup RFE. I absolutely agree and I assume there are other simplifications and cleanups that will be apparent once the rest of the cleanups goes in as well. I copied your description above into an RFE to handle this issue. https://bugs.openjdk.java.net/browse/JDK-8072809 > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 837 // This might be sped up with a cache of the last generation that > 838 // answered yes. > 839 if (_young_gen->is_in(p) || _old_gen->is_in(p)) { > 840 return true; > 841 } > 842 // Otherwise... > 843 return false; > > The comment on line 837 seems mostly relevant to the old code that > iterated through the generations array. Is it still relevant? > Especially since it seems to bottom out in Space::is_in(), which is > documented as being potentially slow and so only to be used in assert. > > Also, with only the two generations now, I'd probably write this as > > return _young_gen->is_in(p) || _old_gen->is_in(p); Agreed. Fixed. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 1046 void GenCollectedHeap::prepare_for_compaction() { > 1047 guarantee(_n_gens = 2, "Wrong number of generations"); > 1048 Generation* old_gen = _old_gen; > 1049 // Start by compacting into same gen. > 1050 CompactPoint cp(old_gen); > 1051 old_gen->prepare_for_compaction(&cp); > 1052 Generation* young_gen = _young_gen; > 1053 young_gen->prepare_for_compaction(&cp); > 1054 } > > The old_gen and young_gen local variables just add clutter after the > rewrite. Agreed. This was taken care of in one of the later cleanups but I moved that cleanup into this patch. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.hpp > 387 Generation* get_gen(int i) const { > 388 guarantee(i >= 0 && i < _n_gens, "Out of bounds"); > 389 if (i == 0) { > 390 return _young_gen; > 391 } else { > 392 return _old_gen; > 393 } > 394 } > > The assertion here now ought to be (level == 0 || level == 1). And > _n_gens must be 2. Assert fixed. > > ------------------------------------------------------------------------------ > Thank you! /Jesper From thomas.schatzl at oracle.com Tue Feb 10 20:59:05 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Feb 2015 21:59:05 +0100 Subject: RFR: (XXS): 8065093: Remove unused variable/output argument In-Reply-To: <54DA698F.7060308@oracle.com> References: <54DA698F.7060308@oracle.com> Message-ID: <1423601945.3307.4.camel@oracle.com> Hi, On Tue, 2015-02-10 at 15:26 -0500, Tom Benson wrote: > Hi, > I need reviewers and a commit sponsor for another small clean-up task. > Bug 8065093 points out that total_reserved can be removed from > GenCollectedHeap::initialize and ::allocate. > > Webrev: http://cr.openjdk.java.net/~jprovino/8065093/webrev.01 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065093 > jprt url: > http://scaaa637.us.oracle.com//archive/2015/02/2015-02-09-195058.trbenson.hs-gc > looks good to me. Could you add a line of documentation to the allocate method in the hpp file? Thanks, Thomas From kim.barrett at oracle.com Tue Feb 10 22:26:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Feb 2015 17:26:53 -0500 Subject: RFR: (XXS): 8065093: Remove unused variable/output argument In-Reply-To: <54DA698F.7060308@oracle.com> References: <54DA698F.7060308@oracle.com> Message-ID: <44860519-D74D-4EE4-A0EE-1F7790A57F52@oracle.com> On Feb 10, 2015, at 3:26 PM, Tom Benson wrote: > > Hi, > I need reviewers and a commit sponsor for another small clean-up task. Bug 8065093 points out that total_reserved can be removed from GenCollectedHeap::initialize and ::allocate. > > Webrev: http://cr.openjdk.java.net/~jprovino/8065093/webrev.01 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065093 > jprt url: http://scaaa637.us.oracle.com//archive/2015/02/2015-02-09-195058.trbenson.hs-gc > > Thanks, > Tom Looks good. From kim.barrett at oracle.com Tue Feb 10 22:56:20 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Feb 2015 17:56:20 -0500 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54DA6C42.7060209@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> Message-ID: On Feb 10, 2015, at 3:38 PM, Jesper Wilhelmsson wrote: > > Hi Kim, > > Thanks for taking another close look at this change! > > Some of these issues are the result of this being a part of a bigger change, but I have addressed your concerns to make sure this intermediate version is of decent quality even without the following cleanups. (Even though I hope we will get the rest in asap. Those will be a lot easier to review). > > For example anything related to levels and _n_gens will be removed in later patches when the entire level concept is removed. That?s what I thought, but I would prefer having this changeset be able to stand on its own merits. I think the further changes will be easier to understand with the additional (usually temporary) asserts and such, especially for anyone who didn?t review this changeset. > A new webrev is available here: > http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.02/ This webrev seems to be broken - genCollectedHeap.cpp frame display is messed up. Old version is showing as empty, although new version still highlights differences. I didn?t look at it carefully though, since I?m not sure I?d be looking at anything like the intended code. A few inline replies. >> ------------------------------------------------------------------------------ >> src/share/vm/memory/genCollectedHeap.cpp >> collect_generation and do_collection >> >> I tried to give the changes here a thorough look, but the diffs are >> very messy. I hope I didn't miss anything. >> >> I think the review of this would have been noticably easier if the >> extraction of collect_generation into a separate function had happened >> before and independently of the generation array changes. Oh well. > > That may be true, even though I believe that the only major difference if this would have been done separately would be that the call sites would use get_gen(0/1) instead of young/old_gen. This is clearly the most difficult part of removing the generation array and also this is where we saw a few bugs in the last version. According to our tests it should be fine now. :) I think having the splitting isolated might have made comparison checking easier, at least for me, because I?d know there weren?t supposed to be any functional differences. I wonder if the diff might have been simpler with collect_generation after do_collection. But this is all water under the bridge. >> ------------------------------------------------------------------------------ >> src/share/vm/memory/genCollectedHeap.cpp >> 574 void GenCollectedHeap:: >> 575 gen_process_roots(int level, >> >> I think the proposed changes maintain the previous behavior, as >> desired. However ... >> >> This is probably something for a future (but soon, I hope) cleanup. >> >> [?] >> I'm ok with the proposed change as is, as part of that change set. >> But please make sure there's a follow-on cleanup RFE. > > I absolutely agree and I assume there are other simplifications and cleanups that will be apparent once the rest of the cleanups goes in as well. I copied your description above into an RFE to handle this issue. > > https://bugs.openjdk.java.net/browse/JDK-8072809 Thank you. From kim.barrett at oracle.com Tue Feb 10 23:03:24 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Feb 2015 18:03:24 -0500 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54D4D967.7030205@oracle.com> References: <54D4D967.7030205@oracle.com> Message-ID: <7DBEFE4C-54D2-4092-A58C-A1EE7B7C1B23@oracle.com> On Feb 6, 2015, at 10:10 AM, Mikael Gerdin wrote: > > Hi all, > > There are some problems with the Diagnostic Command GCCause change, I suggest that we back out the change and reconsider its implementation. > > [from the bug] > The change is incomplete since several places in the GC code assumes that explicit gcs have the _java_lang_system_gc GCCause value in order to determine the behavior. > For example: > ParallelGC does not apply policy decisions on user-invoked GCs (decided by the GCCause) > G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. > This could cause problems for people expecting concurrent gcs when running the diagnostic command instead of a possibly several-second full gc pause. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 > Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ A procedural question: Shouldn't this backout be accompanied by re-opening the original RFE (JDK-8068589) that was resolved by the changeset that is now being backed out? From tom.benson at oracle.com Wed Feb 11 01:25:44 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 10 Feb 2015 20:25:44 -0500 Subject: RFR: (XXS): 8065093: Remove unused variable/output argument In-Reply-To: <1423601945.3307.4.camel@oracle.com> References: <54DA698F.7060308@oracle.com> <1423601945.3307.4.camel@oracle.com> Message-ID: <54DAAF98.7050300@oracle.com> Hi, I've added the comment. The updated webrev is here: Webrev: http://cr.openjdk.java.net/~jprovino/8065093/webrev.03 JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065093 Thanks, Tom On 2/10/2015 3:59 PM, Thomas Schatzl wrote: > looks good to me. Could you add a line of documentation to the > allocate method in the hpp file? Thanks, Thomas From kim.barrett at oracle.com Wed Feb 11 08:09:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Feb 2015 03:09:43 -0500 Subject: RFR: (XXS): 8065093: Remove unused variable/output argument In-Reply-To: <54DAAF98.7050300@oracle.com> References: <54DA698F.7060308@oracle.com> <1423601945.3307.4.camel@oracle.com> <54DAAF98.7050300@oracle.com> Message-ID: On Feb 10, 2015, at 8:25 PM, Tom Benson wrote: > > Hi, > I've added the comment. The updated webrev is here: > > Webrev: http://cr.openjdk.java.net/~jprovino/8065093/webrev.03 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065093 Looks good. From goetz.lindenmaier at sap.com Wed Feb 11 08:45:41 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 11 Feb 2015 08:45:41 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Message-ID: <4295855A5C1DE049A61835A1887419CC2CF94DC9@DEWDFEMB12A.global.corp.sap> Hi, maybe my explanations to this change are too short to easily understand it. This concerns jtreg test sanity/ExecuteInternalVMTests.java. The error is ... Running test: TestNewSize_test() # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/collectorPolicy.cpp:1015 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/sapmnt/home1/d045726/oJ/aarch-hs-comp/src/share/vm/memory/collectorPolicy.cpp:1015), pid=30500, tid=4398080324160 # assert(msp.initial_young_size() == expected) failed: 44695552 != 34930688 I also added some explanations in the bug. Does this help? Thanks and best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 10. Februar 2015 16:43 To: 'hotspot-dev Source Developers'; hotspot-gc-dev at openjdk.java.net Subject: RE: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Wed Feb 11 09:40:20 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Feb 2015 10:40:20 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp Message-ID: <54DB2384.3020403@oracle.com> Hi all, Please, review this patch to move the implementation of g1EvacFailure.hpp into a new cpp file. This helps reducing our include dependencies in the header files. http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8072910 Thanks, StefanK From jesper.wilhelmsson at oracle.com Wed Feb 11 09:56:15 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Feb 2015 10:56:15 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp In-Reply-To: <54DB2384.3020403@oracle.com> References: <54DB2384.3020403@oracle.com> Message-ID: <54DB273F.9080006@oracle.com> Looks good! Thanks for cleaning up the hpp file! /Jesper Stefan Karlsson skrev den 11/2/15 10:40: > Hi all, > > Please, review this patch to move the implementation of g1EvacFailure.hpp into a > new cpp file. This helps reducing our include dependencies in the header files. > > http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8072910 > > Thanks, > StefanK From jesper.wilhelmsson at oracle.com Wed Feb 11 10:01:31 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Feb 2015 11:01:31 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> Message-ID: <54DB287B.7080305@oracle.com> Kim Barrett skrev den 10/2/15 23:56: > On Feb 10, 2015, at 3:38 PM, Jesper Wilhelmsson wrote: >> >> Hi Kim, >> >> Thanks for taking another close look at this change! >> >> Some of these issues are the result of this being a part of a bigger change, but I have addressed your concerns to make sure this intermediate version is of decent quality even without the following cleanups. (Even though I hope we will get the rest in asap. Those will be a lot easier to review). >> >> For example anything related to levels and _n_gens will be removed in later patches when the entire level concept is removed. > > That?s what I thought, but I would prefer having this changeset be able to stand on its own merits. I think the further changes will be easier to understand with the additional (usually temporary) asserts and such, especially for anyone who didn?t review this changeset. > >> A new webrev is available here: >> http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.02/ > > This webrev seems to be broken - genCollectedHeap.cpp frame display is messed up. Old version is showing as empty, although new version still highlights differences. I didn?t look at it carefully though, since I?m not sure I?d be looking at anything like the intended code. Yes. Apparently awk (on Mac?) has a hard coded limitation of 50 patterns, so webrev fails to process large files... I have installed gawk now and built a new webrev to replace the old one. (same link) /Jesper > > A few inline replies. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/memory/genCollectedHeap.cpp >>> collect_generation and do_collection >>> >>> I tried to give the changes here a thorough look, but the diffs are >>> very messy. I hope I didn't miss anything. >>> >>> I think the review of this would have been noticably easier if the >>> extraction of collect_generation into a separate function had happened >>> before and independently of the generation array changes. Oh well. >> >> That may be true, even though I believe that the only major difference if this would have been done separately would be that the call sites would use get_gen(0/1) instead of young/old_gen. This is clearly the most difficult part of removing the generation array and also this is where we saw a few bugs in the last version. According to our tests it should be fine now. :) > > I think having the splitting isolated might have made comparison checking easier, at least for me, because I?d know there weren?t supposed to be any functional differences. I wonder if the diff might have been simpler with collect_generation after do_collection. But this is all water under the bridge. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/memory/genCollectedHeap.cpp >>> 574 void GenCollectedHeap:: >>> 575 gen_process_roots(int level, >>> >>> I think the proposed changes maintain the previous behavior, as >>> desired. However ... >>> >>> This is probably something for a future (but soon, I hope) cleanup. >>> >>> [?] >>> I'm ok with the proposed change as is, as part of that change set. >>> But please make sure there's a follow-on cleanup RFE. >> >> I absolutely agree and I assume there are other simplifications and cleanups that will be apparent once the rest of the cleanups goes in as well. I copied your description above into an RFE to handle this issue. >> >> https://bugs.openjdk.java.net/browse/JDK-8072809 > > Thank you. > > From jesper.wilhelmsson at oracle.com Wed Feb 11 10:30:04 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Feb 2015 11:30:04 +0100 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <7DBEFE4C-54D2-4092-A58C-A1EE7B7C1B23@oracle.com> References: <54D4D967.7030205@oracle.com> <7DBEFE4C-54D2-4092-A58C-A1EE7B7C1B23@oracle.com> Message-ID: <54DB2F2C.9040006@oracle.com> Kim Barrett skrev den 11/2/15 00:03: > On Feb 6, 2015, at 10:10 AM, Mikael Gerdin wrote: >> >> Hi all, >> >> There are some problems with the Diagnostic Command GCCause change, I suggest that we back out the change and reconsider its implementation. >> >> [from the bug] >> The change is incomplete since several places in the GC code assumes that explicit gcs have the _java_lang_system_gc GCCause value in order to determine the behavior. >> For example: >> ParallelGC does not apply policy decisions on user-invoked GCs (decided by the GCCause) >> G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. >> This could cause problems for people expecting concurrent gcs when running the diagnostic command instead of a possibly several-second full gc pause. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ > > A procedural question: Shouldn't this backout be accompanied by re-opening the original RFE (JDK-8068589) that was resolved by the changeset that is now being backed out? > We can't reopen the old issue since it has already been used to push a change. The procedure is to create a REDO issue by cloning the original issue. I have done that now. /Jesper From thomas.schatzl at oracle.com Wed Feb 11 10:49:49 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 11 Feb 2015 11:49:49 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp In-Reply-To: <54DB2384.3020403@oracle.com> References: <54DB2384.3020403@oracle.com> Message-ID: <1423651789.3514.4.camel@oracle.com> Hi Stefan, On Wed, 2015-02-11 at 10:40 +0100, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to move the implementation of > g1EvacFailure.hpp into a new cpp file. This helps reducing our include > dependencies in the header files. > > http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8072910 is it possible to fix the comment about "Closures and tasks associated with any self-forwarding pointers..." at the top of the hpp file? There is only one task and no closures now. Not sure if that same comment is required in the cpp file. Maybe remove it. Otherwise looks good. Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 11 11:06:50 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 11 Feb 2015 12:06:50 +0100 Subject: RFR: (XXS): 8065093: Remove unused variable/output argument In-Reply-To: <54DAAF98.7050300@oracle.com> References: <54DA698F.7060308@oracle.com> <1423601945.3307.4.camel@oracle.com> <54DAAF98.7050300@oracle.com> Message-ID: <1423652810.3514.5.camel@oracle.com> Hi, On Tue, 2015-02-10 at 20:25 -0500, Tom Benson wrote: > Hi, > I've added the comment. The updated webrev is here: > > Webrev: http://cr.openjdk.java.net/~jprovino/8065093/webrev.03 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065093 Looks good. Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 11 12:43:07 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 11 Feb 2015 13:43:07 +0100 Subject: Any plans to increase G1 max region size to 64m? In-Reply-To: <54D89CCC.70600@oracle.com> References: <54D381BB.2080203@oracle.com> <1423229268.3186.13.camel@oracle.com> <54D89CCC.70600@oracle.com> Message-ID: <1423658587.3514.13.camel@oracle.com> Hi, On Mon, 2015-02-09 at 12:41 +0100, Thomas Viessmann wrote: > many thanks for your detailed explanation. Here are some more details > about the background. It seems that a humongous allocation triggers a > (long) evacuation pause although the eden is still (almost) empty. > Such long pauses could only be observed during a humongous allocation. In the case shown by the gc log snippet, the explanation is that G1 tries to start the concurrent cycle as soon as the occupancy in the old gen reaches the threshold. It checks the threshold every time a humongous allocation is done. I.e. this works as implemented. The cause for the long pauses seems to be a huge amount of reference changes before allocating the humongous object (the large amount of _pending_cards and the long update rs pause). I do not know why particularly before humongous object allocation this amount of pending cards is so high. There are two possibilities: - it seems to be the application doing a large amount of reference changes just before allocating that new large object; in the normal case (ie. when reaching a young gc when it is full) this number may have always been reduced by concurrent background activity to some manageable amount. - if that initial mark young gc happens right after a (final) mixed gc, this would explain the high amount of pending cards too. The single GC log entry does not give enough information to rule out either of these options. I created JDK-8072920 to record this problem. > Here is an example from the gc.log > > 173913.719: [G1Ergonomics (Concurrent Cycles) request concurrent > cycle initiation, reason: occupancy higher than threshold, occupancy: > 11710496768 bytes, allocation request: 33554448 bytes, threshold: Side note: This large object is exactly 32M + 16 bytes (i.e. object header) large. This means that this object actually requires 64M on the heap. Maybe the application could be improved for that. As for fixes/workaround for this problem assuming that I am correct about the situation: I do not think increasing the region size to 64M helps because the same situation can occur for 64M humongous objects too. I am of course not sure if the application ever tries to allocate 64M objects. Also, even with a 64M region size, your 32M+16 byte object is still considered humongous (i.e. the application would require 128M regions). In case these pending cards originate from a preceding mixed young gc, then a solution would be to increase the IHOP. I.e. give the background processing more time between the last mixed gc and that forced initial mark to process them to a useful level. I do not know if increasing IHOP is acceptable in this situation. If the application causes so many pending cards just before humongous object allocation, I do not see a good way to prevent this occurrence right now. Maybe somebody else has some idea. >From the log snippet I also saw that the application is running with a JDK7 build. 8u40's early reclaim may allow the application to have more free space in general, doing less marking cycles (but the problem may still occur in the current configuration). Thanks, Thomas From thomas.viessmann at oracle.com Wed Feb 11 12:53:06 2015 From: thomas.viessmann at oracle.com (Thomas Viessmann) Date: Wed, 11 Feb 2015 13:53:06 +0100 Subject: Any plans to increase G1 max region size to 64m? In-Reply-To: <1423658587.3514.13.camel@oracle.com> References: <54D381BB.2080203@oracle.com> <1423229268.3186.13.camel@oracle.com> <54D89CCC.70600@oracle.com> <1423658587.3514.13.camel@oracle.com> Message-ID: <54DB50B2.80904@oracle.com> Thanks Thomas, do you want me to attach the complete gc logfile to the bug? Thanks and Regards Thomas On 02/11/15 13:43, Thomas Schatzl wrote: > Hi, > > On Mon, 2015-02-09 at 12:41 +0100, Thomas Viessmann wrote: >> many thanks for your detailed explanation. Here are some more details >> about the background. It seems that a humongous allocation triggers a >> (long) evacuation pause although the eden is still (almost) empty. >> Such long pauses could only be observed during a humongous allocation. > In the case shown by the gc log snippet, the explanation is that G1 > tries to start the concurrent cycle as soon as the occupancy in the old > gen reaches the threshold. It checks the threshold every time a > humongous allocation is done. > > I.e. this works as implemented. > > The cause for the long pauses seems to be a huge amount of reference > changes before allocating the humongous object (the large amount of > _pending_cards and the long update rs pause). > > I do not know why particularly before humongous object allocation this > amount of pending cards is so high. There are two possibilities: > - it seems to be the application doing a large amount of reference > changes just before allocating that new large object; in the normal case > (ie. when reaching a young gc when it is full) this number may have > always been reduced by concurrent background activity to some manageable > amount. > - if that initial mark young gc happens right after a (final) mixed gc, > this would explain the high amount of pending cards too. > > The single GC log entry does not give enough information to rule out > either of these options. > > I created JDK-8072920 to record this problem. > >> Here is an example from the gc.log >> >> 173913.719: [G1Ergonomics (Concurrent Cycles) request concurrent >> cycle initiation, reason: occupancy higher than threshold, occupancy: >> 11710496768 bytes, allocation request: 33554448 bytes, threshold: > Side note: This large object is exactly 32M + 16 bytes (i.e. object > header) large. This means that this object actually requires 64M on the > heap. Maybe the application could be improved for that. > > As for fixes/workaround for this problem assuming that I am correct > about the situation: > > I do not think increasing the region size to 64M helps because the same > situation can occur for 64M humongous objects too. I am of course not > sure if the application ever tries to allocate 64M objects. Also, even > with a 64M region size, your 32M+16 byte object is still considered > humongous (i.e. the application would require 128M regions). > > In case these pending cards originate from a preceding mixed young gc, > then a solution would be to increase the IHOP. I.e. give the background > processing more time between the last mixed gc and that forced initial > mark to process them to a useful level. I do not know if increasing IHOP > is acceptable in this situation. > > If the application causes so many pending cards just before humongous > object allocation, I do not see a good way to prevent this occurrence > right now. Maybe somebody else has some idea. > > From the log snippet I also saw that the application is running with a > JDK7 build. 8u40's early reclaim may allow the application to have more > free space in general, doing less marking cycles (but the problem may > still occur in the current configuration). > > Thanks, > Thomas > > -- Oracle THOMAS VIESSMANN | Senior Principal Technical Support Engineer - Java Phone: +498914302496 | Mobile: +491743005467 Oracle Customer Technical Support - Java ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992 Muenchen ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 Muenchen Registergericht: Amtsgericht Muenchen, HRA 95603 Gesch?ftsf?hrere: Juergen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher ------------------------------------------------------------------------ ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From stefan.karlsson at oracle.com Wed Feb 11 12:53:21 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Feb 2015 13:53:21 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp In-Reply-To: <1423651789.3514.4.camel@oracle.com> References: <54DB2384.3020403@oracle.com> <1423651789.3514.4.camel@oracle.com> Message-ID: <54DB50C1.1040105@oracle.com> Hi Thomas, On 2015-02-11 11:49, Thomas Schatzl wrote: > Hi Stefan, > > On Wed, 2015-02-11 at 10:40 +0100, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to move the implementation of >> g1EvacFailure.hpp into a new cpp file. This helps reducing our include >> dependencies in the header files. >> >> http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8072910 > is it possible to fix the comment about "Closures and tasks associated > with any self-forwarding pointers..." at the top of the hpp file? > > There is only one task and no closures now. > > Not sure if that same comment is required in the cpp file. Maybe remove > it. > > Otherwise looks good. I've update the patch: http://cr.openjdk.java.net/~stefank/8072910/webrev.01 http://cr.openjdk.java.net/~stefank/8072910/webrev.01.delta Thanks, StefanK > > Thanks, > Thomas > > From stefan.karlsson at oracle.com Wed Feb 11 12:54:09 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Feb 2015 13:54:09 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp In-Reply-To: <54DB273F.9080006@oracle.com> References: <54DB2384.3020403@oracle.com> <54DB273F.9080006@oracle.com> Message-ID: <54DB50F1.9010905@oracle.com> On 2015-02-11 10:56, Jesper Wilhelmsson wrote: > Looks good! > Thanks for cleaning up the hpp file! Thanks! StefanK > /Jesper > > > Stefan Karlsson skrev den 11/2/15 10:40: >> Hi all, >> >> Please, review this patch to move the implementation of >> g1EvacFailure.hpp into a >> new cpp file. This helps reducing our include dependencies in the >> header files. >> >> http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8072910 >> >> Thanks, >> StefanK From michail.chernov at oracle.com Wed Feb 11 12:55:06 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 11 Feb 2015 15:55:06 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54D3B107.9050901@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> Message-ID: <54DB512A.7070003@oracle.com> Hi, Still hoping for review! Thanks, Michail On 05.02.2015 21:05, Michail Chernov wrote: > Hi, > > Still waiting for reviews! > > Thanks, > Michail > > On 03.02.2015 20:12, Michail Chernov wrote: >> Hi, >> >> Can someone take a look on these changes, please? >> >> Thanks, >> Michail >> >> On 30.01.2015 18:33, Michail Chernov wrote: >>> Hi Leonid, >>> >>> Issues were fixed: >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>> >>> Now all testcases are executed from the same VM. >>> >>> Thanks, >>> Michail >>> >>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Why is it needed to start VM twice for each test. It is very >>>> expensive especially for low-end devices. >>>> >>>> Is it possible to have driver which starts VM several times with >>>> different combinations of options and check it output/exit code >>>> etc? Also it would be much easier to read such test. >>>> >>>> >>>> Leonid >>>> >>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>> Hi all, >>>>> >>>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>> >>>>> There is one scenario with 6 parameters combinations. >>>>> >>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>> 4,5,6 scenarios check how VM works when VM changes >>>>> DisableExplicitGC flag using WhiteBox. >>>>> >>>>> Test tries to call System.gc() and check that VM puts message to >>>>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>>>> DisableExplicitGC value and calls System.gc() twice. >>>>> >>>>> Test was executed locally on linux-i586 with all available GC and >>>>> several GC-related flags. Also it was executed using Aurora on >>>>> other platforms. >>>>> >>>>> Thanks, >>>>> Michail >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From thomas.schatzl at oracle.com Wed Feb 11 13:00:27 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 11 Feb 2015 14:00:27 +0100 Subject: Any plans to increase G1 max region size to 64m? In-Reply-To: <54DB50B2.80904@oracle.com> References: <54D381BB.2080203@oracle.com> <1423229268.3186.13.camel@oracle.com> <54D89CCC.70600@oracle.com> <1423658587.3514.13.camel@oracle.com> <54DB50B2.80904@oracle.com> Message-ID: <1423659627.3514.15.camel@oracle.com> Hi Thomas, On Wed, 2015-02-11 at 13:53 +0100, Thomas Viessmann wrote: > Thanks Thomas, > > do you want me to attach the complete gc logfile to the bug? would be nice to have. If the entire (compressed) log file is too large, just add some context before and after, maybe covering more than one occurrences of this problem. Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 11 13:01:35 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 11 Feb 2015 14:01:35 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp In-Reply-To: <54DB50C1.1040105@oracle.com> References: <54DB2384.3020403@oracle.com> <1423651789.3514.4.camel@oracle.com> <54DB50C1.1040105@oracle.com> Message-ID: <1423659695.3514.16.camel@oracle.com> Hi Stefan, On Wed, 2015-02-11 at 13:53 +0100, Stefan Karlsson wrote: > Hi Thomas, > > [...] > >> http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ > >> https://bugs.openjdk.java.net/browse/JDK-8072910 > > is it possible to fix the comment about "Closures and tasks associated > > with any self-forwarding pointers..." at the top of the hpp file? > > > > There is only one task and no closures now. > > > > Not sure if that same comment is required in the cpp file. Maybe remove > > it. > > > > Otherwise looks good. > > I've update the patch: > http://cr.openjdk.java.net/~stefank/8072910/webrev.01 > http://cr.openjdk.java.net/~stefank/8072910/webrev.01.delta Looks good. Thanks for the change. Thanks, Thomas From bengt.rutisson at oracle.com Wed Feb 11 13:15:21 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 11 Feb 2015 14:15:21 +0100 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54DB512A.7070003@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> Message-ID: <54DB55E9.2080302@oracle.com> Hi Michail, On 11/02/15 13:55, Michail Chernov wrote: > Hi, > > Still hoping for review! Sorry for being so late in looking at this. A couple of questions: Why does the test only test the parallel GC? DisableExplicitGC is valid for all GCs. What do you think about writing this test similar to other tests that validate the output from the GC logging? Here's an example: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java Thanks, Bengt > > Thanks, > Michail > > On 05.02.2015 21:05, Michail Chernov wrote: >> Hi, >> >> Still waiting for reviews! >> >> Thanks, >> Michail >> >> On 03.02.2015 20:12, Michail Chernov wrote: >>> Hi, >>> >>> Can someone take a look on these changes, please? >>> >>> Thanks, >>> Michail >>> >>> On 30.01.2015 18:33, Michail Chernov wrote: >>>> Hi Leonid, >>>> >>>> Issues were fixed: >>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>> >>>> Now all testcases are executed from the same VM. >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Why is it needed to start VM twice for each test. It is very >>>>> expensive especially for low-end devices. >>>>> >>>>> Is it possible to have driver which starts VM several times with >>>>> different combinations of options and check it output/exit code >>>>> etc? Also it would be much easier to read such test. >>>>> >>>>> >>>>> Leonid >>>>> >>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>> >>>>>> There is one scenario with 6 parameters combinations. >>>>>> >>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>> DisableExplicitGC flag using WhiteBox. >>>>>> >>>>>> Test tries to call System.gc() and check that VM puts message to >>>>>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>>>>> DisableExplicitGC value and calls System.gc() twice. >>>>>> >>>>>> Test was executed locally on linux-i586 with all available GC and >>>>>> several GC-related flags. Also it was executed using Aurora on >>>>>> other platforms. >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > From Leonid.Mesnik at oracle.com Wed Feb 11 13:31:47 2015 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 11 Feb 2015 16:31:47 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54DB512A.7070003@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> Message-ID: <54DB59C3.8030408@oracle.com> Hi Sorry for late response. I am ok with new tests. Thank you for fixing this. Please wait for a full review from Reviewer. Leonid On 11.02.2015 15:55, Michail Chernov wrote: > Hi, > > Still hoping for review! > > Thanks, > Michail > > On 05.02.2015 21:05, Michail Chernov wrote: >> Hi, >> >> Still waiting for reviews! >> >> Thanks, >> Michail >> >> On 03.02.2015 20:12, Michail Chernov wrote: >>> Hi, >>> >>> Can someone take a look on these changes, please? >>> >>> Thanks, >>> Michail >>> >>> On 30.01.2015 18:33, Michail Chernov wrote: >>>> Hi Leonid, >>>> >>>> Issues were fixed: >>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>> >>>> Now all testcases are executed from the same VM. >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Why is it needed to start VM twice for each test. It is very >>>>> expensive especially for low-end devices. >>>>> >>>>> Is it possible to have driver which starts VM several times with >>>>> different combinations of options and check it output/exit code >>>>> etc? Also it would be much easier to read such test. >>>>> >>>>> >>>>> Leonid >>>>> >>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>> >>>>>> There is one scenario with 6 parameters combinations. >>>>>> >>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>> DisableExplicitGC flag using WhiteBox. >>>>>> >>>>>> Test tries to call System.gc() and check that VM puts message to >>>>>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>>>>> DisableExplicitGC value and calls System.gc() twice. >>>>>> >>>>>> Test was executed locally on linux-i586 with all available GC and >>>>>> several GC-related flags. Also it was executed using Aurora on >>>>>> other platforms. >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > From stefan.karlsson at oracle.com Wed Feb 11 13:51:55 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Feb 2015 14:51:55 +0100 Subject: RFR: 8072910: Move the g1EvacFailure.hpp implementation to g1EvacFailure.cpp In-Reply-To: <1423659695.3514.16.camel@oracle.com> References: <54DB2384.3020403@oracle.com> <1423651789.3514.4.camel@oracle.com> <54DB50C1.1040105@oracle.com> <1423659695.3514.16.camel@oracle.com> Message-ID: <54DB5E7B.1090806@oracle.com> On 2015-02-11 14:01, Thomas Schatzl wrote: > Hi Stefan, > > On Wed, 2015-02-11 at 13:53 +0100, Stefan Karlsson wrote: >> Hi Thomas, >> >> [...] >>>> http://cr.openjdk.java.net/~stefank/8072910/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8072910 >>> is it possible to fix the comment about "Closures and tasks associated >>> with any self-forwarding pointers..." at the top of the hpp file? >>> >>> There is only one task and no closures now. >>> >>> Not sure if that same comment is required in the cpp file. Maybe remove >>> it. >>> >>> Otherwise looks good. >> I've update the patch: >> http://cr.openjdk.java.net/~stefank/8072910/webrev.01 >> http://cr.openjdk.java.net/~stefank/8072910/webrev.01.delta > Looks good. Thanks for the change. Thanks, StefanK > > Thanks, > Thomas > > From yasuenag at gmail.com Wed Feb 11 14:02:59 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 11 Feb 2015 23:02:59 +0900 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() Message-ID: <54DB6113.4080104@gmail.com> Hi all, I've committed JDK-8068589 to add new GCCause - Diagnostic Command. However, it has been backouted because test is failed [1] and it is not considered about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. I've created patch for this enhancement. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ I'm jdk9 committer, but I'm not employee at Oracle. So I need a Sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html From mikael.gerdin at oracle.com Wed Feb 11 14:08:41 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 11 Feb 2015 15:08:41 +0100 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DB2F2C.9040006@oracle.com> References: <54D4D967.7030205@oracle.com> <7DBEFE4C-54D2-4092-A58C-A1EE7B7C1B23@oracle.com> <54DB2F2C.9040006@oracle.com> Message-ID: <54DB6269.4040501@oracle.com> On 2015-02-11 11:30, Jesper Wilhelmsson wrote: > Kim Barrett skrev den 11/2/15 00:03: >> On Feb 6, 2015, at 10:10 AM, Mikael Gerdin >> wrote: >>> >>> Hi all, >>> >>> There are some problems with the Diagnostic Command GCCause change, I >>> suggest that we back out the change and reconsider its implementation. >>> >>> [from the bug] >>> The change is incomplete since several places in the GC code assumes >>> that explicit gcs have the _java_lang_system_gc GCCause value in >>> order to determine the behavior. >>> For example: >>> ParallelGC does not apply policy decisions on user-invoked GCs >>> (decided by the GCCause) >>> G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. >>> This could cause problems for people expecting concurrent gcs when >>> running the diagnostic command instead of a possibly several-second >>> full gc pause. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ >> >> A procedural question: Shouldn't this backout be accompanied by >> re-opening the original RFE (JDK-8068589) that was resolved by the >> changeset that is now being backed out? >> > > We can't reopen the old issue since it has already been used to push a > change. The procedure is to create a REDO issue by cloning the original > issue. I have done that now. Right, I was planning to do that but I forgot about it. Thanks Kim for pointing that out and Jesper for fixing it. /Mikael > > /Jesper From michail.chernov at oracle.com Wed Feb 11 15:33:59 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 11 Feb 2015 18:33:59 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54DB55E9.2080302@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> Message-ID: <54DB7667.3020107@oracle.com> Hi Bengt, Test works with all options passed to jtreg during testing ( see line 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't need to check all GC's, it will be done during nightly. 44 public final static String[] PARALLEL_GC_OPTIONS = {"UseParallelGC", "UseParallelOldGC"}; Here is defined special options. If define one of these options - will be used other pattern to match output. But it seems to me a little bit wrong. I've checked output of GC log with different GCs and ExplicitGCInvokesConcurrent. Message "Full GC (System.gc())" does not appear only in case of using G1 or CMS with ExplicitGCInvokesConcurrent=true. Will fix it. Thanks, Michail On 11.02.2015 16:15, Bengt Rutisson wrote: > > Hi Michail, > > On 11/02/15 13:55, Michail Chernov wrote: >> Hi, >> >> Still hoping for review! > > Sorry for being so late in looking at this. > > A couple of questions: > > Why does the test only test the parallel GC? DisableExplicitGC is > valid for all GCs. > > What do you think about writing this test similar to other tests that > validate the output from the GC logging? Here's an example: > > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java > > > Thanks, > Bengt > >> >> Thanks, >> Michail >> >> On 05.02.2015 21:05, Michail Chernov wrote: >>> Hi, >>> >>> Still waiting for reviews! >>> >>> Thanks, >>> Michail >>> >>> On 03.02.2015 20:12, Michail Chernov wrote: >>>> Hi, >>>> >>>> Can someone take a look on these changes, please? >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>> Hi Leonid, >>>>> >>>>> Issues were fixed: >>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>> >>>>> Now all testcases are executed from the same VM. >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Why is it needed to start VM twice for each test. It is very >>>>>> expensive especially for low-end devices. >>>>>> >>>>>> Is it possible to have driver which starts VM several times with >>>>>> different combinations of options and check it output/exit code >>>>>> etc? Also it would be much easier to read such test. >>>>>> >>>>>> >>>>>> Leonid >>>>>> >>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>> >>>>>>> There is one scenario with 6 parameters combinations. >>>>>>> >>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>> >>>>>>> Test tries to call System.gc() and check that VM puts message to >>>>>>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>>>>>> DisableExplicitGC value and calls System.gc() twice. >>>>>>> >>>>>>> Test was executed locally on linux-i586 with all available GC >>>>>>> and several GC-related flags. Also it was executed using Aurora >>>>>>> on other platforms. >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > > From jesper.wilhelmsson at oracle.com Wed Feb 11 17:08:38 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Feb 2015 18:08:38 +0100 Subject: RFR (S) 8072693: [BACKOUT] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DB6269.4040501@oracle.com> References: <54D4D967.7030205@oracle.com> <7DBEFE4C-54D2-4092-A58C-A1EE7B7C1B23@oracle.com> <54DB2F2C.9040006@oracle.com> <54DB6269.4040501@oracle.com> Message-ID: <54DB8C96.5030603@oracle.com> Mikael Gerdin skrev den 11/2/15 15:08: > > > On 2015-02-11 11:30, Jesper Wilhelmsson wrote: >> Kim Barrett skrev den 11/2/15 00:03: >>> On Feb 6, 2015, at 10:10 AM, Mikael Gerdin >>> wrote: >>>> >>>> Hi all, >>>> >>>> There are some problems with the Diagnostic Command GCCause change, I >>>> suggest that we back out the change and reconsider its implementation. >>>> >>>> [from the bug] >>>> The change is incomplete since several places in the GC code assumes >>>> that explicit gcs have the _java_lang_system_gc GCCause value in >>>> order to determine the behavior. >>>> For example: >>>> ParallelGC does not apply policy decisions on user-invoked GCs >>>> (decided by the GCCause) >>>> G1/CMS honors +ExplicitGCInvokesConcurrent based on the GCCause setting. >>>> This could cause problems for people expecting concurrent gcs when >>>> running the diagnostic command instead of a possibly several-second >>>> full gc pause. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072693 >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8072693/webrev.0/ >>> >>> A procedural question: Shouldn't this backout be accompanied by >>> re-opening the original RFE (JDK-8068589) that was resolved by the >>> changeset that is now being backed out? >>> >> >> We can't reopen the old issue since it has already been used to push a >> change. The procedure is to create a REDO issue by cloning the original >> issue. I have done that now. > > Right, I was planning to do that but I forgot about it. Thanks Kim for pointing > that out and Jesper for fixing it. No problem, that's part of the gatekeeping duties :) Another thing we should remember the next time this happens is that if the change has already been promoted to jdk9/hs, the backout should be done directly in jdk9/hs to enable other teams to benefit from the backout asap. I should have mentioned that when we talked about this before you did the backout. My fault. /Jesper > > /Mikael > >> >> /Jesper From kim.barrett at oracle.com Wed Feb 11 18:21:42 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Feb 2015 13:21:42 -0500 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54DB287B.7080305@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> <54DB287B.7080305@oracle.com> Message-ID: <2ADA664E-D4C2-4BDC-AAFD-8A17DD3F84EE@oracle.com> On Feb 11, 2015, at 5:01 AM, Jesper Wilhelmsson wrote: > > Kim Barrett skrev den 10/2/15 23:56: >> On Feb 10, 2015, at 3:38 PM, Jesper Wilhelmsson wrote: >>> >>> Hi Kim, >>> >>> Thanks for taking another close look at this change! >>> >>> Some of these issues are the result of this being a part of a bigger change, but I have addressed your concerns to make sure this intermediate version is of decent quality even without the following cleanups. (Even though I hope we will get the rest in asap. Those will be a lot easier to review). >>> >>> For example anything related to levels and _n_gens will be removed in later patches when the entire level concept is removed. >> >> That?s what I thought, but I would prefer having this changeset be able to stand on its own merits. I think the further changes will be easier to understand with the additional (usually temporary) asserts and such, especially for anyone who didn?t review this changeset. >> >>> A new webrev is available here: >>> http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.02/ >> >> This webrev seems to be broken - genCollectedHeap.cpp frame display is messed up. Old version is showing as empty, although new version still highlights differences. I didn?t look at it carefully though, since I?m not sure I?d be looking at anything like the intended code. > > Yes. Apparently awk (on Mac?) has a hard coded limitation of 50 patterns, so webrev fails to process large files... I have installed gawk now and built a new webrev to replace the old one. (same link) Bleh. That must have been fun to track down. Changes look good. From jon.masamitsu at oracle.com Wed Feb 11 23:34:31 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 11 Feb 2015 15:34:31 -0800 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> Message-ID: <54DBE707.4020401@oracle.com> Goetz, Could you have used page alignment to determine the new expected sizes? For example, instead of 987 // Calculate what we expect the flag to be. 988 flag_value = adapted_InitialHeapSize - MaxNewSize; 989 verify_old_initial(flag_value); expected_old_initial = align_size_up(flag_value, os::vm_page_size()) verify_old_initial(expected_old_initial) Jon On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: > > Hi, > > could someone please have a look at this change? > > It's really not that big. > > GC-folks maybe? > > Thanks, > > Goetz. > > *From:*Lindenmaier, Goetz > *Sent:* Freitag, 30. Januar 2015 10:36 > *To:* hotspot-dev Source Developers > *Subject:* RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal > tests to support 64K pages > > Hi, > > this fixes a final problem with 64-bit page size in the jtreg tests. > > It addresses the internal VM tests of the collector policies. > > Those tests set a row of fixed flag values, and one special value to > test. > > Then they call the heap ergonomics and check the expected result of the > > special value. > > With 64K page size, the heap ergonomics adapt more values, breaking > the tests. > > Wrt. the adapted flag values the tests are correct though. > > This change makes the expected values depend on the adapted flags, and > the > > tests pass. They only depend on adapted flags that are not subject of the > > corresponding test. > > Please review this test. I please need a sponsor.__ > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8071822 > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.x.zakharov at oracle.com Thu Feb 12 14:00:58 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 12 Feb 2015 17:00:58 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before Message-ID: <54DCB21A.2000203@oracle.com> Hello. Summary: test for auxiliary data in G1 fails as they cannot precisely measure this aux data size. I've added whitebox method to get this size. I've on little question about placement of helper method "sum_memory_usage", which currently placed in gc_implementation/g1/heapRegionManager.hpp but it doesn't logically related to HeapManager itself. If you can advice me where its best place it will be wonderful. webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev/ bug: JDK-8061715 gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before Testing done in Stockholm's JPRT (2015-02-12-112315.azakharov.hs-gc) all is fine. Thanks. From bengt.rutisson at oracle.com Thu Feb 12 14:07:18 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Feb 2015 15:07:18 +0100 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54DB7667.3020107@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> Message-ID: <54DCB396.2080807@oracle.com> Hi Michail, On 11/02/15 16:33, Michail Chernov wrote: > Hi Bengt, > > Test works with all options passed to jtreg during testing ( see line > 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't need to > check all GC's, it will be done during nightly. Ah. I see that now. > > 44 public final static String[] PARALLEL_GC_OPTIONS = > {"UseParallelGC", "UseParallelOldGC"}; > Here is defined special options. If define one of these options - will > be used other pattern to match output. Right. > > But it seems to me a little bit wrong. I've checked output of GC log > with different GCs and ExplicitGCInvokesConcurrent. Message "Full GC > (System.gc())" does not appear only in case of using G1 or CMS with > ExplicitGCInvokesConcurrent=true. Will fix it. OK. My main point was that I think the whole structure of the test is different than how we usually write tests that verify the log output. I would prefer if the tests look similar. Would you mind re-writing the test to look like the other tests. I much prefer that you explicitly start with the GCs you want to test than that you use the WhiteBox API to find out which GC you are running. I'm having a similar discussion with Dima who recently invented yet another way to parse the GC log output from tests. I think it gets very hard to read the tests when they do the same thing in different ways. Thanks, Bengt > > Thanks, > Michail > On 11.02.2015 16:15, Bengt Rutisson wrote: >> >> Hi Michail, >> >> On 11/02/15 13:55, Michail Chernov wrote: >>> Hi, >>> >>> Still hoping for review! >> >> Sorry for being so late in looking at this. >> >> A couple of questions: >> >> Why does the test only test the parallel GC? DisableExplicitGC is >> valid for all GCs. >> >> What do you think about writing this test similar to other tests that >> validate the output from the GC logging? Here's an example: >> >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >> >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Michail >>> >>> On 05.02.2015 21:05, Michail Chernov wrote: >>>> Hi, >>>> >>>> Still waiting for reviews! >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>> Hi, >>>>> >>>>> Can someone take a look on these changes, please? >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> Issues were fixed: >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>> >>>>>> Now all testcases are executed from the same VM. >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>>> >>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Why is it needed to start VM twice for each test. It is very >>>>>>> expensive especially for low-end devices. >>>>>>> >>>>>>> Is it possible to have driver which starts VM several times with >>>>>>> different combinations of options and check it output/exit code >>>>>>> etc? Also it would be much easier to read such test. >>>>>>> >>>>>>> >>>>>>> Leonid >>>>>>> >>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>> >>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>> >>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>> >>>>>>>> Test tries to call System.gc() and check that VM puts message >>>>>>>> to stdout. After (in case of 4,5,6 scenarios) test tries to >>>>>>>> change DisableExplicitGC value and calls System.gc() twice. >>>>>>>> >>>>>>>> Test was executed locally on linux-i586 with all available GC >>>>>>>> and several GC-related flags. Also it was executed using Aurora >>>>>>>> on other platforms. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michail >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > From tom.benson at oracle.com Thu Feb 12 20:14:10 2015 From: tom.benson at oracle.com (Tom Benson) Date: Thu, 12 Feb 2015 15:14:10 -0500 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold Message-ID: <54DD0992.8010308@oracle.com> Hi, I need reviewers and a commit sponsor for changes for bug 6764713, which will increase the size of the age field in an object header from 4 bits to 5. This will allow a maximum MaxTenuringThreshold of 31, though the default will remain at the current value of 15. This includes the same change to the 32-bit version, which would close bug 6719225 as well. In that case, the hash field in the header is affected, losing one bit (25 bits -> 24), so I have asked for review from hotspot-runtime-dev as well as gc-dev. Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 Testing: JPRT and reference server performance tests Notes: Contrary to what earlier notes in the JBS entry said, this does not require stronger alignment for the JavaThread structure for when biased locking stores that pointer in the header. The JavaThread* was already being aligned 1 power of 2 more strongly than it needed to be, so there was an unused bit that could be stolen. In the 32-bit version, it does require taking one bit from the hash field, which goes from 25 to 24 bits. This is something I'd especially like feedback on. Running reference server performance tests, I saw no impact from this change. We *could* make this change 64-bit-only, and leave the age field at 4 bits for the 32-bit version. If we did so, we could also decrease the alignment required for the JavaThread* to 512 from the current 1024. The comment changes imply that the bits available for the JavaThread* have been reduced by 1, and that the alignment is now stronger, but neither is true. The comments have been corrected to match the alignment that was already enforced. Three tests needed to be corrected to match the new limits. These check the maximum valid values, what value represents NeverTenure, and so on. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Feb 13 02:54:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Feb 2015 12:54:55 +1000 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DD0992.8010308@oracle.com> References: <54DD0992.8010308@oracle.com> Message-ID: <54DD677F.10101@oracle.com> Hi Tom, If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most! The rest seems okay but I'm still mulling over it. :) Thanks, David H. On 13/02/2015 6:14 AM, Tom Benson wrote: > Hi, > I need reviewers and a commit sponsor for changes for bug 6764713, which > will increase the size of the age field in an object header from 4 bits > to 5. This will allow a maximum MaxTenuringThreshold of 31, though the > default will remain at the current value of 15. > > This includes the same change to the 32-bit version, which would close > bug 6719225 as well. In that case, the hash field in the header is > affected, losing one bit (25 bits -> 24), so I have asked for review > from hotspot-runtime-dev as well as gc-dev. > > Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 > Testing: JPRT and reference server performance tests > > Notes: > Contrary to what earlier notes in the JBS entry said, this does not > require stronger alignment for the JavaThread structure for when biased > locking stores that pointer in the header. The JavaThread* was already > being aligned 1 power of 2 more strongly than it needed to be, so there > was an unused bit that could be stolen. > > In the 32-bit version, it does require taking one bit from the hash > field, which goes from 25 to 24 bits. This is something I'd especially > like feedback on. Running reference server performance tests, I saw no > impact from this change. We *could* make this change 64-bit-only, and > leave the age field at 4 bits for the 32-bit version. If we did so, we > could also decrease the alignment required for the JavaThread* to 512 > from the current 1024. > > The comment changes imply that the bits available for the JavaThread* > have been reduced by 1, and that the alignment is now stronger, but > neither is true. The comments have been corrected to match the > alignment that was already enforced. > > Three tests needed to be corrected to match the new limits. These check > the maximum valid values, what value represents NeverTenure, and so on. > > Thanks, > Tom > From sangheon.kim at oracle.com Fri Feb 13 06:54:24 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Thu, 12 Feb 2015 22:54:24 -0800 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages Message-ID: <54DD9FA0.2000107@oracle.com> Hi All, Please review this small enhancement for better error messages when assert fails. This change would be helpful forJDK-8071930 which is hard to reproduce. I will need a sponsor for this change. CR: https://bugs.openjdk.java.net/browse/JDK-8073115 Webrev: http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ Testing: JPRT Thanks, Sangheon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Fri Feb 13 07:38:58 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 13 Feb 2015 08:38:58 +0100 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DD9FA0.2000107@oracle.com> References: <54DD9FA0.2000107@oracle.com> Message-ID: <54DDAA12.8010506@oracle.com> Hi Sangheon, Looks good! Thanks for enhancing the asserts, this is something the Hotspot code is in great need of. I'll be happy to sponsor this change. /Jesper Sangheon Kim skrev den 13/2/15 07:54: > Hi All, > > Please review this small enhancement for better error messages when assert fails. > This change would be helpful forJDK-8071930 which is hard to reproduce. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073115 > > Webrev: > http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ > > Testing: > JPRT > > Thanks, > Sangheon > From bengt.rutisson at oracle.com Fri Feb 13 08:12:43 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 13 Feb 2015 09:12:43 +0100 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DD9FA0.2000107@oracle.com> References: <54DD9FA0.2000107@oracle.com> Message-ID: <54DDB1FB.6020609@oracle.com> Hi Sangheon, On 13/02/15 07:54, Sangheon Kim wrote: > Hi All, > > Please review this small enhancement for better error messages when assert fails. > This change would be helpful forJDK-8071930 which is hard to reproduce. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073115 > > Webrev: > http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ Looks good. Thanks, Bengt > > Testing: > JPRT > > Thanks, > Sangheon -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Fri Feb 13 09:07:00 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Feb 2015 10:07:00 +0100 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DD9FA0.2000107@oracle.com> References: <54DD9FA0.2000107@oracle.com> Message-ID: <54DDBEB4.2000909@oracle.com> Hi Sangheon, On 2015-02-13 07:54, Sangheon Kim wrote: > Hi All, > > Please review this small enhancement for better error messages when assert fails. > This change would be helpful forJDK-8071930 which is hard to reproduce. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073115 > > Webrev: > http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html You are duplicating the same assert three times. Could you create a new define, say #define assert_covered_region_contains(addr) ..., and remove the duplication? This will also have the benefit of lowering the line noise in the functions you change. Thanks, StefanK > > Testing: > JPRT > > Thanks, > Sangheon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Fri Feb 13 09:33:38 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 13 Feb 2015 15:03:38 +0530 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DD0992.8010308@oracle.com> References: <54DD0992.8010308@oracle.com> Message-ID: Hi Tom, Perhaps you misunderstood the comments in the jira (although my memory is foggy now, so many years later): the comments (and the diffs), IIRC, stated that the age bits can go up to 6 (in the 64-bit jvm) without changing the JavaThread* alignment (which may or may not have been different at the time the comments were written). And that any larger number of bits for age would require wider alignment. As you stated for the 32-bit case, yes, you'd be forced to steal a bit from somewhere. I am traveling at the moment with very limited internet access, so haven't looked at yr diffs, although I might have better connectivity next week. -- ramki On Fri, Feb 13, 2015 at 1:44 AM, Tom Benson wrote: > Hi, > I need reviewers and a commit sponsor for changes for bug 6764713, which > will increase the size of the age field in an object header from 4 bits to > 5. This will allow a maximum MaxTenuringThreshold of 31, though the default > will remain at the current value of 15. > > This includes the same change to the 32-bit version, which would close bug > 6719225 as well. In that case, the hash field in the header is affected, > losing one bit (25 bits -> 24), so I have asked for review from > hotspot-runtime-dev as well as gc-dev. > > Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 > Testing: JPRT and reference server performance tests > > Notes: > Contrary to what earlier notes in the JBS entry said, this does not > require stronger alignment for the JavaThread structure for when biased > locking stores that pointer in the header. The JavaThread* was already > being aligned 1 power of 2 more strongly than it needed to be, so there was > an unused bit that could be stolen. > > In the 32-bit version, it does require taking one bit from the hash field, > which goes from 25 to 24 bits. This is something I'd especially like > feedback on. Running reference server performance tests, I saw no impact > from this change. We *could* make this change 64-bit-only, and leave the > age field at 4 bits for the 32-bit version. If we did so, we could also > decrease the alignment required for the JavaThread* to 512 from the current > 1024. > > The comment changes imply that the bits available for the JavaThread* have > been reduced by 1, and that the alignment is now stronger, but neither is > true. The comments have been corrected to match the alignment that was > already enforced. > > Three tests needed to be corrected to match the new limits. These check > the maximum valid values, what value represents NeverTenure, and so on. > > Thanks, > Tom > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.x.zakharov at oracle.com Fri Feb 13 12:24:18 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Fri, 13 Feb 2015 15:24:18 +0300 Subject: [RFR] 8016752: Test case for 8005857/8016740 (assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose) In-Reply-To: <54635670.2070909@oracle.com> References: <54476AD3.3050907@oracle.com> <1415094901.5218.5.camel@oracle.com> <5460952D.4070101@oracle.com> <54633D85.5060006@oracle.com> <54635670.2070909@oracle.com> Message-ID: <54DDECF2.1050504@oracle.com> Hi, as we now have stable "~=" support in @requires tag of jtreg I've updated patch. Added check for GC = parallel too. Please review it. Thanks. webrev: http://cr.openjdk.java.net/~azakharov/8016752/webrev.03/ testbug: https://bugs.openjdk.java.net/browse/JDK-8016752 12.11.2014 15:45, Dmitry Fazunenko ?????: > Hi Andrey, > > I think it's too early to rely on '~=' in @requires. There is no > guarantee that it will be supported. (I hope it will). > > You also need to add @requires and list GC the test will work with. > > Thanks, > Dima > > > On 12.11.2014 14:59, Andrey Zakharov wrote: >> Hi, team >> As this test requires fastdebug build, here is update according to >> latest changes to jtreg (@requires tag). >> Also I've suggested patch to jtreg for support matching against >> regexp patterns in @requires expressions (like "foo bar" ~= ".*bar") >> *(its blocker for original tesbug now) >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8016752/webrev.02/ >> >> testbug: >> https://bugs.openjdk.java.net/browse/JDK-8016752 >> >> Thanks. >> >> On 10.11.2014 14:36, Andrey Zakharov wrote: >>> Hi, Thomas >>> Yes, its fails very stable on 7u40b31 >>> # Internal Error >>> (/HUDSON/workspace/jdk7u40-2-build-linux-amd64-product/jdk7u40/hotspot/src/share/vm/memory/gcLocker.hpp:94), >>> pid=15099, tid=139928946063104 >>> # assert(_needs_gc || SafepointSynchronize::is_at_safepoint()) >>> failed: only read at safepoint >>> >>> with elapsed time (seconds): 1.273 >>> on local linux x64 box. >>> And passed on b32. >>> >>> Also, there are batches in comments of bugs for builds before fix >>> and with fix. >>> >>> >>> On 04.11.2014 13:55, Thomas Schatzl wrote: >>>> Hi Andrey, >>>> >>>> On Wed, 2014-10-22 at 12:29 +0400, Andrey Zakharov wrote: >>>>> Hi, team. >>>>> Here is simple test for JVM don't crash when its with PSOldGen, low >>>>> memory and with -XX:+PrintGCDetails and -XX:+Verbose flags >>>>> (https://bugs.openjdk.java.net/browse/JDK-8016740) based on Crasher >>>>> attached to original incident bug >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~azakharov/8016752/webrev/ >>>> The test looks okay, but did you check that if you revert JDK-8016740, >>>> the test actually fails? >>>> The original reproducer was stressing the GC a lot more as it tried to >>>> cause crashes for 60 seconds. >>>> >>>> If that is the case, it looks okay to me. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> > From mikael.gerdin at oracle.com Fri Feb 13 12:33:36 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 13 Feb 2015 13:33:36 +0100 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DB6113.4080104@gmail.com> References: <54DB6113.4080104@gmail.com> Message-ID: <54DDEF20.6010501@oracle.com> Hi Yasumasa, On 2015-02-11 15:02, Yasumasa Suenaga wrote: > Hi all, > > I've committed JDK-8068589 to add new GCCause - Diagnostic Command. > However, it has been backouted because test is failed [1] and it is not considered > about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. > > I've created patch for this enhancement. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run Given that the documentation of the GC.run command is: "GC.run Call java.lang.System.gc(). Impact: Medium: Depends on Java heap size and content. Syntax: GC.run" I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. /Mikael > > > I'm jdk9 committer, but I'm not employee at Oracle. > So I need a Sponsor. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html > From mikael.gerdin at oracle.com Fri Feb 13 12:58:32 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 13 Feb 2015 13:58:32 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54DA6C42.7060209@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> Message-ID: <54DDF4F8.2080508@oracle.com> Hi Jesper, On 2015-02-10 21:38, Jesper Wilhelmsson wrote: > Hi Kim, > > Thanks for taking another close look at this change! > > Some of these issues are the result of this being a part of a bigger > change, but I have addressed your concerns to make sure this > intermediate version is of decent quality even without the following > cleanups. (Even though I hope we will get the rest in asap. Those will > be a lot easier to review). > > For example anything related to levels and _n_gens will be removed in > later patches when the entire level concept is removed. > > A new webrev is available here: > http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.02/ Overall I think this is a good incremental cleanup. I have some requests to make it easier to reason about the code though: if (!(max_level == 1 && full && _old_gen->full_collects_younger_generations()) && _young_gen->should_collect(full, size, is_tlab)) is a bit of a mouthful, can you please break out parts of it into a boolean? bool old_collects_young = (max_level == 1 && full && _old_gen->full_collects_younger_generations()) if (old_collects_young && _young_gen->should_collect...) The must_restore_marks_for_biased_locking is even more confusing. Its initial value is "false", DefNew returns false for performs_in_place_marking() so the if block there is essentially dead code. For the old generation you pass !must_restore_marks.. to collect_generation in order to trigger the preserving of marks if it was not performed completed by the young gc but it's then immediately set to true after the call to collect_generation in order to get the code to properly restore the marks. I suggest that you assert that young gens always return false for performs_in_place_marking() and either pass literal "true" or "false" to collect_generation, or perhaps even call BiasedLocking::preserve_marks() before calling collect_generation for old gen and just get rid of the parameter. You would still need to keep the boolean variable in order to know if you should restore the marks, but that's fine I think. /Mikael > > Some replies inline. > > > Kim Barrett skrev den 9/2/15 21:05: >> On Jan 29, 2015, at 5:45 AM, Jesper Wilhelmsson >> wrote: >>> >>> Hi, >>> >>> Please review this second attempt to remove the generations array. >>> >>> There were two bugs that caused this patch to be backed out the last >>> time: >>> >>> 1. Collection of the old generation was always run even if the young >>> collection freed up enough to satisfy the allocation need. This was >>> due to an unexpected use of the size variable and stopped working >>> when the code that changed the variable was broken out into a >>> separate function. >>> >>> 2. The new _young_generation and _old_generation fields was missing >>> from the declarations in vm_structs.cpp. Cut'n'paste error when the >>> original huge change was split into smaller parts for easier review. >>> >>> I have resolved these issues. I also moved the >>> BiasedLocking::preserve_marks() since the previous change didn't >>> preserve exactly the same behavior. And I added a comment in a test >>> that caused some issues when I was debugging this. >>> >>> Testing: AdHoc run of the nightly GC tests, JPRT, and JTREG >>> >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8061802 >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01/ >>> >>> I also made an incremental webrev based on the old patch applied to a >>> fresh version of the GC repo. Please note that the old patch do not >>> apply cleanly to a current GC repo, but the changes in the >>> incremental diff should cover what has been changed with regards to >>> this RFE. Please refer to the full webrevs if in doubt. >>> >>> Incremental webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01.incremental/ >>> >>> Old (buggy) webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8055702/webrev.01/ >>> >>> >>> For reference, as I mentioned above the original huge change was >>> split into several smaller parts. This is the first of those parts. >>> The other can be found here: >>> >>> http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.01/ >>> >>> Please note that these are the old patches that applies on top of the >>> old (buggy) patch above. They will not apply cleanly on top of the >>> new patch. I'll update these once the first part is finalized. >>> >>> Thanks, >>> /Jesper >> >> ------------------------------------------------------------------------------ >> >> Throughout, copyrights need to be updated. >> >> ------------------------------------------------------------------------------ >> >> agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java >> 71 public Generation getGen(int i) { >> 72 if (Assert.ASSERTS_ENABLED) { >> 73 Assert.that((i >= 0) && (i < nGens()), "Index " + i + >> 74 " out of range (should be between 0 and " + >> nGens() + ")"); >> 75 } >> 76 >> 77 switch (i) { >> 78 case 0: >> 79 return genFactory.newObject(youngGenField.getAddress()); >> 80 case 1: >> 81 return genFactory.newObject(oldGenField.getAddress()); >> 82 default: >> 83 // no generation for i, and assertions disabled. >> 84 return null; >> 85 } >> 86 } >> >> With the replacement of the old code with the switch statement, the >> assertion seems both poorly placed and not entirely sufficient. The >> code is now assuming that nGens() == 2, for example. > > I updated the assertion and removed the usage of nGens() in this method. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> 131 ReservedSpace young_rs = >> heap_rs.first_part(_gen_specs[0]->max_size(), false, false); >> 132 _young_gen = _gen_specs[0]->init(young_rs, 0, rem_set()); >> 133 heap_rs = heap_rs.last_part(_gen_specs[0]->max_size()); >> 134 >> 135 ReservedSpace old_rs = >> heap_rs.first_part(_gen_specs[1]->max_size(), false, false); >> 136 _old_gen = _gen_specs[1]->init(old_rs, 1, rem_set()); >> 137 heap_rs = heap_rs.last_part(_gen_specs[1]->max_size()); >> >> I feel like there should be an assertion somewhere before here that >> _n_gens == 2. >> >> Also, I think line 137 is unnecessary. > > Assertion added and line removed. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> 216 void GenCollectedHeap::save_used_regions(int level) { >> 217 assert(level < _n_gens, "Illegal level parameter"); >> 218 if (level == 1) { >> 219 _old_gen->save_used_region(); >> 220 } >> 221 _young_gen->save_used_region(); >> 222 } >> >> Assumes level >= 0. Old code would do nothing with negative level. >> Probably negative level is a bug, and should be asserted against. > > Assertion added. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> collect_generation and do_collection >> >> I tried to give the changes here a thorough look, but the diffs are >> very messy. I hope I didn't miss anything. >> >> I think the review of this would have been noticably easier if the >> extraction of collect_generation into a separate function had happened >> before and independently of the generation array changes. Oh well. > > That may be true, even though I believe that the only major difference > if this would have been done separately would be that the call sites > would use get_gen(0/1) instead of young/old_gen. This is clearly the > most difficult part of removing the generation array and also this is > where we saw a few bugs in the last version. According to our tests it > should be fine now. :) > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> 574 void GenCollectedHeap:: >> 575 gen_process_roots(int level, >> >> I think the proposed changes maintain the previous behavior, as >> desired. However ... >> >> This is probably something for a future (but soon, I hope) cleanup. >> >> GenCollectedHeap::gen_process_roots() is a bit of a mess now. It first >> calls SharedHeap::process_roots. It then does completely different >> things, depending on the value of the first (level) argument. That's >> not at all obvious from the way the code is written though. Retaining >> the structure from the old iteration through _gens[] is not helpful in >> the new world where we have exactly two generations. >> >> (I was surprised to note that the old code seems to do nothing for >> _gens[level]. I wonder if that was a lurking bug?) >> >> There are two overloads for gen_process_roots(). The first does most >> of the work. The second constructs an additional closure and calls >> the first with that closure plus some other argument adjustments. I >> think all client callers call the second; the first could be hoisted >> into the second and eliminated as a separate function. >> >> I also suspect that, with some careful analysis, we could determine >> the level value for all callers. This and the fact that this function >> does very different things according to the level suggests splitting >> this function into two distinct functions. >> >> Here's what I came up with for the level values being provided: >> >> - MarkSweep always calls with level == 1 (assertion) >> - CMS always calls with level == _cmsGen->level() >> presumably _cmsGen->level() is 1, since _cmsGen is old_gen? >> - ParNewGeneration::work calls with level == _gen->level() >> _gen is the young generation, so level is always 0 here? >> - DefNewGeneration::collect calls with level == _level >> _level is 0, since this is young generation? >> >> The two callers apparently providing 0 as the level also always >> provide true as the second (younger_gens_as_roots) argument. I >> suspect there are other argument simplifications that would result >> from splitting. >> >> I'm ok with the proposed change as is, as part of that change set. >> But please make sure there's a follow-on cleanup RFE. > > I absolutely agree and I assume there are other simplifications and > cleanups that will be apparent once the rest of the cleanups goes in as > well. I copied your description above into an RFE to handle this issue. > > https://bugs.openjdk.java.net/browse/JDK-8072809 > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> 837 // This might be sped up with a cache of the last generation that >> 838 // answered yes. >> 839 if (_young_gen->is_in(p) || _old_gen->is_in(p)) { >> 840 return true; >> 841 } >> 842 // Otherwise... >> 843 return false; >> >> The comment on line 837 seems mostly relevant to the old code that >> iterated through the generations array. Is it still relevant? >> Especially since it seems to bottom out in Space::is_in(), which is >> documented as being potentially slow and so only to be used in assert. >> >> Also, with only the two generations now, I'd probably write this as >> >> return _young_gen->is_in(p) || _old_gen->is_in(p); > > Agreed. Fixed. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> 1046 void GenCollectedHeap::prepare_for_compaction() { >> 1047 guarantee(_n_gens = 2, "Wrong number of generations"); >> 1048 Generation* old_gen = _old_gen; >> 1049 // Start by compacting into same gen. >> 1050 CompactPoint cp(old_gen); >> 1051 old_gen->prepare_for_compaction(&cp); >> 1052 Generation* young_gen = _young_gen; >> 1053 young_gen->prepare_for_compaction(&cp); >> 1054 } >> >> The old_gen and young_gen local variables just add clutter after the >> rewrite. > > Agreed. This was taken care of in one of the later cleanups but I moved > that cleanup into this patch. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.hpp >> 387 Generation* get_gen(int i) const { >> 388 guarantee(i >= 0 && i < _n_gens, "Out of bounds"); >> 389 if (i == 0) { >> 390 return _young_gen; >> 391 } else { >> 392 return _old_gen; >> 393 } >> 394 } >> >> The assertion here now ought to be (level == 0 || level == 1). And >> _n_gens must be 2. > > Assert fixed. > >> >> ------------------------------------------------------------------------------ >> >> > > Thank you! > /Jesper From karen.kinnear at oracle.com Fri Feb 13 14:42:06 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 13 Feb 2015 09:42:06 -0500 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DD677F.10101@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> Message-ID: <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently. In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark immutable objects or value types (yes, today those don't have an identity hash but I am not yet convinced that we won't have a design where we need to distinguish reference objects from value types underneath a common object header for jdk10). So - hmmm. thanks, Karen On Feb 12, 2015, at 9:54 PM, David Holmes wrote: > Hi Tom, > > If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most! > > The rest seems okay but I'm still mulling over it. :) > > Thanks, > David H. > > On 13/02/2015 6:14 AM, Tom Benson wrote: >> Hi, >> I need reviewers and a commit sponsor for changes for bug 6764713, which >> will increase the size of the age field in an object header from 4 bits >> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >> default will remain at the current value of 15. >> >> This includes the same change to the 32-bit version, which would close >> bug 6719225 as well. In that case, the hash field in the header is >> affected, losing one bit (25 bits -> 24), so I have asked for review >> from hotspot-runtime-dev as well as gc-dev. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >> Testing: JPRT and reference server performance tests >> >> Notes: >> Contrary to what earlier notes in the JBS entry said, this does not >> require stronger alignment for the JavaThread structure for when biased >> locking stores that pointer in the header. The JavaThread* was already >> being aligned 1 power of 2 more strongly than it needed to be, so there >> was an unused bit that could be stolen. >> >> In the 32-bit version, it does require taking one bit from the hash >> field, which goes from 25 to 24 bits. This is something I'd especially >> like feedback on. Running reference server performance tests, I saw no >> impact from this change. We *could* make this change 64-bit-only, and >> leave the age field at 4 bits for the 32-bit version. If we did so, we >> could also decrease the alignment required for the JavaThread* to 512 >> from the current 1024. >> >> The comment changes imply that the bits available for the JavaThread* >> have been reduced by 1, and that the alignment is now stronger, but >> neither is true. The comments have been corrected to match the >> alignment that was already enforced. >> >> Three tests needed to be corrected to match the new limits. These check >> the maximum valid values, what value represents NeverTenure, and so on. >> >> Thanks, >> Tom >> From sergei.kovalev at oracle.com Fri Feb 13 15:15:23 2015 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 13 Feb 2015 18:15:23 +0300 Subject: RFR(S): 8067162: runtime/SharedArchiveFile tests fail on compact profiles Message-ID: <54DE150B.10206@oracle.com> Hello All, Please review the fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8067162 Webrev: http://cr.openjdk.java.net/~skovalev/8067162/webrew.00/ Synopsis: Test failed on compact profiles with message: Exception in thread "main" java.lang.RuntimeException: Utilization for one of the regions is below a threshold of 30% Having no GUI classes we cannot utilize enough part of region. Solution: Solution: exclude tests from execution on compact profiles. Modified TEST.group file. Tests added to group: needs_jre. Tested locally with showGroups jtreg mechanism. -- With best regards, Sergei From tom.benson at oracle.com Fri Feb 13 15:37:58 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 13 Feb 2015 10:37:58 -0500 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> Message-ID: <54DE1A56.9080008@oracle.com> Hi, Based on comments here and elsewhere on possible future uses for this unused bit (in the 64-bit version), I'm more inclined to close both 6764713 and 6719225 with no change. With a comment along the lines of "evolution of the JVM since the time the age field was reduced has revealed potentially more valuable uses of the bit." However, if there are supporters of a larger MaxTenuringThreshold lurking, I'd like to hear their point of view as well. Thanks, Tom On 2/13/2015 9:42 AM, Karen Kinnear wrote: > Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently. > > In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am > not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark > immutable objects or value types (yes, today those don't have an identity hash but I am not yet convinced that we won't have > a design where we need to distinguish reference objects from value types underneath a common object header for jdk10). > > So - hmmm. > > thanks, > Karen > > On Feb 12, 2015, at 9:54 PM, David Holmes wrote: > >> Hi Tom, >> >> If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most! >> >> The rest seems okay but I'm still mulling over it. :) >> >> Thanks, >> David H. >> >> On 13/02/2015 6:14 AM, Tom Benson wrote: >>> Hi, >>> I need reviewers and a commit sponsor for changes for bug 6764713, which >>> will increase the size of the age field in an object header from 4 bits >>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >>> default will remain at the current value of 15. >>> >>> This includes the same change to the 32-bit version, which would close >>> bug 6719225 as well. In that case, the hash field in the header is >>> affected, losing one bit (25 bits -> 24), so I have asked for review >>> from hotspot-runtime-dev as well as gc-dev. >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >>> Testing: JPRT and reference server performance tests >>> >>> Notes: >>> Contrary to what earlier notes in the JBS entry said, this does not >>> require stronger alignment for the JavaThread structure for when biased >>> locking stores that pointer in the header. The JavaThread* was already >>> being aligned 1 power of 2 more strongly than it needed to be, so there >>> was an unused bit that could be stolen. >>> >>> In the 32-bit version, it does require taking one bit from the hash >>> field, which goes from 25 to 24 bits. This is something I'd especially >>> like feedback on. Running reference server performance tests, I saw no >>> impact from this change. We *could* make this change 64-bit-only, and >>> leave the age field at 4 bits for the 32-bit version. If we did so, we >>> could also decrease the alignment required for the JavaThread* to 512 >>> from the current 1024. >>> >>> The comment changes imply that the bits available for the JavaThread* >>> have been reduced by 1, and that the alignment is now stronger, but >>> neither is true. The comments have been corrected to match the >>> alignment that was already enforced. >>> >>> Three tests needed to be corrected to match the new limits. These check >>> the maximum valid values, what value represents NeverTenure, and so on. >>> >>> Thanks, >>> Tom >>> From charlie.hunt at oracle.com Fri Feb 13 16:01:45 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Fri, 13 Feb 2015 10:01:45 -0600 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DE1A56.9080008@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> <54DE1A56.9080008@oracle.com> Message-ID: <437E034A-E466-4270-89B9-10278F08CA7B@oracle.com> Hi Tom, Some background on some observations and strategies folks have tended to take wrt GC tuning. With both Parallel GC and CMS GC, a common approach by folks tuning GC and heap sizes is to employ a strategy of promoting as few objects as possible from young generation to old generation. In other words, keep live objects in young generation as long as possible. This is where the max tenuring threshold comes in. If you have the ability to have higher object ages, those live objects can slosh around between survivor spaces for a longer time / higher age and have a higher probability of becoming unreachable before getting promoted to old generation. Once they are in old generation, (as you know) with Parallel GC it is a bit more expensive to collect them. With CMS, promoting fewer objects to old generation implies less chance for old generation fragmentation. However, with G1 GC, we have the ability to incrementally collect old generation and incrementally collecting old generation does not have the pain points that Parallel GC and CMS GC carry with them. So the approach of trying to avoid object promotion is not as useful with G1. Hence, the value of having a higher max tenuring threshold is not as important with G1. And, with G1 expected to one day replace Parallel GC and CMS GC, whenever that might be ;-) ? well, you get the picture. To summarize, I suspect folks who are using Parallel GC or CMS GC could probably take advantage of a higher max tenuring threshold. But, in G1 I have not seen that having a higher max tenuring threshold as being nearly as useful. There may be others in the community who do GC tuning on a daily basis who may be able to offer their observations and experience too. Fwiw, from my perspective I am ok with the suggestion in your note below of closing this as ?evolution of the JVM since the time the age field was reduced has revealed potentially more valuable uses for the bit?. hths, charlie > On Feb 13, 2015, at 9:37 AM, Tom Benson wrote: > > Hi, > Based on comments here and elsewhere on possible future uses for this unused bit (in the 64-bit version), I'm more inclined to close both 6764713 and 6719225 with no change. With a comment along the lines of "evolution of the JVM since the time the age field was reduced has revealed potentially more valuable uses of the bit." > > However, if there are supporters of a larger MaxTenuringThreshold lurking, I'd like to hear their point of view as well. > Thanks, > Tom > > On 2/13/2015 9:42 AM, Karen Kinnear wrote: >> Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently. >> >> In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am >> not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark >> immutable objects or value types (yes, today those don't have an identity hash but I am not yet convinced that we won't have >> a design where we need to distinguish reference objects from value types underneath a common object header for jdk10). >> >> So - hmmm. >> >> thanks, >> Karen >> >> On Feb 12, 2015, at 9:54 PM, David Holmes wrote: >> >>> Hi Tom, >>> >>> If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most! >>> >>> The rest seems okay but I'm still mulling over it. :) >>> >>> Thanks, >>> David H. >>> >>> On 13/02/2015 6:14 AM, Tom Benson wrote: >>>> Hi, >>>> I need reviewers and a commit sponsor for changes for bug 6764713, which >>>> will increase the size of the age field in an object header from 4 bits >>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >>>> default will remain at the current value of 15. >>>> >>>> This includes the same change to the 32-bit version, which would close >>>> bug 6719225 as well. In that case, the hash field in the header is >>>> affected, losing one bit (25 bits -> 24), so I have asked for review >>>> from hotspot-runtime-dev as well as gc-dev. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >>>> Testing: JPRT and reference server performance tests >>>> >>>> Notes: >>>> Contrary to what earlier notes in the JBS entry said, this does not >>>> require stronger alignment for the JavaThread structure for when biased >>>> locking stores that pointer in the header. The JavaThread* was already >>>> being aligned 1 power of 2 more strongly than it needed to be, so there >>>> was an unused bit that could be stolen. >>>> >>>> In the 32-bit version, it does require taking one bit from the hash >>>> field, which goes from 25 to 24 bits. This is something I'd especially >>>> like feedback on. Running reference server performance tests, I saw no >>>> impact from this change. We *could* make this change 64-bit-only, and >>>> leave the age field at 4 bits for the 32-bit version. If we did so, we >>>> could also decrease the alignment required for the JavaThread* to 512 >>>> from the current 1024. >>>> >>>> The comment changes imply that the bits available for the JavaThread* >>>> have been reduced by 1, and that the alignment is now stronger, but >>>> neither is true. The comments have been corrected to match the >>>> alignment that was already enforced. >>>> >>>> Three tests needed to be corrected to match the new limits. These check >>>> the maximum valid values, what value represents NeverTenure, and so on. >>>> >>>> Thanks, >>>> Tom >>>> > From varming at gmail.com Fri Feb 13 16:13:56 2015 From: varming at gmail.com (Carsten Varming) Date: Fri, 13 Feb 2015 11:13:56 -0500 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DE1A56.9080008@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> <54DE1A56.9080008@oracle.com> Message-ID: Dear Tom, If you want very large MaxTenuringThresholds, then you could add an option to reinterpret the value of the four bits to be a power of 2. One way is to only bump the age from i to i+1 when the gc count is divisible by 2^i. You lose granularity and precision, but gain some very large ages. Carsten On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson wrote: > Hi, > Based on comments here and elsewhere on possible future uses for this > unused bit (in the 64-bit version), I'm more inclined to close both 6764713 > and 6719225 with no change. With a comment along the lines of "evolution > of the JVM since the time the age field was reduced has revealed > potentially more valuable uses of the bit." > > However, if there are supporters of a larger MaxTenuringThreshold lurking, > I'd like to hear their point of view as well. > Thanks, > Tom > > > On 2/13/2015 9:42 AM, Karen Kinnear wrote: > >> Seconded. For the hash code, talk to Coleen and ask her who did the work >> in core libs recently. >> >> In addition, those bits are fiercely sought after - we have other things >> we would like to do with any available bits and I am >> not convinced this is more valuable. We just resisted using one for the >> jdk9 frozen arrays although we might want one to mark >> immutable objects or value types (yes, today those don't have an identity >> hash but I am not yet convinced that we won't have >> a design where we need to distinguish reference objects from value types >> underneath a common object header for jdk10). >> >> So - hmmm. >> >> thanks, >> Karen >> >> On Feb 12, 2015, at 9:54 PM, David Holmes wrote: >> >> Hi Tom, >>> >>> If you are potentially messing with the (identity) hash of all Java >>> objects in the 32-bit case then this needs a broader discussion eg on >>> core-libs-dev (cc'd) as this will impact end-user code the most! >>> >>> The rest seems okay but I'm still mulling over it. :) >>> >>> Thanks, >>> David H. >>> >>> On 13/02/2015 6:14 AM, Tom Benson wrote: >>> >>>> Hi, >>>> I need reviewers and a commit sponsor for changes for bug 6764713, which >>>> will increase the size of the age field in an object header from 4 bits >>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >>>> default will remain at the current value of 15. >>>> >>>> This includes the same change to the 32-bit version, which would close >>>> bug 6719225 as well. In that case, the hash field in the header is >>>> affected, losing one bit (25 bits -> 24), so I have asked for review >>>> from hotspot-runtime-dev as well as gc-dev. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >>>> Testing: JPRT and reference server performance tests >>>> >>>> Notes: >>>> Contrary to what earlier notes in the JBS entry said, this does not >>>> require stronger alignment for the JavaThread structure for when biased >>>> locking stores that pointer in the header. The JavaThread* was already >>>> being aligned 1 power of 2 more strongly than it needed to be, so there >>>> was an unused bit that could be stolen. >>>> >>>> In the 32-bit version, it does require taking one bit from the hash >>>> field, which goes from 25 to 24 bits. This is something I'd especially >>>> like feedback on. Running reference server performance tests, I saw no >>>> impact from this change. We *could* make this change 64-bit-only, and >>>> leave the age field at 4 bits for the 32-bit version. If we did so, we >>>> could also decrease the alignment required for the JavaThread* to 512 >>>> from the current 1024. >>>> >>>> The comment changes imply that the bits available for the JavaThread* >>>> have been reduced by 1, and that the alignment is now stronger, but >>>> neither is true. The comments have been corrected to match the >>>> alignment that was already enforced. >>>> >>>> Three tests needed to be corrected to match the new limits. These check >>>> the maximum valid values, what value represents NeverTenure, and so on. >>>> >>>> Thanks, >>>> Tom >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Feb 13 16:37:20 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 13 Feb 2015 17:37:20 +0100 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DE1A56.9080008@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> <54DE1A56.9080008@oracle.com> Message-ID: <54DE2840.3000402@oracle.com> Hi, On 2015-02-13 16:37, Tom Benson wrote: > Hi, > Based on comments here and elsewhere on possible future uses for this > unused bit (in the 64-bit version), I'm more inclined to close both > 6764713 and 6719225 with no change. With a comment along the lines of > "evolution of the JVM since the time the age field was reduced has > revealed potentially more valuable uses of the bit." This sounds like a good approach in my view. I think we can leave the age at 4 bits. In my view the main issue with the aging is that our heuristics for adjusting the tenuring threshold are not always reliable. Sometimes the threshold gets stuck at the max value etc. I prefer to close these bug reports as suggested above and if we want to improve the tenuring we should work on the heuristics instead. Thanks for digging these bug reports up, Tom! We should probably have brought them up for discussion and closing them a long time ago. Thanks, Bengt > > However, if there are supporters of a larger MaxTenuringThreshold > lurking, I'd like to hear their point of view as well. > Thanks, > Tom > > On 2/13/2015 9:42 AM, Karen Kinnear wrote: >> Seconded. For the hash code, talk to Coleen and ask her who did the >> work in core libs recently. >> >> In addition, those bits are fiercely sought after - we have other >> things we would like to do with any available bits and I am >> not convinced this is more valuable. We just resisted using one for >> the jdk9 frozen arrays although we might want one to mark >> immutable objects or value types (yes, today those don't have an >> identity hash but I am not yet convinced that we won't have >> a design where we need to distinguish reference objects from value >> types underneath a common object header for jdk10). >> >> So - hmmm. >> >> thanks, >> Karen >> >> On Feb 12, 2015, at 9:54 PM, David Holmes wrote: >> >>> Hi Tom, >>> >>> If you are potentially messing with the (identity) hash of all Java >>> objects in the 32-bit case then this needs a broader discussion eg >>> on core-libs-dev (cc'd) as this will impact end-user code the most! >>> >>> The rest seems okay but I'm still mulling over it. :) >>> >>> Thanks, >>> David H. >>> >>> On 13/02/2015 6:14 AM, Tom Benson wrote: >>>> Hi, >>>> I need reviewers and a commit sponsor for changes for bug 6764713, >>>> which >>>> will increase the size of the age field in an object header from 4 >>>> bits >>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >>>> default will remain at the current value of 15. >>>> >>>> This includes the same change to the 32-bit version, which would close >>>> bug 6719225 as well. In that case, the hash field in the header is >>>> affected, losing one bit (25 bits -> 24), so I have asked for review >>>> from hotspot-runtime-dev as well as gc-dev. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >>>> Testing: JPRT and reference server performance tests >>>> >>>> Notes: >>>> Contrary to what earlier notes in the JBS entry said, this does not >>>> require stronger alignment for the JavaThread structure for when >>>> biased >>>> locking stores that pointer in the header. The JavaThread* was >>>> already >>>> being aligned 1 power of 2 more strongly than it needed to be, so >>>> there >>>> was an unused bit that could be stolen. >>>> >>>> In the 32-bit version, it does require taking one bit from the hash >>>> field, which goes from 25 to 24 bits. This is something I'd >>>> especially >>>> like feedback on. Running reference server performance tests, I >>>> saw no >>>> impact from this change. We *could* make this change 64-bit-only, and >>>> leave the age field at 4 bits for the 32-bit version. If we did >>>> so, we >>>> could also decrease the alignment required for the JavaThread* to 512 >>>> from the current 1024. >>>> >>>> The comment changes imply that the bits available for the JavaThread* >>>> have been reduced by 1, and that the alignment is now stronger, but >>>> neither is true. The comments have been corrected to match the >>>> alignment that was already enforced. >>>> >>>> Three tests needed to be corrected to match the new limits. These >>>> check >>>> the maximum valid values, what value represents NeverTenure, and so >>>> on. >>>> >>>> Thanks, >>>> Tom >>>> > From tom.benson at oracle.com Fri Feb 13 17:16:15 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 13 Feb 2015 12:16:15 -0500 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DE2840.3000402@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> <54DE1A56.9080008@oracle.com> <54DE2840.3000402@oracle.com> Message-ID: <54DE315F.5050802@oracle.com> Hi, Note that not taking this bit for the age field would open the door to reducing the alignment of the JavaThread*. It's the fact that there was already an unclaimed bit there (in the 64-bit version) that made the age size increase seem more reasonable. However, I'd propose not changing that, either, at least for the 64-bit version, so that when someone finally claims "the bit" it doesn't need to be undone. For the 32-bit version, it's less clear cut, but I'd still lean toward leaving it as is. Tom On 2/13/2015 11:37 AM, Bengt Rutisson wrote: > > Hi, > > On 2015-02-13 16:37, Tom Benson wrote: >> Hi, >> Based on comments here and elsewhere on possible future uses for this >> unused bit (in the 64-bit version), I'm more inclined to close both >> 6764713 and 6719225 with no change. With a comment along the lines >> of "evolution of the JVM since the time the age field was reduced has >> revealed potentially more valuable uses of the bit." > > This sounds like a good approach in my view. I think we can leave the > age at 4 bits. In my view the main issue with the aging is that our > heuristics for adjusting the tenuring threshold are not always > reliable. Sometimes the threshold gets stuck at the max value etc. I > prefer to close these bug reports as suggested above and if we want to > improve the tenuring we should work on the heuristics instead. > > Thanks for digging these bug reports up, Tom! We should probably have > brought them up for discussion and closing them a long time ago. > > Thanks, > Bengt > >> >> However, if there are supporters of a larger MaxTenuringThreshold >> lurking, I'd like to hear their point of view as well. >> Thanks, >> Tom >> From sangheon.kim at oracle.com Fri Feb 13 17:40:47 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 13 Feb 2015 09:40:47 -0800 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DDAA12.8010506@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDAA12.8010506@oracle.com> Message-ID: <54DE371F.50107@oracle.com> Hi Jesper, Thanks for reviewing this and sponsoring this. Sangheon On 02/12/2015 11:38 PM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > Looks good! > Thanks for enhancing the asserts, this is something the Hotspot code > is in great need of. I'll be happy to sponsor this change. > /Jesper > > > Sangheon Kim skrev den 13/2/15 07:54: >> Hi All, >> >> Please review this small enhancement for better error messages when >> assert fails. >> This change would be helpful forJDK-8071930 >> which is hard to >> reproduce. >> >> I will need a sponsor for this change. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073115 >> >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ >> >> Testing: >> JPRT >> >> Thanks, >> Sangheon >> From sangheon.kim at oracle.com Fri Feb 13 17:41:18 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 13 Feb 2015 09:41:18 -0800 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DDB1FB.6020609@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDB1FB.6020609@oracle.com> Message-ID: <54DE373E.6060408@oracle.com> Hi Bengt, Thank your for the review. Sangheon On 02/13/2015 12:12 AM, Bengt Rutisson wrote: > > Hi Sangheon, > > On 13/02/15 07:54, Sangheon Kim wrote: >> Hi All, >> >> Please review this small enhancement for better error messages when assert fails. >> This change would be helpful forJDK-8071930 which is hard to reproduce. >> >> I will need a sponsor for this change. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073115 >> >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ > > Looks good. > > Thanks, > Bengt > >> Testing: >> JPRT >> >> Thanks, >> Sangheon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Fri Feb 13 17:41:40 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 13 Feb 2015 09:41:40 -0800 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DDBEB4.2000909@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDBEB4.2000909@oracle.com> Message-ID: <54DE3754.6040409@oracle.com> Hi StefanK, Thanks for reviewing this and please see inline. On 02/13/2015 01:07 AM, Stefan Karlsson wrote: > Hi Sangheon, > > On 2015-02-13 07:54, Sangheon Kim wrote: >> Hi All, >> >> Please review this small enhancement for better error messages when assert fails. >> This change would be helpful forJDK-8071930 which is hard to reproduce. >> >> I will need a sponsor for this change. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073115 >> >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ > > http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html > > You are duplicating the same assert three times. Could you create a > new define, say #define assert_covered_region_contains(addr) ..., and > remove the duplication? This will also have the benefit of lowering > the line noise in the functions you change. Basically I agree with you. But in this case I think the benefit of macro is limited to reduce 3 lines than current proposal. Unless this macro moves to general header file, its usage would be limited. So let me skip adding a new macro at this time. Thanks, Sangheon > > Thanks, > StefanK > >> Testing: >> JPRT >> >> Thanks, >> Sangheon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Fri Feb 13 13:47:53 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 13 Feb 2015 14:47:53 +0100 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DD677F.10101@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> Message-ID: <54DE0089.7000303@gmail.com> On 02/13/2015 03:54 AM, David Holmes wrote: > Hi Tom, > > If you are potentially messing with the (identity) hash of all Java > objects in the 32-bit case then this needs a broader discussion eg on > core-libs-dev (cc'd) as this will impact end-user code the most! > > The rest seems okay but I'm still mulling over it. :) > > Thanks, > David H. Hi, As I understand, this will make identity hashCode have 2^24 instead of 2^25 distinct values on 32 bit architectures, right? This will mostly affect java.util.IdentityHashMap performance (and any use of objects that don't override hashCode in other hashCode-based Maps). IHM has a maximum capacity of 2^29 (key, value) slots. Performance will start to degrade sooner - at sizes > 2^24 / 1.5 (~10M) instead of 2^25 / 1.5 (~20M) entries. IHM has the following hashCode -> array slot index mapping function: /** * Returns index for Object x. */ private static int hash(Object x, int length) { int h = System.identityHashCode(x); // Multiply by -127, and left-shift to use least bit as part of hash return ((h << 1) - (h << 8)) & (length - 1); } Left-shift is added because keys are located at even indexes and associated values are at odd indexes in the same array. So the function to map hashCode to ordinal key index is actually: (h - (h << 7)) & (capacity - 1) where capacity is a power of two <= 2^29, which means that it is necessary that 24 hash bits from Object header be mapped to lower 24 bits of Object.hashCode(). Object.hashCode() in range 0..2^24-1 should still be enough to address the whole range of 2^29 capacity table given the above mapping function. So the question is, how frequent are IdentityHashMap(s) with > 10M entries or any other HashMaps with keys that don't override Object.hashCode(). Here's an JMH (http://openjdk.java.net/projects/code-tools/jmh/) micro-benchmark you can use to measure the impact of change on IdentityHashMap: http://cr.openjdk.java.net/~plevart/misc/IHMBench/IHMBench.java by default it creates an IdentityHashMap with size of 2^24 entries. This is where the performance difference is expected to start to be different between 24bit vs. 25bit hash codes. You can also try to use larger (up to 28) 'log2size' parameter, but you might want to increate -Xmx too in this case. Regards, Peter > On 13/02/2015 6:14 AM, Tom Benson wrote: >> Hi, >> I need reviewers and a commit sponsor for changes for bug 6764713, which >> will increase the size of the age field in an object header from 4 bits >> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >> default will remain at the current value of 15. >> >> This includes the same change to the 32-bit version, which would close >> bug 6719225 as well. In that case, the hash field in the header is >> affected, losing one bit (25 bits -> 24), so I have asked for review >> from hotspot-runtime-dev as well as gc-dev. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >> Testing: JPRT and reference server performance tests >> >> Notes: >> Contrary to what earlier notes in the JBS entry said, this does not >> require stronger alignment for the JavaThread structure for when biased >> locking stores that pointer in the header. The JavaThread* was already >> being aligned 1 power of 2 more strongly than it needed to be, so there >> was an unused bit that could be stolen. >> >> In the 32-bit version, it does require taking one bit from the hash >> field, which goes from 25 to 24 bits. This is something I'd especially >> like feedback on. Running reference server performance tests, I saw no >> impact from this change. We *could* make this change 64-bit-only, and >> leave the age field at 4 bits for the 32-bit version. If we did so, we >> could also decrease the alignment required for the JavaThread* to 512 >> from the current 1024. >> >> The comment changes imply that the bits available for the JavaThread* >> have been reduced by 1, and that the alignment is now stronger, but >> neither is true. The comments have been corrected to match the >> alignment that was already enforced. >> >> Three tests needed to be corrected to match the new limits. These check >> the maximum valid values, what value represents NeverTenure, and so on. >> >> Thanks, >> Tom >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Fri Feb 13 16:00:37 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 13 Feb 2015 17:00:37 +0100 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DE1A56.9080008@oracle.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> <54DE1A56.9080008@oracle.com> Message-ID: <54DE1FA5.7010508@gmail.com> On 02/13/2015 04:37 PM, Tom Benson wrote: > Hi, > Based on comments here and elsewhere on possible future uses for this > unused bit (in the 64-bit version), I'm more inclined to close both > 6764713 and 6719225 with no change. With a comment along the lines of > "evolution of the JVM since the time the age field was reduced has > revealed potentially more valuable uses of the bit." > > However, if there are supporters of a larger MaxTenuringThreshold > lurking, I'd like to hear their point of view as well. > Thanks, > Tom Hi Tom, This is just my uneducated thinking... I can imagine that with G1 collector this is more complicated, but with standard young-gen collector where there are 2 survivor spaces, couldn't they be labeled "A" and "B" and when MaxTenuringThreshold > 15, the Object's age be incremented only when it is moved in one direction A -> B (and not when it is moved B -> A). For MaxTenuringThreshold of say 24, it would be moved to OldGen when age > 24/2 then. The resolution of MaxTenuringThreshold > 15 could only be specified in steps of 2 then (16, 18, 20, ... 30). I guess the movement of young objects among survivor regions in G1 is not so regular (so that you could label half of survivor regions with "A" and the other half with "B" and objects would always move from A -> B or B -> A and never A -> A or B -> B), right? Regards, Peter > > On 2/13/2015 9:42 AM, Karen Kinnear wrote: >> Seconded. For the hash code, talk to Coleen and ask her who did the >> work in core libs recently. >> >> In addition, those bits are fiercely sought after - we have other >> things we would like to do with any available bits and I am >> not convinced this is more valuable. We just resisted using one for >> the jdk9 frozen arrays although we might want one to mark >> immutable objects or value types (yes, today those don't have an >> identity hash but I am not yet convinced that we won't have >> a design where we need to distinguish reference objects from value >> types underneath a common object header for jdk10). >> >> So - hmmm. >> >> thanks, >> Karen >> >> On Feb 12, 2015, at 9:54 PM, David Holmes wrote: >> >>> Hi Tom, >>> >>> If you are potentially messing with the (identity) hash of all Java >>> objects in the 32-bit case then this needs a broader discussion eg >>> on core-libs-dev (cc'd) as this will impact end-user code the most! >>> >>> The rest seems okay but I'm still mulling over it. :) >>> >>> Thanks, >>> David H. >>> >>> On 13/02/2015 6:14 AM, Tom Benson wrote: >>>> Hi, >>>> I need reviewers and a commit sponsor for changes for bug 6764713, >>>> which >>>> will increase the size of the age field in an object header from 4 >>>> bits >>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >>>> default will remain at the current value of 15. >>>> >>>> This includes the same change to the 32-bit version, which would close >>>> bug 6719225 as well. In that case, the hash field in the header is >>>> affected, losing one bit (25 bits -> 24), so I have asked for review >>>> from hotspot-runtime-dev as well as gc-dev. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >>>> Testing: JPRT and reference server performance tests >>>> >>>> Notes: >>>> Contrary to what earlier notes in the JBS entry said, this does not >>>> require stronger alignment for the JavaThread structure for when >>>> biased >>>> locking stores that pointer in the header. The JavaThread* was >>>> already >>>> being aligned 1 power of 2 more strongly than it needed to be, so >>>> there >>>> was an unused bit that could be stolen. >>>> >>>> In the 32-bit version, it does require taking one bit from the hash >>>> field, which goes from 25 to 24 bits. This is something I'd >>>> especially >>>> like feedback on. Running reference server performance tests, I >>>> saw no >>>> impact from this change. We *could* make this change 64-bit-only, and >>>> leave the age field at 4 bits for the 32-bit version. If we did >>>> so, we >>>> could also decrease the alignment required for the JavaThread* to 512 >>>> from the current 1024. >>>> >>>> The comment changes imply that the bits available for the JavaThread* >>>> have been reduced by 1, and that the alignment is now stronger, but >>>> neither is true. The comments have been corrected to match the >>>> alignment that was already enforced. >>>> >>>> Three tests needed to be corrected to match the new limits. These >>>> check >>>> the maximum valid values, what value represents NeverTenure, and so >>>> on. >>>> >>>> Thanks, >>>> Tom >>>> > From peter.levart at gmail.com Fri Feb 13 16:55:04 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 13 Feb 2015 17:55:04 +0100 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com> <54DE1A56.9080008@oracle.com> Message-ID: <54DE2C68.4020505@gmail.com> On 02/13/2015 05:13 PM, Carsten Varming wrote: > Dear Tom, > > If you want very large MaxTenuringThresholds, then you could add an option > to reinterpret the value of the four bits to be a power of 2. One way is to > only bump the age from i to i+1 when the gc count is divisible by 2^i. You > lose granularity and precision, but gain some very large ages. > > Carsten GC count, yes. Clever. Or, 4 bit value 'x' could be reinterpreted as being multiplied by constant 'k', computed from MaxTenuringThreshold: k = 1 + (MaxTenuringThreshold >> 4); ... 0 <= MaxTenuringThreshold <= 15: k = 1 16 <= MaxTenuringThreshold <= 31: k = 2 32 <= MaxTenuringThreshold <= 47: k = 3 48 <= MaxTenuringThreshold <= 63: k = 4 ... ...then increment 'x' when GC count is divisible by 'k'. When 'x' > MaxTenuringThreshold / k, object is OLD... Peter > > On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson wrote: > >> Hi, >> Based on comments here and elsewhere on possible future uses for this >> unused bit (in the 64-bit version), I'm more inclined to close both 6764713 >> and 6719225 with no change. With a comment along the lines of "evolution >> of the JVM since the time the age field was reduced has revealed >> potentially more valuable uses of the bit." >> >> However, if there are supporters of a larger MaxTenuringThreshold lurking, >> I'd like to hear their point of view as well. >> Thanks, >> Tom >> >> >> On 2/13/2015 9:42 AM, Karen Kinnear wrote: >> >>> Seconded. For the hash code, talk to Coleen and ask her who did the work >>> in core libs recently. >>> >>> In addition, those bits are fiercely sought after - we have other things >>> we would like to do with any available bits and I am >>> not convinced this is more valuable. We just resisted using one for the >>> jdk9 frozen arrays although we might want one to mark >>> immutable objects or value types (yes, today those don't have an identity >>> hash but I am not yet convinced that we won't have >>> a design where we need to distinguish reference objects from value types >>> underneath a common object header for jdk10). >>> >>> So - hmmm. >>> >>> thanks, >>> Karen >>> >>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote: >>> >>> Hi Tom, >>>> If you are potentially messing with the (identity) hash of all Java >>>> objects in the 32-bit case then this needs a broader discussion eg on >>>> core-libs-dev (cc'd) as this will impact end-user code the most! >>>> >>>> The rest seems okay but I'm still mulling over it. :) >>>> >>>> Thanks, >>>> David H. >>>> >>>> On 13/02/2015 6:14 AM, Tom Benson wrote: >>>> >>>>> Hi, >>>>> I need reviewers and a commit sponsor for changes for bug 6764713, which >>>>> will increase the size of the age field in an object header from 4 bits >>>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the >>>>> default will remain at the current value of 15. >>>>> >>>>> This includes the same change to the 32-bit version, which would close >>>>> bug 6719225 as well. In that case, the hash field in the header is >>>>> affected, losing one bit (25 bits -> 24), so I have asked for review >>>>> from hotspot-runtime-dev as well as gc-dev. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 >>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 >>>>> Testing: JPRT and reference server performance tests >>>>> >>>>> Notes: >>>>> Contrary to what earlier notes in the JBS entry said, this does not >>>>> require stronger alignment for the JavaThread structure for when biased >>>>> locking stores that pointer in the header. The JavaThread* was already >>>>> being aligned 1 power of 2 more strongly than it needed to be, so there >>>>> was an unused bit that could be stolen. >>>>> >>>>> In the 32-bit version, it does require taking one bit from the hash >>>>> field, which goes from 25 to 24 bits. This is something I'd especially >>>>> like feedback on. Running reference server performance tests, I saw no >>>>> impact from this change. We *could* make this change 64-bit-only, and >>>>> leave the age field at 4 bits for the 32-bit version. If we did so, we >>>>> could also decrease the alignment required for the JavaThread* to 512 >>>>> from the current 1024. >>>>> >>>>> The comment changes imply that the bits available for the JavaThread* >>>>> have been reduced by 1, and that the alignment is now stronger, but >>>>> neither is true. The comments have been corrected to match the >>>>> alignment that was already enforced. >>>>> >>>>> Three tests needed to be corrected to match the new limits. These check >>>>> the maximum valid values, what value represents NeverTenure, and so on. >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>> From dl at cs.oswego.edu Fri Feb 13 14:33:48 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 13 Feb 2015 09:33:48 -0500 Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold In-Reply-To: <54DE0089.7000303@gmail.com> References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com> <54DE0089.7000303@gmail.com> Message-ID: <54DE0B4C.6010005@cs.oswego.edu> On 02/13/2015 08:47 AM, Peter Levart wrote: > On 02/13/2015 03:54 AM, David Holmes wrote: >> Hi Tom, >> >> If you are potentially messing with the (identity) hash of all Java objects in >> the 32-bit case then this needs a broader discussion eg on core-libs-dev >> (cc'd) as this will impact end-user code the most! >> > > As I understand, this will make identity hashCode have 2^24 instead of 2^25 > distinct values on 32 bit architectures, right? This will mostly affect > java.util.IdentityHashMap performance (and any use of objects that don't > override hashCode in other hashCode-based Maps). IHM has a maximum capacity of > 2^29 (key, value) slots. Performance will start to degrade sooner - at sizes > > 2^24 / 1.5 (~10M) instead of 2^25 / 1.5 (~20M) entries. > In other words, it approximately doubles the probability of a collision for tables with more than 10 million keys. It's a sure thing that some applications out there will see measurable slowdowns. So the justification needed here is whether these slowdowns are more than compensated by the benefits of adding another age bit. This seems hard to carry out, but the fallback plan of adding age bit only on 64bit platforms that don't impact hash bits sounds completely safe. -Doug From sangheon.kim at oracle.com Fri Feb 13 21:11:45 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 13 Feb 2015 13:11:45 -0800 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DE3754.6040409@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDBEB4.2000909@oracle.com> <54DE3754.6040409@oracle.com> Message-ID: <54DE6890.5050704@oracle.com> Hi All, Sorry for sending many emails for this simple fix. After some discussion with StefanK, I decided to add a macro for this assert. Webrev: http://cr.openjdk.java.net/~sangheki/8073115/webrev.01/ Thanks, Sangheon On 02/13/2015 09:41 AM, Sangheon Kim wrote: > Hi StefanK, > > Thanks for reviewing this and please see inline. > > On 02/13/2015 01:07 AM, Stefan Karlsson wrote: >> Hi Sangheon, >> >> On 2015-02-13 07:54, Sangheon Kim wrote: >>> Hi All, >>> >>> Please review this small enhancement for better error messages when assert fails. >>> This change would be helpful forJDK-8071930 which is hard to reproduce. >>> >>> I will need a sponsor for this change. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8073115 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ >> >> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html >> >> You are duplicating the same assert three times. Could you create a >> new define, say #define assert_covered_region_contains(addr) ..., and >> remove the duplication? This will also have the benefit of lowering >> the line noise in the functions you change. > Basically I agree with you. > But in this case I think the benefit of macro is limited to reduce 3 > lines than current proposal. > Unless this macro moves to general header file, its usage would be > limited. > So let me skip adding a new macro at this time. > > Thanks, > Sangheon > >> >> Thanks, >> StefanK >> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Sangheon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Fri Feb 13 21:26:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Feb 2015 22:26:08 +0100 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DE6890.5050704@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDBEB4.2000909@oracle.com> <54DE3754.6040409@oracle.com> <54DE6890.5050704@oracle.com> Message-ID: <54DE6BF0.7000807@oracle.com> On 2015-02-13 22:11, Sangheon Kim wrote: > Hi All, > > Sorry for sending many emails for this simple fix. > After some discussion with StefanK, I decided to add a macro for this > assert. > > Webrev: > http://cr.openjdk.java.net/~sangheki/8073115/webrev.01/ Looks good. Thanks for adding the macro. StefanK > > Thanks, > Sangheon > > On 02/13/2015 09:41 AM, Sangheon Kim wrote: >> Hi StefanK, >> >> Thanks for reviewing this and please see inline. >> >> On 02/13/2015 01:07 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 2015-02-13 07:54, Sangheon Kim wrote: >>>> Hi All, >>>> >>>> Please review this small enhancement for better error messages when assert fails. >>>> This change would be helpful forJDK-8071930 which is hard to reproduce. >>>> >>>> I will need a sponsor for this change. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8073115 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ >>> >>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html >>> >>> You are duplicating the same assert three times. Could you create a >>> new define, say #define assert_covered_region_contains(addr) ..., >>> and remove the duplication? This will also have the benefit of >>> lowering the line noise in the functions you change. >> Basically I agree with you. >> But in this case I think the benefit of macro is limited to reduce 3 >> lines than current proposal. >> Unless this macro moves to general header file, its usage would be >> limited. >> So let me skip adding a new macro at this time. >> >> Thanks, >> Sangheon >> >>> >>> Thanks, >>> StefanK >>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Sangheon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwha at google.com Sat Feb 14 01:21:38 2015 From: jwha at google.com (Jungwoo Ha) Date: Fri, 13 Feb 2015 17:21:38 -0800 Subject: DTraceAllocProbes bug in interpreter Message-ID: I am not sure if DTraceAllocProbes is a live code, but I think this is a bug. dtrace_object_alloc has changed to receive size argument in JDK8. This code only passes oop to dtrace_object_alloc. RDX has the size but it needs to be saved. I don't use DTrace, but it looks broken. If someone sponsor this is a right fix, I'll create a webrev. diff -r f06c7b654d63 src/cpu/x86/vm/templateTable_x86_32.cpp --- a/src/cpu/x86/vm/templateTable_x86_32.cpp Thu Jul 31 09:58:53 2014 +0100 +++ b/src/cpu/x86/vm/templateTable_x86_32.cpp Fri Feb 13 17:14:57 2015 -0800 @@ -3288,6 +3288,7 @@ // The object is initialized before the header. If the object size is // zero, go directly to the header initialization. __ bind(initialize_object); + __ push(rdx); // save object size __ decrement(rdx, sizeof(oopDesc)); __ jcc(Assembler::zero, initialize_header); @@ -3328,13 +3329,14 @@ __ pop(rcx); // get saved klass back in the register. } __ store_klass(rax, rcx); // klass + __ pop(rdx); // restore object size to rdx { SkipIfEqual skip_if(_masm, &DTraceAllocProbes, 0); // Trigger dtrace event for fastpath __ push(atos); __ call_VM_leaf( - CAST_FROM_FN_PTR(address, SharedRuntime::dtrace_object_alloc), rax); + CAST_FROM_FN_PTR(address, SharedRuntime::dtrace_object_alloc), rax, rdx); __ pop(atos); } diff -r f06c7b654d63 src/cpu/x86/vm/templateTable_x86_64.cpp --- a/src/cpu/x86/vm/templateTable_x86_64.cpp Thu Jul 31 09:58:53 2014 +0100 +++ b/src/cpu/x86/vm/templateTable_x86_64.cpp Fri Feb 13 17:14:57 2015 -0800 @@ -3352,6 +3352,7 @@ // The object is initialized before the header. If the object size is // zero, go directly to the header initialization. __ bind(initialize_object); + __ movl(rbx, rdx); // save object size to rbx __ decrementl(rdx, sizeof(oopDesc)); __ jcc(Assembler::zero, initialize_header); @@ -3386,7 +3387,7 @@ // Trigger dtrace event for fastpath __ push(atos); // save the return value __ call_VM_leaf( - CAST_FROM_FN_PTR(address, SharedRuntime::dtrace_object_alloc), rax); + CAST_FROM_FN_PTR(address, SharedRuntime::dtrace_object_alloc), rax, rbx); __ pop(atos); // restore the return value } -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Sat Feb 14 04:15:52 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sat, 14 Feb 2015 05:15:52 +0100 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DE6890.5050704@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDBEB4.2000909@oracle.com> <54DE3754.6040409@oracle.com> <54DE6890.5050704@oracle.com> Message-ID: <54DECBF8.1060106@oracle.com> Looks good! /Jesper Sangheon Kim skrev den 13/2/15 22:11: > Hi All, > > Sorry for sending many emails for this simple fix. > After some discussion with StefanK, I decided to add a macro for this assert. > > Webrev: > http://cr.openjdk.java.net/~sangheki/8073115/webrev.01/ > > Thanks, > Sangheon > > On 02/13/2015 09:41 AM, Sangheon Kim wrote: >> Hi StefanK, >> >> Thanks for reviewing this and please see inline. >> >> On 02/13/2015 01:07 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 2015-02-13 07:54, Sangheon Kim wrote: >>>> Hi All, >>>> >>>> Please review this small enhancement for better error messages when assert fails. >>>> This change would be helpful forJDK-8071930 which is hard to reproduce. >>>> >>>> I will need a sponsor for this change. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8073115 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ >>> >>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html >>> >>> You are duplicating the same assert three times. Could you create a new >>> define, say #define assert_covered_region_contains(addr) ..., and remove the >>> duplication? This will also have the benefit of lowering the line noise in >>> the functions you change. >> Basically I agree with you. >> But in this case I think the benefit of macro is limited to reduce 3 lines >> than current proposal. >> Unless this macro moves to general header file, its usage would be limited. >> So let me skip adding a new macro at this time. >> >> Thanks, >> Sangheon >> >>> >>> Thanks, >>> StefanK >>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Sangheon >>> >> > From yasuenag at gmail.com Sat Feb 14 13:10:46 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 14 Feb 2015 22:10:46 +0900 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DDEF20.6010501@oracle.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> Message-ID: <54DF4956.7030709@gmail.com> Hi Mikael, > I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? This function is used with GCCause::is_serviceability_requested_gc() . CMSCollector::is_external_interruption() and AdaptiveSizePolicy::check_gc_overhead_limit() is_user_requested_gc() and is_serviceability_requested_gc() checkes _jvmti_force_gc is selected. So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run to it. > A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. We can use GCCause::is_user_requested_gc() if the proposal in above is accepted. Thanks Yasumasa On 2015/02/13 21:33, Mikael Gerdin wrote: > Hi Yasumasa, > > On 2015-02-11 15:02, Yasumasa Suenaga wrote: >> Hi all, >> >> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >> However, it has been backouted because test is failed [1] and it is not considered >> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >> >> I've created patch for this enhancement. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ > > I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run > > Given that the documentation of the GC.run command is: > "GC.run > Call java.lang.System.gc(). > > Impact: Medium: Depends on Java heap size and content. > > Syntax: GC.run" > > I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). > > This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC > > A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. > > /Mikael > >> >> >> I'm jdk9 committer, but I'm not employee at Oracle. >> So I need a Sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >> From junjie.qian at yahoo.com Sun Feb 15 02:57:42 2015 From: junjie.qian at yahoo.com (Junjie Qian) Date: Sun, 15 Feb 2015 02:57:42 +0000 (UTC) Subject: DFS or BFS traversal in Parallel Scavenge (or Parallel new) GC Message-ID: <1466138772.5575012.1423969062481.JavaMail.yahoo@mail.yahoo.com> Dear all, I am reading the Parallel scavenge GC implementation in OpenJDK1.7, and having a question regarding the way how the parallel GC threads traverse the graph to mark the live objects. The question is, does one GC thread traverse the graph in DFS or BFS way in Parallel scavenge (or parallel new)? There are two conflicting sources suggesting the answer:1. the paper on ASPLOS'13, "A study of the scalability of stop-the-world garbage collectors on multicores", in Section 2.3.3. the author says "A GC thread performs a breadth-first traversal (BFT) of the graph of live objects". 2. the reply in this mailist, "Request for review (S): 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred" , Ramki said "ParNew's slightly more DFS-like evacuation compared with DefNew's considerably more BFS-like evacuation because of the latter's use of a pure Cheney scan compared with the use of (a) marking stack(s) in the former" A lot of references online explains Parnew uses the same parallel GC algorithm as ParallelScavenge, please correct me if I made a mistake on this one.?Thanks!BestJunjie -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Feb 16 07:12:19 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Feb 2015 08:12:19 +0100 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54DE6890.5050704@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDBEB4.2000909@oracle.com> <54DE3754.6040409@oracle.com> <54DE6890.5050704@oracle.com> Message-ID: <54E19853.1070502@oracle.com> Hi Sangheon, On 2015-02-13 22:11, Sangheon Kim wrote: > Hi All, > > Sorry for sending many emails for this simple fix. > After some discussion with StefanK, I decided to add a macro for this > assert. > > Webrev: > http://cr.openjdk.java.net/~sangheki/8073115/webrev.01/ Looks even better. :) Thanks, Bengt > > Thanks, > Sangheon > > On 02/13/2015 09:41 AM, Sangheon Kim wrote: >> Hi StefanK, >> >> Thanks for reviewing this and please see inline. >> >> On 02/13/2015 01:07 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 2015-02-13 07:54, Sangheon Kim wrote: >>>> Hi All, >>>> >>>> Please review this small enhancement for better error messages when assert fails. >>>> This change would be helpful forJDK-8071930 which is hard to reproduce. >>>> >>>> I will need a sponsor for this change. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8073115 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ >>> >>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html >>> >>> You are duplicating the same assert three times. Could you create a >>> new define, say #define assert_covered_region_contains(addr) ..., >>> and remove the duplication? This will also have the benefit of >>> lowering the line noise in the functions you change. >> Basically I agree with you. >> But in this case I think the benefit of macro is limited to reduce 3 >> lines than current proposal. >> Unless this macro moves to general header file, its usage would be >> limited. >> So let me skip adding a new macro at this time. >> >> Thanks, >> Sangheon >> >>> >>> Thanks, >>> StefanK >>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Sangheon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Feb 16 07:59:41 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 16 Feb 2015 02:59:41 -0500 Subject: RFR(M): 8068883: Remove disabling of warning "C4355: 'this' : used in base member initializer list" In-Reply-To: <0459695D-FA49-4233-BE79-EBEE83720FC7@oracle.com> References: <0459695D-FA49-4233-BE79-EBEE83720FC7@oracle.com> Message-ID: <59BD7FCE-B49F-42B2-8263-8BD784944055@oracle.com> On Jan 14, 2015, at 3:50 PM, Kim Barrett wrote: > > On Jan 14, 2015, at 11:28 AM, Volker Simonis wrote: >>>> I've additionally also removed the Visual Studio compiler macro which >>>> disable the warning "C4786:'identifier' : identifier was truncated to >>>> 'number' characters in the debug information." because as far as I >>>> could see, this was only relevant up to Visual Studio 6.0 and I hope >>>> nobody will ever compile the HotSpot with that compiler any more(see >>>> http://support.microsoft.com/kb/195386). >>> >>> This seems like a worthwhile change, independent of the other changes >>> being proposed. Could this be separated out. >>> >> >> Sure, if we decide not to push this patch we can still just remove >> that pragma in a separate change. > > [?] If you (Volker) don't want > to deal with the extra overhead, I'll take care of it. Finally getting around to following up on this bit of the discussion. https://bugs.openjdk.java.net/browse/JDK-8073188 So it might get cleaned up eventually. From mikael.gerdin at oracle.com Mon Feb 16 08:35:25 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Feb 2015 09:35:25 +0100 Subject: DTraceAllocProbes bug in interpreter In-Reply-To: References: Message-ID: <54E1ABCD.5010308@oracle.com> Hi Jungwoo, The DTrace probes are part of the serviceability support, bcc:ing gc-dev and redirecting to serviceability-dev. /Mikael On 2015-02-14 02:21, Jungwoo Ha wrote: > I am not sure if DTraceAllocProbes is a live code, but I think this is a > bug. > dtrace_object_alloc has changed to receive size argument in JDK8. > This code only passes oop to dtrace_object_alloc. RDX has the size but > it needs to be saved. > I don't use DTrace, but it looks broken. If someone sponsor this is a > right fix, I'll create a webrev. > > diff -r f06c7b654d63 src/cpu/x86/vm/templateTable_x86_32.cpp > --- a/src/cpu/x86/vm/templateTable_x86_32.cppThu Jul 31 09:58:53 2014 +0100 > +++ b/src/cpu/x86/vm/templateTable_x86_32.cppFri Feb 13 17:14:57 2015 -0800 > @@ -3288,6 +3288,7 @@ > // The object is initialized before the header. If the object size is > // zero, go directly to the header initialization. > __ bind(initialize_object); > + __ push(rdx); // save object size > __ decrement(rdx, sizeof(oopDesc)); > __ jcc(Assembler::zero, initialize_header); > @@ -3328,13 +3329,14 @@ > __ pop(rcx); // get saved klass back in the register. > } > __ store_klass(rax, rcx); // klass > + __ pop(rdx); // restore object size to rdx > { > SkipIfEqual skip_if(_masm, &DTraceAllocProbes, 0); > // Trigger dtrace event for fastpath > __ push(atos); > __ call_VM_leaf( > - CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax); > + CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax, rdx); > __ pop(atos); > } > diff -r f06c7b654d63 src/cpu/x86/vm/templateTable_x86_64.cpp > --- a/src/cpu/x86/vm/templateTable_x86_64.cppThu Jul 31 09:58:53 2014 +0100 > +++ b/src/cpu/x86/vm/templateTable_x86_64.cppFri Feb 13 17:14:57 2015 -0800 > @@ -3352,6 +3352,7 @@ > // The object is initialized before the header. If the object size is > // zero, go directly to the header initialization. > __ bind(initialize_object); > + __ movl(rbx, rdx); // save object size to rbx > __ decrementl(rdx, sizeof(oopDesc)); > __ jcc(Assembler::zero, initialize_header); > @@ -3386,7 +3387,7 @@ > // Trigger dtrace event for fastpath > __ push(atos); // save the return value > __ call_VM_leaf( > - CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax); > + CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax, rbx); > __ pop(atos); // restore the return value > } > From volker.simonis at gmail.com Mon Feb 16 09:42:59 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Feb 2015 10:42:59 +0100 Subject: RFR(M): 8068883: Remove disabling of warning "C4355: 'this' : used in base member initializer list" In-Reply-To: <59BD7FCE-B49F-42B2-8263-8BD784944055@oracle.com> References: <0459695D-FA49-4233-BE79-EBEE83720FC7@oracle.com> <59BD7FCE-B49F-42B2-8263-8BD784944055@oracle.com> Message-ID: On Mon, Feb 16, 2015 at 8:59 AM, Kim Barrett wrote: > On Jan 14, 2015, at 3:50 PM, Kim Barrett wrote: >> >> On Jan 14, 2015, at 11:28 AM, Volker Simonis wrote: >>>>> I've additionally also removed the Visual Studio compiler macro which >>>>> disable the warning "C4786:'identifier' : identifier was truncated to >>>>> 'number' characters in the debug information." because as far as I >>>>> could see, this was only relevant up to Visual Studio 6.0 and I hope >>>>> nobody will ever compile the HotSpot with that compiler any more(see >>>>> http://support.microsoft.com/kb/195386). >>>> >>>> This seems like a worthwhile change, independent of the other changes >>>> being proposed. Could this be separated out. >>>> >>> >>> Sure, if we decide not to push this patch we can still just remove >>> that pragma in a separate change. >> >> [?] If you (Volker) don't want >> to deal with the extra overhead, I'll take care of it. > > Finally getting around to following up on this bit of the discussion. > > https://bugs.openjdk.java.net/browse/JDK-8073188 > > So it might get cleaned up eventually. > Thanks! I'll be happy to review it once you send around a RFR. Regards, Volker From andrey.x.zakharov at oracle.com Mon Feb 16 11:48:56 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 16 Feb 2015 14:48:56 +0300 Subject: RFR: JDK-8019361: [TESTBUG] Conflicting collector combinations in option list for GC tests Message-ID: <54E1D928.8060607@oracle.com> Hi, team Here is very simple patch removing @ignore tag from test which was ignored due conflicting options which now has been checked by already added @required tag: webrev: http://cr.openjdk.java.net/~azakharov/8019361/webrev/ testbug: https://bugs.openjdk.java.net/browse/JDK-8019361 Thanks. From dmitry.fazunenko at oracle.com Mon Feb 16 11:59:54 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 16 Feb 2015 14:59:54 +0300 Subject: RFR: JDK-8019361: [TESTBUG] Conflicting collector combinations in option list for GC tests In-Reply-To: <54E1D928.8060607@oracle.com> References: <54E1D928.8060607@oracle.com> Message-ID: <54E1DBBA.2020905@oracle.com> Hi Andrey, the change to the TestDynShrinkHeap.java looks good. But JDK-8019361 looks like a wrong number. It must be JDK-8051984, I think. If so, what about other sources listed in the description: ./test/gc/arguments/TestParallelHeapSizeFlags.java ./test/gc/arguments/TestUseCompressedOopsErgo.java ./test/gc/g1/TestHumongousShrinkHeap.java are they already fixed? Thanks, Dima On 16.02.2015 14:48, Andrey Zakharov wrote: > Hi, team > Here is very simple patch removing @ignore tag from test which was > ignored due conflicting options which now has been checked by already > added @required tag: > > webrev: > http://cr.openjdk.java.net/~azakharov/8019361/webrev/ > > testbug: > https://bugs.openjdk.java.net/browse/JDK-8019361 > > Thanks. From bengt.rutisson at oracle.com Mon Feb 16 12:34:27 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Feb 2015 13:34:27 +0100 Subject: RFR: JDK-8019361: [TESTBUG] Conflicting collector combinations in option list for GC tests In-Reply-To: <54E1D928.8060607@oracle.com> References: <54E1D928.8060607@oracle.com> Message-ID: <54E1E3D3.3010405@oracle.com> Hi Andrey, On 2015-02-16 12:48, Andrey Zakharov wrote: > Hi, team > Here is very simple patch removing @ignore tag from test which was > ignored due conflicting options which now has been checked by already > added @required tag: > > webrev: > http://cr.openjdk.java.net/~azakharov/8019361/webrev/ > > testbug: > https://bugs.openjdk.java.net/browse/JDK-8019361 Why did you change the static import of com.oracle.java.testlibrary.Asserts? Seems unrelated to the @ignore change and I don't think there is a reason for it either. We use static import of the asserts a lot in our test code. Thanks, Bengt > > Thanks. From volker.simonis at gmail.com Mon Feb 16 13:39:14 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Feb 2015 14:39:14 +0100 Subject: RFR(M): 8068883: Remove disabling of warning "C4355: 'this' : used in base member initializer list" In-Reply-To: <59BD7FCE-B49F-42B2-8263-8BD784944055@oracle.com> References: <0459695D-FA49-4233-BE79-EBEE83720FC7@oracle.com> <59BD7FCE-B49F-42B2-8263-8BD784944055@oracle.com> Message-ID: By the way, is it OK if I close "8068883: Remove disabling of warning "C4355: 'this' : used in base member initializer list" as "will not fix" and add a link to this mail-thread. I can also add a link to the new bug you've created to the comments section. Regards, Volker On Mon, Feb 16, 2015 at 8:59 AM, Kim Barrett wrote: > On Jan 14, 2015, at 3:50 PM, Kim Barrett wrote: >> >> On Jan 14, 2015, at 11:28 AM, Volker Simonis wrote: >>>>> I've additionally also removed the Visual Studio compiler macro which >>>>> disable the warning "C4786:'identifier' : identifier was truncated to >>>>> 'number' characters in the debug information." because as far as I >>>>> could see, this was only relevant up to Visual Studio 6.0 and I hope >>>>> nobody will ever compile the HotSpot with that compiler any more(see >>>>> http://support.microsoft.com/kb/195386). >>>> >>>> This seems like a worthwhile change, independent of the other changes >>>> being proposed. Could this be separated out. >>>> >>> >>> Sure, if we decide not to push this patch we can still just remove >>> that pragma in a separate change. >> >> [?] If you (Volker) don't want >> to deal with the extra overhead, I'll take care of it. > > Finally getting around to following up on this bit of the discussion. > > https://bugs.openjdk.java.net/browse/JDK-8073188 > > So it might get cleaned up eventually. > From andrey.x.zakharov at oracle.com Mon Feb 16 15:24:06 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 16 Feb 2015 18:24:06 +0300 Subject: RFR: 8051984: @ignore should be placed after @test Message-ID: <54E20B96.90509@oracle.com> Hi > But JDK-8019361 looks like a wrong number. It must be JDK-8051984, I think. I'm wrongly got reason of ignore bug for RFR. Thanks, Dima. webrev: http://cr.openjdk.java.net/~azakharov/8051984/webrev// /bug: https://bugs.openjdk.java.net/browse/JDK-8051984 > If so, what about other sources listed in the description: > ./test/gc/arguments/TestParallelHeapSizeFlags.java > ./test/gc/arguments/TestUseCompressedOopsErgo.java > ./test/gc/g1/TestHumongousShrinkHeap.java Its already fixed either by removing @ignore either by inserting @requires / / > Why did you change the static import of > com.oracle.java.testlibrary.Asserts? Seems unrelated to the @ignore > change and I don't think there is a reason for it either. We use static > import of the asserts a lot in our test code. > > Thanks, > Bengt > > >/ > />/ Thanks./ There is nothing especial in import static here, its only serves to reduce Asserts package names in code, but it also leads to less readability and question like "what assertLessThan comes from?". Asserts.assertLessThan is better - it doesn't junk global namespace. In only this case - its only code style question. If you have any other conserns about this, please tell me. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Feb 16 15:41:28 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Feb 2015 16:41:28 +0100 Subject: RFR: 8051984: @ignore should be placed after @test In-Reply-To: <54E20B96.90509@oracle.com> References: <54E20B96.90509@oracle.com> Message-ID: <54E20FA8.4000302@oracle.com> Hi Andrey, On 16/02/15 16:24, Andrey Zakharov wrote: > Hi >> But JDK-8019361 looks like a wrong number. It must be JDK-8051984, I think. > > I'm wrongly got reason of ignore bug for RFR. Thanks, Dima. > > webrev: > http://cr.openjdk.java.net/~azakharov/8051984/webrev// > > /bug: > https://bugs.openjdk.java.net/browse/JDK-8051984 > >> If so, what about other sources listed in the description: >> ./test/gc/arguments/TestParallelHeapSizeFlags.java >> ./test/gc/arguments/TestUseCompressedOopsErgo.java >> ./test/gc/g1/TestHumongousShrinkHeap.java > Its already fixed either by removing @ignore either by inserting @requires > / > / >> Why did you change the static import of >> com.oracle.java.testlibrary.Asserts? Seems unrelated to the @ignore >> change and I don't think there is a reason for it either. We use static >> import of the asserts a lot in our test code. >> >> Thanks, >> Bengt >> >> >/ >> />/ Thanks./ > > There is nothing especial in import static here, its only serves to > reduce Asserts package names in code, but it also leads to less > readability and question like "what assertLessThan comes from?". > Asserts.assertLessThan is better - it doesn't junk global namespace. > In only this case - its only code style question. If you have any > other conserns about this, please tell me. For people reading the hotspots tests a lot I think assertLessThan() is more readable than Asserts.assertLessThan(). Please don't change this for this test only. If you feel strongly about this issue I think you should bring it up for a wider discussion so we can agree on a guideline for how to use it. Right now it just seems like a completely unrelated change that is not necessary to solve your bug. Thanks, Bengt > > > Thanks. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.x.zakharov at oracle.com Mon Feb 16 16:07:41 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 16 Feb 2015 19:07:41 +0300 Subject: RFR: 8051984: @ignore should be placed after @test In-Reply-To: <54E20FA8.4000302@oracle.com> References: <54E20B96.90509@oracle.com> <54E20FA8.4000302@oracle.com> Message-ID: <54E215CD.8010704@oracle.com> 16.02.2015 18:41, Bengt Rutisson ?????: > > Hi Andrey, > > On 16/02/15 16:24, Andrey Zakharov wrote: >> Hi >>> But JDK-8019361 looks like a wrong number. It must be JDK-8051984, I think. >> >> I'm wrongly got reason of ignore bug for RFR. Thanks, Dima. >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8051984/webrev// >> >> /bug: >> https://bugs.openjdk.java.net/browse/JDK-8051984 >> >>> If so, what about other sources listed in the description: >>> ./test/gc/arguments/TestParallelHeapSizeFlags.java >>> ./test/gc/arguments/TestUseCompressedOopsErgo.java >>> ./test/gc/g1/TestHumongousShrinkHeap.java >> Its already fixed either by removing @ignore either by inserting >> @requires >> / >> / >>> Why did you change the static import of >>> com.oracle.java.testlibrary.Asserts? Seems unrelated to the @ignore >>> change and I don't think there is a reason for it either. We use static >>> import of the asserts a lot in our test code. >>> >>> Thanks, >>> Bengt >>> >>> >/ >>> />/ Thanks./ >> >> There is nothing especial in import static here, its only serves to >> reduce Asserts package names in code, but it also leads to less >> readability and question like "what assertLessThan comes from?". >> Asserts.assertLessThan is better - it doesn't junk global namespace. >> In only this case - its only code style question. If you have any >> other conserns about this, please tell me. > > For people reading the hotspots tests a lot I think assertLessThan() > is more readable than Asserts.assertLessThan(). Please don't change > this for this test only. If you feel strongly about this issue I think > you should bring it up for a wider discussion so we can agree on a > guideline for how to use it. Right now it just seems like a completely > unrelated change that is not necessary to solve your bug. Ok. At least I must change Asserts.* to Asserts.assertLessThan; webrev: http://cr.openjdk.java.net/~azakharov/8051984/webrev.02/ Just for information: in src/hs-gc/hotspot/test grep 'import com.oracle.java.testlibrary.Asserts.' -R ./ --exclude-dir=.hg | wc -l 56 grep 'import static com.oracle.java.testlibrary.Asserts.' -R ./ --exclude-dir=.hg | wc -l 66 grep 'import static com.oracle.java.testlibrary.Asserts.' -R ./gc --exclude-dir=.hg | wc -l 17 grep 'import com.oracle.java.testlibrary.Asserts.' -R ./gc --exclude-dir=.hg | wc -l 5 Thanks. > > Thanks, > Bengt > >> >> >> Thanks. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon Feb 16 16:33:29 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 16 Feb 2015 16:33:29 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <54DBE707.4020401@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> Hi Jon, thanks for looking at this change! It's not that easy as just aligning to vm_page_size, but I can use CollectorPolicy::compute_heap_alignment(): http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ Best regards, Goetz. From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jon Masamitsu Sent: Donnerstag, 12. Februar 2015 00:35 To: hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Goetz, Could you have used page alignment to determine the new expected sizes? For example, instead of 987 // Calculate what we expect the flag to be. 988 flag_value = adapted_InitialHeapSize - MaxNewSize; 989 verify_old_initial(flag_value); expected_old_initial = align_size_up(flag_value, os::vm_page_size()) verify_old_initial(expected_old_initial) Jon On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Feb 16 16:37:49 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 16 Feb 2015 11:37:49 -0500 Subject: RFR(M): 8068883: Remove disabling of warning "C4355: 'this' : used in base member initializer list" In-Reply-To: References: <0459695D-FA49-4233-BE79-EBEE83720FC7@oracle.com> <59BD7FCE-B49F-42B2-8263-8BD784944055@oracle.com> Message-ID: On Feb 16, 2015, at 8:39 AM, Volker Simonis wrote: > > By the way, is it OK if I close "8068883: Remove disabling of warning > "C4355: 'this' : used in base member initializer list" as "will not > fix" and add a link to this mail-thread. I can also add a link to the > new bug you've created to the comments section. That?s fine with me. Thanks. From sangheon.kim at oracle.com Mon Feb 16 17:17:40 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Mon, 16 Feb 2015 09:17:40 -0800 Subject: RFR(xs): 8073115: assert(_covered_region.contains(p)) needs better error messages In-Reply-To: <54E19853.1070502@oracle.com> References: <54DD9FA0.2000107@oracle.com> <54DDBEB4.2000909@oracle.com> <54DE3754.6040409@oracle.com> <54DE6890.5050704@oracle.com> <54E19853.1070502@oracle.com> Message-ID: <54E22634.5010605@oracle.com> Hi StefanK, Bengt and Jesper, Thank you for the reviewing this. Sangheon On 02/15/2015 11:12 PM, Bengt Rutisson wrote: > > Hi Sangheon, > > On 2015-02-13 22:11, Sangheon Kim wrote: >> Hi All, >> >> Sorry for sending many emails for this simple fix. >> After some discussion with StefanK, I decided to add a macro for this >> assert. >> >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8073115/webrev.01/ > > Looks even better. :) > > Thanks, > Bengt > >> >> Thanks, >> Sangheon >> >> On 02/13/2015 09:41 AM, Sangheon Kim wrote: >>> Hi StefanK, >>> >>> Thanks for reviewing this and please see inline. >>> >>> On 02/13/2015 01:07 AM, Stefan Karlsson wrote: >>>> Hi Sangheon, >>>> >>>> On 2015-02-13 07:54, Sangheon Kim wrote: >>>>> Hi All, >>>>> >>>>> Please review this small enhancement for better error messages when assert fails. >>>>> This change would be helpful forJDK-8071930 which is hard to reproduce. >>>>> >>>>> I will need a sponsor for this change. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8073115 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/ >>>> >>>> http://cr.openjdk.java.net/~sangheki/8073115/webrev.00/src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp.udiff.html >>>> >>>> You are duplicating the same assert three times. Could you create a >>>> new define, say #define assert_covered_region_contains(addr) ..., >>>> and remove the duplication? This will also have the benefit of >>>> lowering the line noise in the functions you change. >>> Basically I agree with you. >>> But in this case I think the benefit of macro is limited to reduce 3 >>> lines than current proposal. >>> Unless this macro moves to general header file, its usage would be >>> limited. >>> So let me skip adding a new macro at this time. >>> >>> Thanks, >>> Sangheon >>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Sangheon >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Feb 16 19:41:09 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Feb 2015 20:41:09 +0100 Subject: RFR: 8051984: @ignore should be placed after @test In-Reply-To: <54E215CD.8010704@oracle.com> References: <54E20B96.90509@oracle.com> <54E20FA8.4000302@oracle.com> <54E215CD.8010704@oracle.com> Message-ID: <54E247D5.6020106@oracle.com> Hi again, On 16/02/15 17:07, Andrey Zakharov wrote: > > 16.02.2015 18:41, Bengt Rutisson ?????: >> >> Hi Andrey, >> >> On 16/02/15 16:24, Andrey Zakharov wrote: >>> Hi >>>> But JDK-8019361 looks like a wrong number. It must be JDK-8051984, I think. >>> >>> I'm wrongly got reason of ignore bug for RFR. Thanks, Dima. >>> >>> webrev: >>> http://cr.openjdk.java.net/~azakharov/8051984/webrev// >>> >>> /bug: >>> https://bugs.openjdk.java.net/browse/JDK-8051984 >>> >>>> If so, what about other sources listed in the description: >>>> ./test/gc/arguments/TestParallelHeapSizeFlags.java >>>> ./test/gc/arguments/TestUseCompressedOopsErgo.java >>>> ./test/gc/g1/TestHumongousShrinkHeap.java >>> Its already fixed either by removing @ignore either by inserting >>> @requires >>> / >>> / >>>> Why did you change the static import of >>>> com.oracle.java.testlibrary.Asserts? Seems unrelated to the @ignore >>>> change and I don't think there is a reason for it either. We use static >>>> import of the asserts a lot in our test code. >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >/ >>>> />/ Thanks./ >>> >>> There is nothing especial in import static here, its only serves to >>> reduce Asserts package names in code, but it also leads to less >>> readability and question like "what assertLessThan comes from?". >>> Asserts.assertLessThan is better - it doesn't junk global namespace. >>> In only this case - its only code style question. If you have any >>> other conserns about this, please tell me. >> >> For people reading the hotspots tests a lot I think assertLessThan() >> is more readable than Asserts.assertLessThan(). Please don't change >> this for this test only. If you feel strongly about this issue I >> think you should bring it up for a wider discussion so we can agree >> on a guideline for how to use it. Right now it just seems like a >> completely unrelated change that is not necessary to solve your bug. > Ok. At least I must change Asserts.* to Asserts.assertLessThan; I still find it odd to do this as part of this change. But ok. > > webrev: > http://cr.openjdk.java.net/~azakharov/8051984/webrev.02/ Looks ok. Reviewed. > > Just for information: > in src/hs-gc/hotspot/test > > grep 'import com.oracle.java.testlibrary.Asserts.' -R ./ > --exclude-dir=.hg | wc -l > 56 > > grep 'import static com.oracle.java.testlibrary.Asserts.' -R ./ > --exclude-dir=.hg | wc -l > 66 > > grep 'import static com.oracle.java.testlibrary.Asserts.' -R ./gc > --exclude-dir=.hg | wc -l > 17 > > grep 'import com.oracle.java.testlibrary.Asserts.' -R ./gc > --exclude-dir=.hg | wc -l > 5 Right, so static import is the more common way for importing the asserts. There are also the JFR tests for hotspot: $ grep -r 'import static jrockit.Asserts' jdk/test/closed/com/oracle/jfr/gc/ | wc -l 36 $ grep -r 'import jrockit.Asserts' jdk/test/closed/com/oracle/jfr/gc/ | wc -l 3 Thanks, Bengt > > Thanks. > >> >> Thanks, >> Bengt >> >>> >>> >>> Thanks. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Feb 16 23:16:38 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 16 Feb 2015 18:16:38 -0500 Subject: RFR: 8069016: Add BarrierSet downcast support Message-ID: Please review this change that ensures all barrier set downcasts are checked when running in debug mode. This is a step toward some cleanups and changes to the barrier set class hierarchy, improving error checking and making it easier to find places where assumptions are being made that would be invalidated by changes. I will need a sponsor for this change. CR: https://bugs.openjdk.java.net/browse/JDK-8069016 Webrev: http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00 Changeset includes * New FakeRttiSupport utility class template. This provides some infrastructure for performing the checks. It is intended to ease similar changes in some other class hierarchies where ad hoc checking or unchecked downcasts are common, such as the CollectedHeap hierarchy. * Re-implementation of BarrierSet's "fake RTTI" to use FakeRttiSupport. As part of this, BarrierSet::is_a() is now just an integer bit test rather than a virtual function that needs to walk up the class hierarchy. * Adds barrier_set_cast function template, which uses the improved is_a() test to assert the validity of the conversion. * Adds BarrierSet::CardTableForRS barrier set name tag, so that all existing classes have an associated tag. * Changes all C-style barrier set downcasts to use barrier_set_cast. In most cases, this is just a mechanical translation. In some cases some existing checks have been eliminated in favor of the check made by the new mechanism. In a few places more extensive changes have been made, as detailed below: ** In various g1_write_barrier_post() implementations, downcast to G1SATBCardTableLoggingModRefBS rather than G1SATBCardTableModRefBS, since the code being generated includes logging. ** In PSMarkSweep::invoke_no_policy(), don't bother conditionalizing clear/invalidate of barrier set on whether the bs is a modrefbs; it always will be for parallel scavenge collector. Similarly in PSParallelCompact::post_compact(). ** For VerifyLiveClosure constructor initialization of _bs member, just use barrier_set_cast of the heap's barrier. If the previous is_a conditionalization failed it would just lead to a later segfault when attempting to dereference through the NULL _bs member. Testing: JPRT, local JTREG of test/[closed]/{gc,runtime}, local RefWorkload using CMS, G1, ParallelOld From thomas.schatzl at oracle.com Tue Feb 17 08:35:09 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Feb 2015 09:35:09 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <54D11432.5050006@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> Message-ID: <1424162109.3163.2.camel@oracle.com> Hi all, On Tue, 2015-02-03 at 10:32 -0800, Jon Masamitsu wrote: > On 02/03/2015 02:27 AM, Thomas Schatzl wrote: > > Hi Jon, > > > > thanks for the comments. I incorporated all of them in the latest > > webrev at > > > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1/ (full) > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.0_to_1/ (diff) That webrev contains a bug that I found shortly after, the roundto() method just rounds but does not divide :/ Please re-review the fix for that. After fixing this I went through another big round of testing (perf + lots of aurora tests) to make sure that the change is finally good. Here are the changesets: http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2/ (full) http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1_to_2/ (diff) Sorry for the issues, Thomas From thomas.schatzl at oracle.com Tue Feb 17 09:02:57 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Feb 2015 10:02:57 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing Message-ID: <1424163777.3163.4.camel@oracle.com> Hi all, can I have reviews for the following change that adds detailed logging for the ext root scan phase of the g1 collector? If you add -XX:+UnlockExperimentalOptions -XX:G1LogLevel=finest, the "Ext Root Scan" phase is now split up into several sub-categories, e.g. instead of [Parallel Time: ...] [GC Worker Start... Min: ... Avg: ... Max: ... ] [Ext root scan... Min: ... Avg: ... Max: ... ] [Update RS... Min: ... Avg: ... Max: ... ] You get a detailed breakdown like this: [Parallel Time: ...] [GC Worker Start... Min: ... Avg: ... Max: ... ] [Ext root scan... Min: ... Avg: ... Max: ... ] [Thread Roots: Min: ... Avg: ... Max: ... ] [StringTable Roots: Min: ... Avg: ... Max: ... ] [same for Universe Roots, JNI Handles Roots, ObjectSynchronizer Roots, FlatProfiler Roots, Management Roots, SystemDictionary Roots, CLDG Roots, JVMTI Roots, CodeCache Roots, Filter SATB Roots, CM RefProcessor Roots, Wait for Strong CLD] [Weak CLD Roots: Min: ... Avg: ... Max: ... ] [Update RS... Min: ... Avg: ... Max: ... ] I intentionally only enabled this with -XX:G1LogLevel=finest because I think typically this information would just increase the log file without much additional information. Unfortunately there is no log level between finer and finest that could be used to show this information without the per-thread timing, which would cut the number of lines in half at least. There is the option of adding another global option (some diagnostic option maybe?), but I do think its use is limited (i.e. only after you notice that "Ext Root Scan" grows over time) so you do not want all those lines of information using only G1LogLevel=finer/PrintGCDetails. It would be trivial to change either way. E.g. something like [Parallel Time: ...] [GC Worker Start... Min: ... Avg: ... Max: ... ] [Ext root scan... Min: ... Avg: ... Max: ... ] [Thread Roots:... Min: ... Avg: ... Max: ... ] [StringTable Roots:... Min: ... Avg: ... Max: ... ] [same for Universe Roots, JNI Handles Roots, ObjectSynchronizer Roots, FlatProfiler Roots, Management Roots, SystemDictionary Roots, CLDG Roots, JVMTI Roots, CodeCache Roots, Filter SATB Roots, CM RefProcessor Roots, Wait for Strong CLD] [Weak CLD Roots: Min: ... Avg: ... Max: ... ] [Update RS... Min: ... Avg: ... Max: ... ] These messages help a lot in diagnosing the type of root leaks in root processing. JIRA: https://bugs.openjdk.java.net/browse/JDK-8027962 Webrev: http://cr.openjdk.java.net/~tschatzl/8027962/webrev/ Testing: jprt, test case Thanks, Thomas From bengt.rutisson at oracle.com Tue Feb 17 15:03:35 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 17 Feb 2015 16:03:35 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <1424163777.3163.4.camel@oracle.com> References: <1424163777.3163.4.camel@oracle.com> Message-ID: <54E35847.8070708@oracle.com> Hi Thomas, Thanks for splitting the root scanning logging up. This will be very useful. On 2015-02-17 10:02, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following change that adds detailed logging > for the ext root scan phase of the g1 collector? > > If you add -XX:+UnlockExperimentalOptions -XX:G1LogLevel=finest, the > "Ext Root Scan" phase is now split up into several sub-categories, e.g. > instead of > > [Parallel Time: ...] > [GC Worker Start... > Min: ... Avg: ... Max: ... ] > [Ext root scan... > Min: ... Avg: ... Max: ... ] > [Update RS... > Min: ... Avg: ... Max: ... ] > > You get a detailed breakdown like this: > > [Parallel Time: ...] > [GC Worker Start... > Min: ... Avg: ... Max: ... ] > [Ext root scan... > Min: ... Avg: ... Max: ... ] > [Thread Roots: > Min: ... Avg: ... Max: ... ] > [StringTable Roots: > Min: ... Avg: ... Max: ... ] > [same for Universe Roots, JNI Handles Roots, ObjectSynchronizer > Roots, FlatProfiler Roots, Management Roots, SystemDictionary Roots, > CLDG Roots, JVMTI Roots, CodeCache Roots, Filter SATB Roots, CM > RefProcessor Roots, Wait for Strong CLD] > [Weak CLD Roots: > Min: ... Avg: ... Max: ... ] > [Update RS... > Min: ... Avg: ... Max: ... ] > > I intentionally only enabled this with -XX:G1LogLevel=finest because I > think typically this information would just increase the log file > without much additional information. > > Unfortunately there is no log level between finer and finest that could > be used to show this information without the per-thread timing, which > would cut the number of lines in half at least. > There is the option of adding another global option (some diagnostic > option maybe?), but I do think its use is limited (i.e. only after you > notice that "Ext Root Scan" grows over time) so you do not want all > those lines of information using only G1LogLevel=finer/PrintGCDetails. > > It would be trivial to change either way. > > E.g. something like > > [Parallel Time: ...] > [GC Worker Start... Min: ... Avg: ... Max: ... ] > [Ext root scan... Min: ... Avg: ... Max: ... ] > [Thread Roots:... Min: ... Avg: ... Max: ... ] > [StringTable Roots:... Min: ... Avg: ... Max: ... ] > [same for Universe Roots, JNI Handles Roots, ObjectSynchronizer > Roots, FlatProfiler Roots, Management Roots, SystemDictionary Roots, > CLDG Roots, JVMTI Roots, CodeCache Roots, Filter SATB Roots, CM > RefProcessor Roots, Wait for Strong CLD] > [Weak CLD Roots: Min: ... Avg: ... Max: ... ] > [Update RS... Min: ... Avg: ... Max: ... ] > > These messages help a lot in diagnosing the type of root leaks in root > processing. > > JIRA: > https://bugs.openjdk.java.net/browse/JDK-8027962 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8027962/webrev/ I think it would be good if we can make sure that the GC code does not leak in to runtime/timer. Not sure exactly how, but it would be good to try some change out to avoid this dependency. TestGCLogMessages.java I find it a little confusing that the instance variable messages has the same name as the parameter to the method checkMessagesAtLevel(). Could you change the name of one of them? 47 LogMessageWithLevel messages[] = new LogMessageWithLevel[] { 79 void checkMessagesAtLevel(OutputAnalyzer output, LogMessageWithLevel messages[], int level) throws Exception { Also, what do you think about using an enum instead of using the integer values 2, 3 etc for levels? Thanks, Bengt > Testing: > jprt, test case > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Feb 17 15:18:15 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Feb 2015 16:18:15 +0100 Subject: RFR (S): 8058446: G1 Hot card cache should use ArrayAllocator to allocate the cache array Message-ID: <1424186295.3163.9.camel@oracle.com> Hi all, can I have reviews for this small change (or feedback): it changes the hot card cache array that holds the hot cards from always using C heap to an ArrayAllocator. This is because the hot card cache may be specified to be quite large (up to 2^31 entries), which will result in native OOME at startup. The fix is to use an ArrayAllocator for larger hot card caches. Another potential improvement would be to decrease the maximum allowed HCC size to something more reasonable - however I have no idea what this size could be. One comment in the CR suggests to add a test that adds testing of the boundary values. However, I do not see how you could create a stable test for that, given that that test would somehow need to guess a maximum reasonable value to not crash on any machines. I left a test out for now as the change itself is pretty simple. A few values are already checked in the TestAuxiliaryData* tests too. CR: https://bugs.openjdk.java.net/browse/JDK-8058446 Webrev: http://cr.openjdk.java.net/~tschatzl/8058446/webrev/ Testing: jprt Thanks, Thomas From sergei.kovalev at oracle.com Tue Feb 17 16:00:14 2015 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 17 Feb 2015 19:00:14 +0300 Subject: RFR(S): 8067162: runtime/SharedArchiveFile tests fail on compact profiles In-Reply-To: <54DE150B.10206@oracle.com> References: <54DE150B.10206@oracle.com> Message-ID: <54E3658E.7080708@oracle.com> Hi all, Please take a look. On 13.02.15 18:15, Sergei Kovalev wrote: > Hello All, > > Please review the fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067162 > Webrev: http://cr.openjdk.java.net/~skovalev/8067162/webrew.00/ > > Synopsis: Test failed on compact profiles with message: > > Exception in thread "main" java.lang.RuntimeException: Utilization for > one of the regions is below a threshold of 30% > > Having no GUI classes we cannot utilize enough part of region. > > Solution: Solution: exclude tests from execution on compact profiles. > Modified TEST.group file. Tests added to group: needs_jre. > > Tested locally with showGroups jtreg mechanism. > -- With best regards, Sergei From mikael.gerdin at oracle.com Tue Feb 17 16:13:14 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 17 Feb 2015 17:13:14 +0100 Subject: RFR (S): 8058446: G1 Hot card cache should use ArrayAllocator to allocate the cache array In-Reply-To: <1424186295.3163.9.camel@oracle.com> References: <1424186295.3163.9.camel@oracle.com> Message-ID: <54E3689A.8060800@oracle.com> Hi Thomas, On 2015-02-17 16:18, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change (or feedback): it changes the > hot card cache array that holds the hot cards from always using C heap > to an ArrayAllocator. > > This is because the hot card cache may be specified to be quite large > (up to 2^31 entries), which will result in native OOME at startup. > > The fix is to use an ArrayAllocator for larger hot card caches. > > Another potential improvement would be to decrease the maximum allowed > HCC size to something more reasonable - however I have no idea what this > size could be. > > One comment in the CR suggests to add a test that adds testing of the > boundary values. However, I do not see how you could create a stable > test for that, given that that test would somehow need to guess a > maximum reasonable value to not crash on any machines. > > I left a test out for now as the change itself is pretty simple. > > A few values are already checked in the TestAuxiliaryData* tests too. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8058446 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8058446/webrev/ Looks fine to me. /Mikael > Testing: > jprt > > Thanks, > Thomas > > From jesper.wilhelmsson at oracle.com Tue Feb 17 16:17:03 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Feb 2015 17:17:03 +0100 Subject: RFR (S): 8058446: G1 Hot card cache should use ArrayAllocator to allocate the cache array In-Reply-To: <1424186295.3163.9.camel@oracle.com> References: <1424186295.3163.9.camel@oracle.com> Message-ID: <54E3697F.9070202@oracle.com> Looks good! /Jesper Thomas Schatzl skrev den 17/2/15 16:18: > Hi all, > > can I have reviews for this small change (or feedback): it changes the > hot card cache array that holds the hot cards from always using C heap > to an ArrayAllocator. > > This is because the hot card cache may be specified to be quite large > (up to 2^31 entries), which will result in native OOME at startup. > > The fix is to use an ArrayAllocator for larger hot card caches. > > Another potential improvement would be to decrease the maximum allowed > HCC size to something more reasonable - however I have no idea what this > size could be. > > One comment in the CR suggests to add a test that adds testing of the > boundary values. However, I do not see how you could create a stable > test for that, given that that test would somehow need to guess a > maximum reasonable value to not crash on any machines. > > I left a test out for now as the change itself is pretty simple. > > A few values are already checked in the TestAuxiliaryData* tests too. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8058446 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8058446/webrev/ > Testing: > jprt > > Thanks, > Thomas > > From jon.masamitsu at oracle.com Tue Feb 17 18:56:50 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 17 Feb 2015 10:56:50 -0800 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> Message-ID: <54E38EF2.90304@oracle.com> On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: > > Hi Jon, > > thanks for looking at this change! > > It's not that easy as just aligning to vm_page_size, but I can use > > CollectorPolicy::compute_heap_alignment(): > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ > > Please revert to the original order of these lines unless it makes a difference. 990 set_basic_flag_values(); 991 flag_value = 30 * M; Could you define a variable to hold the heap alignment? size_t heap_alignment = CollectorPolicy::compute_heap_alignment() just to make it a little more readable. Should the 30*M be aligned? What is the 20*m? Could you assign it to a variable with a descriptive name? Jon > > Best regards, > > Goetz. > > *From:*hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] > *On Behalf Of * Jon Masamitsu > *Sent:* Donnerstag, 12. Februar 2015 00:35 > *To:* hotspot-gc-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Goetz, > > Could you have used page alignment to determine the > new expected sizes? > > For example, instead of > > 987 // Calculate what we expect the flag to be. > 988 flag_value = adapted_InitialHeapSize - MaxNewSize; > 989 verify_old_initial(flag_value); > > expected_old_initial = align_size_up(flag_value, os::vm_page_size()) > verify_old_initial(expected_old_initial) > > Jon > > On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: > > Hi, > > could someone please have a look at this change? > > It's really not that big. > > GC-folks maybe? > > Thanks, > > Goetz. > > *From:*Lindenmaier, Goetz > *Sent:* Freitag, 30. Januar 2015 10:36 > *To:* hotspot-dev Source Developers > *Subject:* RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Hi, > > this fixes a final problem with 64-bit page size in the jtreg tests. > > It addresses the internal VM tests of the collector policies. > > Those tests set a row of fixed flag values, and one special value > to test. > > Then they call the heap ergonomics and check the expected result > of the > > special value. > > With 64K page size, the heap ergonomics adapt more values, > breaking the tests. > > Wrt. the adapted flag values the tests are correct though. > > This change makes the expected values depend on the adapted flags, > and the > > tests pass. They only depend on adapted flags that are not subject > of the > > corresponding test. > > Please review this test. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8071822 > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Tue Feb 17 21:08:43 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Feb 2015 22:08:43 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54DDF4F8.2080508@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> <54DDF4F8.2080508@oracle.com> Message-ID: <54E3ADDB.1090106@oracle.com> Hi Mikael, Thanks for reviewing! I agree with your comments and has fixed them in this new webrev: cr.openjdk.java.net/~jwilhelm/8061802/webrev.03 Thanks, /Jesper Mikael Gerdin skrev den 13/2/15 13:58: > Hi Jesper, > > On 2015-02-10 21:38, Jesper Wilhelmsson wrote: >> Hi Kim, >> >> Thanks for taking another close look at this change! >> >> Some of these issues are the result of this being a part of a bigger >> change, but I have addressed your concerns to make sure this >> intermediate version is of decent quality even without the following >> cleanups. (Even though I hope we will get the rest in asap. Those will >> be a lot easier to review). >> >> For example anything related to levels and _n_gens will be removed in >> later patches when the entire level concept is removed. >> >> A new webrev is available here: >> http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.02/ > > Overall I think this is a good incremental cleanup. > > I have some requests to make it easier to reason about the code though: > > if (!(max_level == 1 && full && _old_gen->full_collects_younger_generations()) && > _young_gen->should_collect(full, size, is_tlab)) > > is a bit of a mouthful, can you please break out parts of it into a boolean? > > bool old_collects_young = (max_level == 1 && full && > _old_gen->full_collects_younger_generations()) > > if (old_collects_young && _young_gen->should_collect...) > > > The must_restore_marks_for_biased_locking is even more confusing. > > Its initial value is "false", DefNew returns false for > performs_in_place_marking() so the if block there is essentially dead code. > > For the old generation you pass !must_restore_marks.. to collect_generation in > order to trigger the preserving of marks if it was not performed completed by > the young gc but it's then immediately set to true after the call to > collect_generation in order to get the code to properly restore the marks. > > I suggest that you assert that young gens always return false for > performs_in_place_marking() and either pass literal "true" or "false" to > collect_generation, or perhaps even call BiasedLocking::preserve_marks() before > calling collect_generation for old gen and just get rid of the parameter. > > You would still need to keep the boolean variable in order to know if you should > restore the marks, but that's fine I think. > > /Mikael > > >> >> Some replies inline. >> >> >> Kim Barrett skrev den 9/2/15 21:05: >>> On Jan 29, 2015, at 5:45 AM, Jesper Wilhelmsson >>> wrote: >>>> >>>> Hi, >>>> >>>> Please review this second attempt to remove the generations array. >>>> >>>> There were two bugs that caused this patch to be backed out the last >>>> time: >>>> >>>> 1. Collection of the old generation was always run even if the young >>>> collection freed up enough to satisfy the allocation need. This was >>>> due to an unexpected use of the size variable and stopped working >>>> when the code that changed the variable was broken out into a >>>> separate function. >>>> >>>> 2. The new _young_generation and _old_generation fields was missing >>>> from the declarations in vm_structs.cpp. Cut'n'paste error when the >>>> original huge change was split into smaller parts for easier review. >>>> >>>> I have resolved these issues. I also moved the >>>> BiasedLocking::preserve_marks() since the previous change didn't >>>> preserve exactly the same behavior. And I added a comment in a test >>>> that caused some issues when I was debugging this. >>>> >>>> Testing: AdHoc run of the nightly GC tests, JPRT, and JTREG >>>> >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8061802 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01/ >>>> >>>> I also made an incremental webrev based on the old patch applied to a >>>> fresh version of the GC repo. Please note that the old patch do not >>>> apply cleanly to a current GC repo, but the changes in the >>>> incremental diff should cover what has been changed with regards to >>>> this RFE. Please refer to the full webrevs if in doubt. >>>> >>>> Incremental webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8061802/webrev.01.incremental/ >>>> >>>> Old (buggy) webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8055702/webrev.01/ >>>> >>>> >>>> For reference, as I mentioned above the original huge change was >>>> split into several smaller parts. This is the first of those parts. >>>> The other can be found here: >>>> >>>> http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.01/ >>>> >>>> Please note that these are the old patches that applies on top of the >>>> old (buggy) patch above. They will not apply cleanly on top of the >>>> new patch. I'll update these once the first part is finalized. >>>> >>>> Thanks, >>>> /Jesper >>> >>> ------------------------------------------------------------------------------ >>> >>> Throughout, copyrights need to be updated. >>> >>> ------------------------------------------------------------------------------ >>> >>> agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java >>> 71 public Generation getGen(int i) { >>> 72 if (Assert.ASSERTS_ENABLED) { >>> 73 Assert.that((i >= 0) && (i < nGens()), "Index " + i + >>> 74 " out of range (should be between 0 and " + >>> nGens() + ")"); >>> 75 } >>> 76 >>> 77 switch (i) { >>> 78 case 0: >>> 79 return genFactory.newObject(youngGenField.getAddress()); >>> 80 case 1: >>> 81 return genFactory.newObject(oldGenField.getAddress()); >>> 82 default: >>> 83 // no generation for i, and assertions disabled. >>> 84 return null; >>> 85 } >>> 86 } >>> >>> With the replacement of the old code with the switch statement, the >>> assertion seems both poorly placed and not entirely sufficient. The >>> code is now assuming that nGens() == 2, for example. >> >> I updated the assertion and removed the usage of nGens() in this method. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> 131 ReservedSpace young_rs = >>> heap_rs.first_part(_gen_specs[0]->max_size(), false, false); >>> 132 _young_gen = _gen_specs[0]->init(young_rs, 0, rem_set()); >>> 133 heap_rs = heap_rs.last_part(_gen_specs[0]->max_size()); >>> 134 >>> 135 ReservedSpace old_rs = >>> heap_rs.first_part(_gen_specs[1]->max_size(), false, false); >>> 136 _old_gen = _gen_specs[1]->init(old_rs, 1, rem_set()); >>> 137 heap_rs = heap_rs.last_part(_gen_specs[1]->max_size()); >>> >>> I feel like there should be an assertion somewhere before here that >>> _n_gens == 2. >>> >>> Also, I think line 137 is unnecessary. >> >> Assertion added and line removed. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> 216 void GenCollectedHeap::save_used_regions(int level) { >>> 217 assert(level < _n_gens, "Illegal level parameter"); >>> 218 if (level == 1) { >>> 219 _old_gen->save_used_region(); >>> 220 } >>> 221 _young_gen->save_used_region(); >>> 222 } >>> >>> Assumes level >= 0. Old code would do nothing with negative level. >>> Probably negative level is a bug, and should be asserted against. >> >> Assertion added. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> collect_generation and do_collection >>> >>> I tried to give the changes here a thorough look, but the diffs are >>> very messy. I hope I didn't miss anything. >>> >>> I think the review of this would have been noticably easier if the >>> extraction of collect_generation into a separate function had happened >>> before and independently of the generation array changes. Oh well. >> >> That may be true, even though I believe that the only major difference >> if this would have been done separately would be that the call sites >> would use get_gen(0/1) instead of young/old_gen. This is clearly the >> most difficult part of removing the generation array and also this is >> where we saw a few bugs in the last version. According to our tests it >> should be fine now. :) >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> 574 void GenCollectedHeap:: >>> 575 gen_process_roots(int level, >>> >>> I think the proposed changes maintain the previous behavior, as >>> desired. However ... >>> >>> This is probably something for a future (but soon, I hope) cleanup. >>> >>> GenCollectedHeap::gen_process_roots() is a bit of a mess now. It first >>> calls SharedHeap::process_roots. It then does completely different >>> things, depending on the value of the first (level) argument. That's >>> not at all obvious from the way the code is written though. Retaining >>> the structure from the old iteration through _gens[] is not helpful in >>> the new world where we have exactly two generations. >>> >>> (I was surprised to note that the old code seems to do nothing for >>> _gens[level]. I wonder if that was a lurking bug?) >>> >>> There are two overloads for gen_process_roots(). The first does most >>> of the work. The second constructs an additional closure and calls >>> the first with that closure plus some other argument adjustments. I >>> think all client callers call the second; the first could be hoisted >>> into the second and eliminated as a separate function. >>> >>> I also suspect that, with some careful analysis, we could determine >>> the level value for all callers. This and the fact that this function >>> does very different things according to the level suggests splitting >>> this function into two distinct functions. >>> >>> Here's what I came up with for the level values being provided: >>> >>> - MarkSweep always calls with level == 1 (assertion) >>> - CMS always calls with level == _cmsGen->level() >>> presumably _cmsGen->level() is 1, since _cmsGen is old_gen? >>> - ParNewGeneration::work calls with level == _gen->level() >>> _gen is the young generation, so level is always 0 here? >>> - DefNewGeneration::collect calls with level == _level >>> _level is 0, since this is young generation? >>> >>> The two callers apparently providing 0 as the level also always >>> provide true as the second (younger_gens_as_roots) argument. I >>> suspect there are other argument simplifications that would result >>> from splitting. >>> >>> I'm ok with the proposed change as is, as part of that change set. >>> But please make sure there's a follow-on cleanup RFE. >> >> I absolutely agree and I assume there are other simplifications and >> cleanups that will be apparent once the rest of the cleanups goes in as >> well. I copied your description above into an RFE to handle this issue. >> >> https://bugs.openjdk.java.net/browse/JDK-8072809 >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> 837 // This might be sped up with a cache of the last generation that >>> 838 // answered yes. >>> 839 if (_young_gen->is_in(p) || _old_gen->is_in(p)) { >>> 840 return true; >>> 841 } >>> 842 // Otherwise... >>> 843 return false; >>> >>> The comment on line 837 seems mostly relevant to the old code that >>> iterated through the generations array. Is it still relevant? >>> Especially since it seems to bottom out in Space::is_in(), which is >>> documented as being potentially slow and so only to be used in assert. >>> >>> Also, with only the two generations now, I'd probably write this as >>> >>> return _young_gen->is_in(p) || _old_gen->is_in(p); >> >> Agreed. Fixed. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> 1046 void GenCollectedHeap::prepare_for_compaction() { >>> 1047 guarantee(_n_gens = 2, "Wrong number of generations"); >>> 1048 Generation* old_gen = _old_gen; >>> 1049 // Start by compacting into same gen. >>> 1050 CompactPoint cp(old_gen); >>> 1051 old_gen->prepare_for_compaction(&cp); >>> 1052 Generation* young_gen = _young_gen; >>> 1053 young_gen->prepare_for_compaction(&cp); >>> 1054 } >>> >>> The old_gen and young_gen local variables just add clutter after the >>> rewrite. >> >> Agreed. This was taken care of in one of the later cleanups but I moved >> that cleanup into this patch. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.hpp >>> 387 Generation* get_gen(int i) const { >>> 388 guarantee(i >= 0 && i < _n_gens, "Out of bounds"); >>> 389 if (i == 0) { >>> 390 return _young_gen; >>> 391 } else { >>> 392 return _old_gen; >>> 393 } >>> 394 } >>> >>> The assertion here now ought to be (level == 0 || level == 1). And >>> _n_gens must be 2. >> >> Assert fixed. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >> >> Thank you! >> /Jesper From kim.barrett at oracle.com Wed Feb 18 02:02:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Feb 2015 21:02:39 -0500 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54E3ADDB.1090106@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> <54DDF4F8.2080508@oracle.com> <54E3ADDB.1090106@oracle.com> Message-ID: <82AE4980-2734-4A61-9C8E-B3B5F7326303@oracle.com> On Feb 17, 2015, at 4:08 PM, Jesper Wilhelmsson wrote: > > Hi Mikael, > > Thanks for reviewing! > I agree with your comments and has fixed them in this new webrev: > cr.openjdk.java.net/~jwilhelm/8061802/webrev.03 I agree that Mikael?s suggestions are improvements. [An incremental webrev would have made this round of review much easier. It might have saved me time to produce one of my own.] Looks good. From stefan.karlsson at oracle.com Wed Feb 18 08:57:10 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 09:57:10 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to oop.inline.hpp Message-ID: <54E453E6.9020107@oracle.com> Hi, Please review this patch to get rid of depencies from handles.hpp to oop.inline.hpp. There's no explicit include of oop.inline.hpp but oop_is_instance is used in handles.hpp. I've moved the usage of oop_is_instance to handles.cpp files and cleaned up the includes a bit. This patch is extracted from a bigger patch to clean up some of our GC code dependencies in oop_iterate. http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8073388 Thanks, StefanK From stefan.karlsson at oracle.com Wed Feb 18 09:00:41 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 10:00:41 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to oop.inline.hpp In-Reply-To: <54E453E6.9020107@oracle.com> References: <54E453E6.9020107@oracle.com> Message-ID: <54E454B9.9020308@oracle.com> On 2015-02-18 09:57, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of depencies from handles.hpp to > oop.inline.hpp. There's no explicit include of oop.inline.hpp but > oop_is_instance is used in handles.hpp. I've moved the usage of > oop_is_instance to handles.cpp files and cleaned up the includes a bit. > > This patch is extracted from a bigger patch to clean up some of our GC > code dependencies in oop_iterate. After sending this mail I realized that this part of the larger patch was to get rid of the dependency against klass.hpp and not oop.inline.hpp. StefanK > > http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073388 > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Feb 18 09:09:06 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 10:09:06 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to oop.inline.hpp In-Reply-To: <54E454B9.9020308@oracle.com> References: <54E453E6.9020107@oracle.com> <54E454B9.9020308@oracle.com> Message-ID: <54E456B2.6050200@oracle.com> I'm withdrawing this RFR, and will send out a corrected RFR to hotspot-dev. StefanK On 2015-02-18 10:00, Stefan Karlsson wrote: > On 2015-02-18 09:57, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to get rid of depencies from handles.hpp to >> oop.inline.hpp. There's no explicit include of oop.inline.hpp but >> oop_is_instance is used in handles.hpp. I've moved the usage of >> oop_is_instance to handles.cpp files and cleaned up the includes a bit. >> >> This patch is extracted from a bigger patch to clean up some of our >> GC code dependencies in oop_iterate. > > After sending this mail I realized that this part of the larger patch > was to get rid of the dependency against klass.hpp and not > oop.inline.hpp. > > StefanK > >> >> http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073388 >> >> Thanks, >> StefanK > From goetz.lindenmaier at sap.com Wed Feb 18 09:52:55 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Feb 2015 09:52:55 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <54E38EF2.90304@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96401@DEWDFEMB12A.global.corp.sap> Hi Jon, > Please revert to the original order of these lines > Could you define a variable to hold the heap alignment? Done. > Should the 30*M be aligned? It works as is, so I didn't want to change it. Also, OldSize is not aligned to heap_alignment. It ends up being 10M, while heap_alignment is 32M on the machine with 64K pages. > What is the 20*m? The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. Before, the flag_value was just chosen accordingly (170M). Now I add +20M to MaxNewSize to assure this, as I have to compute MaxNewSize. Is 'overlap' a good name? Here's the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ Thanks and best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Dienstag, 17. Februar 2015 19:57 To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: Hi Jon, thanks for looking at this change! It's not that easy as just aligning to vm_page_size, but I can use CollectorPolicy::compute_heap_alignment(): http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ Please revert to the original order of these lines unless it makes a difference. 990 set_basic_flag_values(); 991 flag_value = 30 * M; Could you define a variable to hold the heap alignment? size_t heap_alignment = CollectorPolicy::compute_heap_alignment() just to make it a little more readable. Should the 30*M be aligned? What is the 20*m? Could you assign it to a variable with a descriptive name? Jon Best regards, Goetz. From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jon Masamitsu Sent: Donnerstag, 12. Februar 2015 00:35 To: hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Goetz, Could you have used page alignment to determine the new expected sizes? For example, instead of 987 // Calculate what we expect the flag to be. 988 flag_value = adapted_InitialHeapSize - MaxNewSize; 989 verify_old_initial(flag_value); expected_old_initial = align_size_up(flag_value, os::vm_page_size()) verify_old_initial(expected_old_initial) Jon On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Wed Feb 18 10:16:00 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Feb 2015 11:16:00 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54DCB21A.2000203@oracle.com> References: <54DCB21A.2000203@oracle.com> Message-ID: <1424254560.3335.5.camel@oracle.com> Hi Andrey, sorry for the late review... On Thu, 2015-02-12 at 17:00 +0300, Andrey Zakharov wrote: > Hello. > Summary: test for auxiliary data in G1 fails as they cannot precisely > measure this aux data size. > I've added whitebox method to get this size. > I've on little question about placement of helper method > "sum_memory_usage", which currently placed in > gc_implementation/g1/heapRegionManager.hpp but it doesn't logically > related to HeapManager itself. > If you can advice me where its best place it will be wonderful. > > webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev/ > bug: > JDK-8061715 gc/g1/TestShrinkAuxiliaryData15.java fails with > java.lang.RuntimeException: heap decommit failed - after > before > > Testing done in Stockholm's JPRT (2015-02-12-112315.azakharov.hs-gc) all > is fine. - the changes in the VM look good, there is one point though: the method HeapRegionManager::get_auxiliary_data_memory_usage() not only returns memory information about auxiliary data structures, but includes the heap. If this is intentional, the method name should be fixed to not read "auxiliary". - in the whitebox.cpp files, in WB_G1AuxiliaryMemoryUsage there seems to be a superfluous newline at line 327/328. - please fix copyright dates - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. Afaik jtreg already automatically puts all output into the log files. - line 174, I do not understand the comment. What does "if auxdata size will be more than page size it would not decommit auxiliary data size is about ~3.6% of heap size" seem to be at least two sentences. - what do the two reasons given in the comment of checkEnvApplicability() actually mean? I.e. why do you not run the test if large pages are enabled? I think the check is wrong too, it should check if UseLargePages is enabled I think. You should use the HotSpotDiagnosticMXBean's getVMOption() method. Did you check that Whitebox. The actual code does not help either. The second check just seems to check whether REGION_SIZE*REGIONS_TO_ALLOCATE is smaller than the heap size. Why not specify -Xmx of 100M directly when starting the VM instead? - it would be nice to not call the hot card cache "RSet cache". I do not know why the switch has been called G1ConcRSLogCacheSize, but it does not have to do much with the remembered set (it decreases the pressure on the remembered set, but it has not a lot do to with it other than that). Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 18 11:28:47 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Feb 2015 12:28:47 +0100 Subject: RFR (S): 8058446: G1 Hot card cache should use ArrayAllocator to allocate the cache array In-Reply-To: <54E3697F.9070202@oracle.com> References: <1424186295.3163.9.camel@oracle.com> <54E3697F.9070202@oracle.com> Message-ID: <1424258927.3335.6.camel@oracle.com> Hi Jesper, Mikael, On Tue, 2015-02-17 at 17:17 +0100, Jesper Wilhelmsson wrote: > Looks good! > /Jesper thanks for the reviews. Thomas From mikael.gerdin at oracle.com Wed Feb 18 12:24:42 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Feb 2015 13:24:42 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <1424254560.3335.5.camel@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> Message-ID: <54E4848A.2010203@oracle.com> Hi, On 2015-02-18 11:16, Thomas Schatzl wrote: > Hi Andrey, > > sorry for the late review... > > On Thu, 2015-02-12 at 17:00 +0300, Andrey Zakharov wrote: >> Hello. >> Summary: test for auxiliary data in G1 fails as they cannot precisely >> measure this aux data size. >> I've added whitebox method to get this size. >> I've on little question about placement of helper method >> "sum_memory_usage", which currently placed in >> gc_implementation/g1/heapRegionManager.hpp but it doesn't logically >> related to HeapManager itself. >> If you can advice me where its best place it will be wonderful. >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev/ >> bug: >> JDK-8061715 gc/g1/TestShrinkAuxiliaryData15.java fails with >> java.lang.RuntimeException: heap decommit failed - after > before >> >> Testing done in Stockholm's JPRT (2015-02-12-112315.azakharov.hs-gc) all >> is fine. > > - the changes in the VM look good, there is one point though: the method > HeapRegionManager::get_auxiliary_data_memory_usage() not only returns > memory information about auxiliary data structures, but includes the > heap. > If this is intentional, the method name should be fixed to not read > "auxiliary". The sum_memory_usage doesn't seem to belong in HeapRegionManager, it doesn't touch any class members and has no other callers. If you really want to factor out the additions in a separate method I'd prefer it if you put it as a static non-class method just above HeapRegionManager::get_auxiliary_data_memory_usage. If you want to keep it, please change it to use pointers instead of references, we rarely use references as output parameters since it makes it hard to understand the code at the call site. A lot of the JVM code you added has 4 space indentation instead of the correct 2 spaces. /Mikael > > - in the whitebox.cpp files, in WB_G1AuxiliaryMemoryUsage there seems to > be a superfluous newline at line 327/328. > > - please fix copyright dates > > - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. > Afaik jtreg already automatically puts all output into the log files. > > - line 174, I do not understand the comment. What does "if auxdata size > will be more than page size it would not decommit auxiliary data size is > about ~3.6% of heap size" seem to be at least two sentences. > > - what do the two reasons given in the comment of > checkEnvApplicability() actually mean? I.e. why do you not run the test > if large pages are enabled? > > I think the check is wrong too, it should check if UseLargePages is > enabled I think. You should use the HotSpotDiagnosticMXBean's > getVMOption() method. > > Did you check that Whitebox. > > The actual code does not help either. > > The second check just seems to check whether > REGION_SIZE*REGIONS_TO_ALLOCATE is smaller than the heap size. Why not > specify -Xmx of 100M directly when starting the VM instead? > > - it would be nice to not call the hot card cache "RSet cache". I do not > know why the switch has been called G1ConcRSLogCacheSize, but it does > not have to do much with the remembered set (it decreases the pressure > on the remembered set, but it has not a lot do to with it other than > that). > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Wed Feb 18 13:39:03 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Feb 2015 14:39:03 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <82AE4980-2734-4A61-9C8E-B3B5F7326303@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> <54DDF4F8.2080508@oracle.com> <54E3ADDB.1090106@oracle.com> <82AE4980-2734-4A61-9C8E-B3B5F7326303@oracle.com> Message-ID: <54E495F7.2010909@oracle.com> Hi, On 2015-02-18 03:02, Kim Barrett wrote: > On Feb 17, 2015, at 4:08 PM, Jesper Wilhelmsson wrote: >> >> Hi Mikael, >> >> Thanks for reviewing! >> I agree with your comments and has fixed them in this new webrev: >> cr.openjdk.java.net/~jwilhelm/8061802/webrev.03 Looks good to me. /Mikael > > I agree that Mikael?s suggestions are improvements. > > [An incremental webrev would have made this round of review much easier. It might have saved me time to produce one of my own.] > > Looks good. > From jesper.wilhelmsson at oracle.com Wed Feb 18 13:39:54 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 18 Feb 2015 14:39:54 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <82AE4980-2734-4A61-9C8E-B3B5F7326303@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> <54DDF4F8.2080508@oracle.com> <54E3ADDB.1090106@oracle.com> <82AE4980-2734-4A61-9C8E-B3B5F7326303@oracle.com> Message-ID: <54E4962A.2070904@oracle.com> Thanks Kim! /Jesper Kim Barrett skrev den 18/2/15 03:02: > On Feb 17, 2015, at 4:08 PM, Jesper Wilhelmsson wrote: >> >> Hi Mikael, >> >> Thanks for reviewing! >> I agree with your comments and has fixed them in this new webrev: >> cr.openjdk.java.net/~jwilhelm/8061802/webrev.03 > > I agree that Mikael?s suggestions are improvements. > > [An incremental webrev would have made this round of review much easier. It might have saved me time to produce one of my own.] > > Looks good. > From jesper.wilhelmsson at oracle.com Wed Feb 18 13:40:14 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 18 Feb 2015 14:40:14 +0100 Subject: RFR: JDK-8061802 - REDO - Remove the generations array In-Reply-To: <54E495F7.2010909@oracle.com> References: <54CA0F41.3090909@oracle.com> <54DA6C42.7060209@oracle.com> <54DDF4F8.2080508@oracle.com> <54E3ADDB.1090106@oracle.com> <82AE4980-2734-4A61-9C8E-B3B5F7326303@oracle.com> <54E495F7.2010909@oracle.com> Message-ID: <54E4963E.1010006@oracle.com> Thanks Mikael! /Jesper Mikael Gerdin skrev den 18/2/15 14:39: > Hi, > > On 2015-02-18 03:02, Kim Barrett wrote: >> On Feb 17, 2015, at 4:08 PM, Jesper Wilhelmsson >> wrote: >>> >>> Hi Mikael, >>> >>> Thanks for reviewing! >>> I agree with your comments and has fixed them in this new webrev: >>> cr.openjdk.java.net/~jwilhelm/8061802/webrev.03 > > Looks good to me. > > /Mikael > >> >> I agree that Mikael?s suggestions are improvements. >> >> [An incremental webrev would have made this round of review much easier. It >> might have saved me time to produce one of my own.] >> >> Looks good. >> From thomas.schatzl at oracle.com Wed Feb 18 14:36:14 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Feb 2015 15:36:14 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <54E35847.8070708@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <54E35847.8070708@oracle.com> Message-ID: <1424270174.3335.8.camel@oracle.com> Hi Bengt, thanks for the review. On Tue, 2015-02-17 at 16:03 +0100, Bengt Rutisson wrote: > > JIRA: > > https://bugs.openjdk.java.net/browse/JDK-8027962 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8027962/webrev/ > > I think it would be good if we can make sure that the GC code does not > leak in to runtime/timer. Not sure exactly how, but it would be good to > try some change out to avoid this dependency. Actually there is a really simple way of doing that by declaring an interface with the required methods and use that. > TestGCLogMessages.java > > I find it a little confusing that the instance variable messages has the > same name as the parameter to the method checkMessagesAtLevel(). Could > you change the name of one of them? > > 47 LogMessageWithLevel messages[] = new LogMessageWithLevel[] { > > 79 void checkMessagesAtLevel(OutputAnalyzer output, > LogMessageWithLevel messages[], int level) throws Exception { > > Also, what do you think about using an enum instead of using the integer > values 2, 3 etc for levels? All fixed. New webrevs at: http://cr.openjdk.java.net/~tschatzl/8027962/webrev.1/ (full) http://cr.openjdk.java.net/~tschatzl/8027962/webrev.0_to_1/ (incremental) Testing: jprt Thanks, Thomas From goetz.lindenmaier at sap.com Wed Feb 18 15:17:48 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Feb 2015 15:17:48 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96594@DEWDFEMB12A.global.corp.sap> Hi, I additionally updated the copyright in this webrev ;) Best regards, Goetz. From: Lindenmaier, Goetz Sent: Mittwoch, 18. Februar 2015 10:53 To: 'Jon Masamitsu'; hotspot-gc-dev at openjdk.java.net Subject: RE: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi Jon, > Please revert to the original order of these lines > Could you define a variable to hold the heap alignment? Done. > Should the 30*M be aligned? It works as is, so I didn't want to change it. Also, OldSize is not aligned to heap_alignment. It ends up being 10M, while heap_alignment is 32M on the machine with 64K pages. > What is the 20*m? The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. Before, the flag_value was just chosen accordingly (170M). Now I add +20M to MaxNewSize to assure this, as I have to compute MaxNewSize. Is 'overlap' a good name? Here's the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ Thanks and best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Dienstag, 17. Februar 2015 19:57 To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: Hi Jon, thanks for looking at this change! It's not that easy as just aligning to vm_page_size, but I can use CollectorPolicy::compute_heap_alignment(): http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ Please revert to the original order of these lines unless it makes a difference. 990 set_basic_flag_values(); 991 flag_value = 30 * M; Could you define a variable to hold the heap alignment? size_t heap_alignment = CollectorPolicy::compute_heap_alignment() just to make it a little more readable. Should the 30*M be aligned? What is the 20*m? Could you assign it to a variable with a descriptive name? Jon Best regards, Goetz. From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jon Masamitsu Sent: Donnerstag, 12. Februar 2015 00:35 To: hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Goetz, Could you have used page alignment to determine the new expected sizes? For example, instead of 987 // Calculate what we expect the flag to be. 988 flag_value = adapted_InitialHeapSize - MaxNewSize; 989 verify_old_initial(flag_value); expected_old_initial = align_size_up(flag_value, os::vm_page_size()) verify_old_initial(expected_old_initial) Jon On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Feb 18 20:01:52 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 18 Feb 2015 12:01:52 -0800 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: References: Message-ID: <54E4EFB0.60609@oracle.com> On 2/16/2015 3:16 PM, Kim Barrett wrote: > Please review this change that ensures all barrier set downcasts are > checked when running in debug mode. This is a step toward some > cleanups and changes to the barrier set class hierarchy, improving > error checking and making it easier to find places where assumptions > are being made that would be invalidated by changes. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069016 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00 > > Changeset includes > > * New FakeRttiSupport utility class template. This provides some Kim, Just starting on this but an up front question. Do you have a particular preference for having "Fake" in the class name? As opposed to just RTTISupport? It feels a little funny and adds (unnecessary?) length to the name. Jon > infrastructure for performing the checks. It is intended to > ease similar changes in some other class hierarchies where ad hoc > checking or unchecked downcasts are common, such as the > CollectedHeap hierarchy. > > * Re-implementation of BarrierSet's "fake RTTI" to use > FakeRttiSupport. As part of this, BarrierSet::is_a() is now just an > integer bit test rather than a virtual function that needs to walk > up the class hierarchy. > > * Adds barrier_set_cast function template, which uses the improved > is_a() test to assert the validity of the conversion. > > * Adds BarrierSet::CardTableForRS barrier set name tag, so that all > existing classes have an associated tag. > > * Changes all C-style barrier set downcasts to use barrier_set_cast. In > most cases, this is just a mechanical translation. In some cases some > existing checks have been eliminated in favor of the check made by the > new mechanism. In a few places more extensive changes have been made, > as detailed below: > > ** In various g1_write_barrier_post() implementations, downcast to > G1SATBCardTableLoggingModRefBS rather than G1SATBCardTableModRefBS, > since the code being generated includes logging. > > ** In PSMarkSweep::invoke_no_policy(), don't bother conditionalizing > clear/invalidate of barrier set on whether the bs is a modrefbs; it > always will be for parallel scavenge collector. Similarly in > PSParallelCompact::post_compact(). > > ** For VerifyLiveClosure constructor initialization of _bs member, just > use barrier_set_cast of the heap's barrier. If the previous is_a > conditionalization failed it would just lead to a later segfault > when attempting to dereference through the NULL _bs member. > > Testing: > JPRT, local JTREG of test/[closed]/{gc,runtime}, > local RefWorkload using CMS, G1, ParallelOld > From kim.barrett at oracle.com Wed Feb 18 21:23:13 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Feb 2015 16:23:13 -0500 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <54E4EFB0.60609@oracle.com> References: <54E4EFB0.60609@oracle.com> Message-ID: <25815900-91C3-4AED-A71A-E6805995FD6B@oracle.com> On Feb 18, 2015, at 3:01 PM, Jon Masamitsu wrote: > > > On 2/16/2015 3:16 PM, Kim Barrett wrote: >> Please review this change that ensures all barrier set downcasts are >> checked when running in debug mode. This is a step toward some >> cleanups and changes to the barrier set class hierarchy, improving >> error checking and making it easier to find places where assumptions >> are being made that would be invalidated by changes. >> >> I will need a sponsor for this change. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8069016 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00 >> >> Changeset includes >> >> * New FakeRttiSupport utility class template. This provides some > > Kim, > > Just starting on this but an up front question. Do you have a > particular preference for having "Fake" in the class name? As > opposed to just RTTISupport? It feels a little funny and adds > (unnecessary?) length to the name. I don?t feel strongly about the name, but ?RTTISupport? to me indicates something related to ?real? RTTI, which we don?t have. I used ?fake? because of the use of that terminology in several existing comments referring the mechanisms I?m replacing or hope to replace in the future. From kim.barrett at oracle.com Wed Feb 18 22:42:42 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Feb 2015 17:42:42 -0500 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <1424270174.3335.8.camel@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <54E35847.8070708@oracle.com> <1424270174.3335.8.camel@oracle.com> Message-ID: <9A846244-CB01-449E-9684-B70FB2E8DD94@oracle.com> On Feb 18, 2015, at 9:36 AM, Thomas Schatzl wrote: > > Hi Bengt, > > thanks for the review. > > On Tue, 2015-02-17 at 16:03 +0100, Bengt Rutisson wrote: >>> JIRA: >>> https://bugs.openjdk.java.net/browse/JDK-8027962 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8027962/webrev/ >> >> I think it would be good if we can make sure that the GC code does not >> leak in to runtime/timer. Not sure exactly how, but it would be good to >> try some change out to avoid this dependency. > > Actually there is a really simple way of doing that by declaring an > interface with the required methods and use that. > >> TestGCLogMessages.java >> >> I find it a little confusing that the instance variable messages has the >> same name as the parameter to the method checkMessagesAtLevel(). Could >> you change the name of one of them? >> >> 47 LogMessageWithLevel messages[] = new LogMessageWithLevel[] { >> >> 79 void checkMessagesAtLevel(OutputAnalyzer output, >> LogMessageWithLevel messages[], int level) throws Exception { >> >> Also, what do you think about using an enum instead of using the integer >> values 2, 3 etc for levels? > > All fixed. > > New webrevs at: > http://cr.openjdk.java.net/~tschatzl/8027962/webrev.1/ (full) > http://cr.openjdk.java.net/~tschatzl/8027962/webrev.0_to_1/ > (incremental) I think it's not very nice that TrackPhaseTime needs to deal with a possibly null _data and that SharedHeap::process_xxx_roots have a default NULL for the new PhaseTimeData argument. Obviously this is because only G1 support for reporting this additional phase information is being implemented by this change set. And the approach taken is fine, given that limitation. Is the intention to provide it for other collectors later? (And is there an RFE?) 8027962 talks about improving for "at least the G1 collector", but it seems like other collectors benefit similarly. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp 354 static const char* g1_ext_root_task_strings[G1CollectedHeap::G1H_PS_NumElements] = { 355 "Filter SATB Roots (ms)", 356 "CM RefProcessor Roots (ms)", 357 "Wait For Strong CLD (ms)", 358 "Weak CLD Roots (ms)" 359 }; I would drop the explicit array size from the declaration, and instead add some static asserts to verify all present and properly accounted for, e.g. STATIC_ASSERT(G1CollectedHeap::G1H_PS_NumElements == ARRAY_SIZE(g1_ext_root_task_strings)); STATIC_ASSERT(G1CollectedHeap::G1H_PS_filter_satb_buffers == 0); ... Similarly for the SharedHeap task enum. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp 994 G1H_PS_First, Is there a reason why this doesn't start at SharedHeap::SH_PS_NumElements? That seems more natural to me. [As an aside, C++11 has a nice facility for mapping from enum "codes" to strings, including hierarchies of code sets: the std::error_code and std::error_category classes. (Arguably poorly named; they can be used for things other than errors.) Too bad we have to reinvent wheels.] ------------------------------------------------------------------------------ From jon.masamitsu at oracle.com Fri Feb 20 08:04:00 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Feb 2015 00:04:00 -0800 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: References: Message-ID: <54E6EA70.6080203@oracle.com> http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/utilities/fakeRttiSupport.hpp.html 86 TagType _ctag; I'd prefer that the variable be named _concrete_tag or the parameters concrete_tag be changed to ctag 56 explicit FakeRttiSupport(TagType concrete_tag) : 57 _tag_set(tag_bit(concrete_tag)), _ctag(concrete_tag) { } 62 FakeRttiSupport(TagType concrete_tag, uintx tag_set) : 63 _tag_set(tag_set), _ctag(validate_tag(concrete_tag)) { } and function concrete_tag() be changed to ctag(). http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/memory/barrierSet.hpp.frames.html 82 // Test whether this object is of the type corresponding to bsn. 83 bool is_a(BarrierSet::Name bsn) const { return _fake_rtti.has_tag(bsn) For "is_a()" would a more accurate description be // Check if the BarrierSet::Name has a tag in the tag_set http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp.udiff.html + // Concrete tag should be BarrierSet::CardTableExtension. + // That will presently break things in a bunch of places though. Can you expand on these comments. Where would the breakage occur? http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp.udiff.html - BarrierSet* bs = heap->barrier_set(); - if (bs->is_a(BarrierSet::ModRef)) { - ModRefBarrierSet* modBS = (ModRefBarrierSet*)bs; + ModRefBarrierSet* modBS = barrier_set_cast(heap->barrier_set()); Is this one of the place that breaks because the barrier set is really a CardTableExtension? http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/memory/cardTableModRefBS.hpp.udiff.html + // Concrete tag should be BarrierSet::CardTableForRS. + // That will presently break things in a bunch of places though. Expand on this comment also about what will break. Rest looks good. Jon On 2/16/2015 3:16 PM, Kim Barrett wrote: > Please review this change that ensures all barrier set downcasts are > checked when running in debug mode. This is a step toward some > cleanups and changes to the barrier set class hierarchy, improving > error checking and making it easier to find places where assumptions > are being made that would be invalidated by changes. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069016 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00 > > Changeset includes > > * New FakeRttiSupport utility class template. This provides some > infrastructure for performing the checks. It is intended to > ease similar changes in some other class hierarchies where ad hoc > checking or unchecked downcasts are common, such as the > CollectedHeap hierarchy. > > * Re-implementation of BarrierSet's "fake RTTI" to use > FakeRttiSupport. As part of this, BarrierSet::is_a() is now just an > integer bit test rather than a virtual function that needs to walk > up the class hierarchy. > > * Adds barrier_set_cast function template, which uses the improved > is_a() test to assert the validity of the conversion. > > * Adds BarrierSet::CardTableForRS barrier set name tag, so that all > existing classes have an associated tag. > > * Changes all C-style barrier set downcasts to use barrier_set_cast. In > most cases, this is just a mechanical translation. In some cases some > existing checks have been eliminated in favor of the check made by the > new mechanism. In a few places more extensive changes have been made, > as detailed below: > > ** In various g1_write_barrier_post() implementations, downcast to > G1SATBCardTableLoggingModRefBS rather than G1SATBCardTableModRefBS, > since the code being generated includes logging. > > ** In PSMarkSweep::invoke_no_policy(), don't bother conditionalizing > clear/invalidate of barrier set on whether the bs is a modrefbs; it > always will be for parallel scavenge collector. Similarly in > PSParallelCompact::post_compact(). > > ** For VerifyLiveClosure constructor initialization of _bs member, just > use barrier_set_cast of the heap's barrier. If the previous is_a > conditionalization failed it would just lead to a later segfault > when attempting to dereference through the NULL _bs member. > > Testing: > JPRT, local JTREG of test/[closed]/{gc,runtime}, > local RefWorkload using CMS, G1, ParallelOld > From mikael.gerdin at oracle.com Fri Feb 20 11:55:46 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 20 Feb 2015 12:55:46 +0100 Subject: RFR (S) 8073532: jmap -heap fails after generation array removal Message-ID: <54E720C2.6060105@oracle.com> Hi all, Please review this small fix to an issue introduced by JDK-8061802. The API in the SA is pretty strange, but a "Field" object basically only encodes the type and offset of a non-static field, so to get what the field points to you must supply "this.addr", which is the base address of the containing object. An alternate fix could have been to call getAddress(addr), but a quick look at the other usages of AddressField seems to suggest that getValue(addr) is the preferred way. Webrev: http://cr.openjdk.java.net/~mgerdin/8073532/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8073532 Testing: Ran jdk/test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java with -XX:+UseSerialGC before/after fix. Ran "jmap -heap" and inspected the output to verify that the correct output is produced with the fix applied: == Before fix == Heap Usage: Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.tools.jmap.JMap.runTool(JMap.java:201) at sun.tools.jmap.JMap.main(JMap.java:130) Caused by: sun.jvm.hotspot.types.WrongTypeException at sun.jvm.hotspot.types.basic.BasicField.getAddress(BasicField.java:246) at sun.jvm.hotspot.types.basic.BasicFieldWrapper.getAddress(BasicFieldWrapper.java:131) at sun.jvm.hotspot.memory.GenCollectedHeap.getGen(GenCollectedHeap.java:79) at sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:89) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:49) ... 6 more == With fix == Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 157941760 (150.625MB) used = 14044472 (13.393852233886719MB) free = 143897288 (137.23114776611328MB) 8.892184055692427% used Eden Space: capacity = 140443648 (133.9375MB) used = 14044472 (13.393852233886719MB) free = 126399176 (120.54364776611328MB) 10.000076329546781% used From Space: capacity = 17498112 (16.6875MB) used = 0 (0.0MB) free = 17498112 (16.6875MB) 0.0% used To Space: capacity = 17498112 (16.6875MB) used = 0 (0.0MB) free = 17498112 (16.6875MB) 0.0% used tenured generation: capacity = 350945280 (334.6875MB) used = 0 (0.0MB) free = 350945280 (334.6875MB) 0.0% used /Mikael From jesper.wilhelmsson at oracle.com Fri Feb 20 12:11:48 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 20 Feb 2015 13:11:48 +0100 Subject: RFR (S) 8073532: jmap -heap fails after generation array removal In-Reply-To: <54E720C2.6060105@oracle.com> References: <54E720C2.6060105@oracle.com> Message-ID: <54E72484.6000105@oracle.com> Looks good! Thanks for fixing this! /Jesper Mikael Gerdin skrev den 20/2/15 12:55: > Hi all, > > Please review this small fix to an issue introduced by JDK-8061802. > > The API in the SA is pretty strange, but a "Field" object basically only encodes > the type and offset of a non-static field, so to get what the field points to > you must supply "this.addr", which is the base address of the containing object. > > An alternate fix could have been to call getAddress(addr), but a quick look at > the other usages of AddressField seems to suggest that getValue(addr) is the > preferred way. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8073532/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073532 > > Testing: > Ran jdk/test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java with > -XX:+UseSerialGC before/after fix. > Ran "jmap -heap" and inspected the output to verify that the correct output is > produced with the fix applied: > == Before fix == > Heap Usage: > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.tools.jmap.JMap.runTool(JMap.java:201) > at sun.tools.jmap.JMap.main(JMap.java:130) > Caused by: sun.jvm.hotspot.types.WrongTypeException > at sun.jvm.hotspot.types.basic.BasicField.getAddress(BasicField.java:246) > at > sun.jvm.hotspot.types.basic.BasicFieldWrapper.getAddress(BasicFieldWrapper.java:131) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.getGen(GenCollectedHeap.java:79) > at sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:89) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:49) > ... 6 more > > == With fix == > Heap Usage: > New Generation (Eden + 1 Survivor Space): > capacity = 157941760 (150.625MB) > used = 14044472 (13.393852233886719MB) > free = 143897288 (137.23114776611328MB) > 8.892184055692427% used > Eden Space: > capacity = 140443648 (133.9375MB) > used = 14044472 (13.393852233886719MB) > free = 126399176 (120.54364776611328MB) > 10.000076329546781% used > From Space: > capacity = 17498112 (16.6875MB) > used = 0 (0.0MB) > free = 17498112 (16.6875MB) > 0.0% used > To Space: > capacity = 17498112 (16.6875MB) > used = 0 (0.0MB) > free = 17498112 (16.6875MB) > 0.0% used > tenured generation: > capacity = 350945280 (334.6875MB) > used = 0 (0.0MB) > free = 350945280 (334.6875MB) > 0.0% used > > /Mikael From bengt.rutisson at oracle.com Fri Feb 20 12:09:18 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 20 Feb 2015 13:09:18 +0100 Subject: RFR (S) 8073532: jmap -heap fails after generation array removal In-Reply-To: <54E720C2.6060105@oracle.com> References: <54E720C2.6060105@oracle.com> Message-ID: <54E723EE.5030103@oracle.com> Hi Mikael, Looks good! Thanks, Bengt On 2015-02-20 12:55, Mikael Gerdin wrote: > Hi all, > > Please review this small fix to an issue introduced by JDK-8061802. > > The API in the SA is pretty strange, but a "Field" object basically > only encodes the type and offset of a non-static field, so to get what > the field points to you must supply "this.addr", which is the base > address of the containing object. > > An alternate fix could have been to call getAddress(addr), but a quick > look at the other usages of AddressField seems to suggest that > getValue(addr) is the preferred way. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8073532/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073532 > > Testing: > Ran jdk/test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java with > -XX:+UseSerialGC before/after fix. > Ran "jmap -heap" and inspected the output to verify that the correct > output is produced with the fix applied: > == Before fix == > Heap Usage: > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.tools.jmap.JMap.runTool(JMap.java:201) > at sun.tools.jmap.JMap.main(JMap.java:130) > Caused by: sun.jvm.hotspot.types.WrongTypeException > at > sun.jvm.hotspot.types.basic.BasicField.getAddress(BasicField.java:246) > at > sun.jvm.hotspot.types.basic.BasicFieldWrapper.getAddress(BasicFieldWrapper.java:131) > at > sun.jvm.hotspot.memory.GenCollectedHeap.getGen(GenCollectedHeap.java:79) > at sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:89) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:49) > ... 6 more > > == With fix == > Heap Usage: > New Generation (Eden + 1 Survivor Space): > capacity = 157941760 (150.625MB) > used = 14044472 (13.393852233886719MB) > free = 143897288 (137.23114776611328MB) > 8.892184055692427% used > Eden Space: > capacity = 140443648 (133.9375MB) > used = 14044472 (13.393852233886719MB) > free = 126399176 (120.54364776611328MB) > 10.000076329546781% used > From Space: > capacity = 17498112 (16.6875MB) > used = 0 (0.0MB) > free = 17498112 (16.6875MB) > 0.0% used > To Space: > capacity = 17498112 (16.6875MB) > used = 0 (0.0MB) > free = 17498112 (16.6875MB) > 0.0% used > tenured generation: > capacity = 350945280 (334.6875MB) > used = 0 (0.0MB) > free = 350945280 (334.6875MB) > 0.0% used > > /Mikael From stefan.karlsson at oracle.com Fri Feb 20 13:14:31 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Feb 2015 14:14:31 +0100 Subject: RFR: 8073543: Circular include dependency between psScavenge.inline.hpp and psPromotionManager.inline.hpp Message-ID: <54E73337.50408@oracle.com> Hi, Please review this patch to fix a circular dependency between PSScavenge and PSPromotionManager: http://cr.openjdk.java.net/~stefank/8073543/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8073543 The circular dependency can be seen in this call chain: PSPromotionManager::process_popped_location_depth(...) PSScavenge::copy_and_push_safe_barrier(...) PSPromotionManager::copy_to_survivor_space(...) These functions are located in the psScavenge.inline.hpp and psPromotionManager.inline.hpp. Before this patch we have these include paths: psScavenge.inline.hpp -> psPromotionManager.inline.hpp psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> psScavenge.inline.hpp The patch moves PSScavenge::copy_and_push_safe_barrier to the PSPromotionManager class and gets rid of the psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> psScavenge.inline.hpp include chain. This change has been performance tested with SPECjbb2005 on Linux x64, Windows x64, Solaris x64, and Solaris Sparc. Thanks, SstefanK From david.lindholm at oracle.com Fri Feb 20 13:39:46 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 20 Feb 2015 14:39:46 +0100 Subject: RFR: 8073464 - GC workers do not have thread names Message-ID: <54E73922.4040001@oracle.com> Hi, Please review this small fix in GangWorker:initialize(). This addition sets the native thread names of GangWorker threads, which the GC uses for worker threads. Now these names will be visible when debugging in GDB. Webrev: http://cr.openjdk.java.net/~stefank/0thers/david/8073464/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8073464 Thanks, David From charlie.hunt at oracle.com Fri Feb 20 13:50:41 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Fri, 20 Feb 2015 07:50:41 -0600 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <54E73922.4040001@oracle.com> References: <54E73922.4040001@oracle.com> Message-ID: <54E73BB1.9030609@oracle.com> Nice to see this implemented! A next enhancement I would really like to see implemented is a JVMTI event that makes available all JVM internal thread names. That would enable us to see internal JVM thread names in profilers like Studio Analyzer. I realize the JVMTI events fall under a different area than GC. But, thought the enhancement was worth mentioning given this change. thanks, charlie On 02/20/2015 07:39 AM, David Lindholm wrote: > Hi, > > Please review this small fix in GangWorker:initialize(). This addition > sets the native thread names of GangWorker threads, which the GC uses > for worker threads. Now these names will be visible when debugging in > GDB. > > Webrev: > http://cr.openjdk.java.net/~stefank/0thers/david/8073464/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073464 > > > Thanks, > David > > From thomas.schatzl at oracle.com Fri Feb 20 14:40:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Feb 2015 15:40:24 +0100 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer Message-ID: <1424443224.3267.6.camel@oracle.com> Hi all, can I have reviews for the following cleanup? It removes the buffer retain functionality of ParGCAllocBuffer. It has (once I guess, but actually I am not sure because that must have been long time ago) been used to retain the space at the end of the PLAB for the next GC. Nobody uses it. So that and all related code can be removed. Here is a long description of changes: ParGCAllocBuffer::flush_stats_and_retire() is always called with true for "end_of_gc" and false for the "retain" parameter. When moving that into that call to retire(), you will notice that retire() is always called with retain=false. Looking at ParGCAllocBuffer::retire(), if retain is always false, _retained will never be true, which means that _retained_filler is never used. With _retained always false, all of the asserts in retire() always evaluate to true, so the end_of_gc parameter is useless. (Actually the whole _retained_filler is never loaded from, making this entire functionality non-working in the first place). Now looking at what retire() does, there is actually a bug in flush_stats_and_retire() because retire() adds to the waste (the area between _top and _hard_top), but flush() is called first. Looking at the code, we also only flush stats when ResizePLAB is set, due to performance concerns. However this means that the output provided by PrintPLAB will not be updated if ResizePLAB is not set, which is not desirable at all (for comparison of fragmentation with ResizePLAB enabled). I did not see the three atomic adds as a performance problem, as this method is called once per PLAB per GC. There is a small additional change in PLABStats::adjust_desired_plab_sz where I merged the two separate "if (PrintPLAB)" statements. Other cleanup changes include: - removed an obscure "XXX" comment - removed a PRAGMA - cleaned up includes (BlockOffsetTable - huh?) - tried to improve comments CR: https://bugs.openjdk.java.net/browse/JDK-8073466 Webrev: http://cr.openjdk.java.net/~tschatzl/8073466/webrev/ testing: jprt, perf benchmarks with G1 and CMS Thanks, Thomas From jon.masamitsu at oracle.com Fri Feb 20 14:59:16 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Feb 2015 06:59:16 -0800 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <54E6EA70.6080203@oracle.com> References: <54E6EA70.6080203@oracle.com> Message-ID: <54E74BC4.3010601@oracle.com> On 2/20/2015 12:04 AM, Jon Masamitsu wrote: > > ... > > > For "is_a()" would a more accurate description be > > // Check if the BarrierSet::Name has a tag in the tag_set Ignore this one. I get it now. Jon > From thomas.schatzl at oracle.com Fri Feb 20 15:01:30 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Feb 2015 16:01:30 +0100 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <54E73922.4040001@oracle.com> References: <54E73922.4040001@oracle.com> Message-ID: <1424444490.3267.12.camel@oracle.com> Hi, On Fri, 2015-02-20 at 14:39 +0100, David Lindholm wrote: > Hi, > > Please review this small fix in GangWorker:initialize(). This addition > sets the native thread names of GangWorker threads, which the GC uses > for worker threads. Now these names will be visible when debugging in GDB. > > Webrev: http://cr.openjdk.java.net/~stefank/0thers/david/8073464/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073464 > please use Thread::set_native_thread_name() instead of the os function directly. Also, wouldn't it be much more useful to set the native thread name for all NamedThreads to the name that is passed via set_name() by default? This would prevent us from doing this work multiple times. You might also fix the names themselves for gc owned threads in this CR. I do not see the need to split this up in CRs per thread type with each CR being a one-line change. Thanks, Thomas From jon.masamitsu at oracle.com Fri Feb 20 15:17:39 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Feb 2015 07:17:39 -0800 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1424162109.3163.2.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> Message-ID: <54E75013.9010404@oracle.com> On 2/17/2015 12:35 AM, Thomas Schatzl wrote: > Hi all, > > On Tue, 2015-02-03 at 10:32 -0800, Jon Masamitsu wrote: >> On 02/03/2015 02:27 AM, Thomas Schatzl wrote: >>> Hi Jon, >>> >>> thanks for the comments. I incorporated all of them in the latest >>> webrev at >>> >>> http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1/ (full) >>> http://cr.openjdk.java.net/~tschatzl/8058354/webrev.0_to_1/ (diff) > That webrev contains a bug that I found shortly after, the roundto() > method just rounds but does not divide :/ Please re-review the fix for > that. > > After fixing this I went through another big round of testing (perf + > lots of aurora tests) to make sure that the change is finally good. > > Here are the changesets: > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2/ (full) > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1_to_2/ (diff) That last change looks fine Reviewed. Jon > > Sorry for the issues, > Thomas > > From thomas.schatzl at oracle.com Fri Feb 20 15:29:25 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Feb 2015 16:29:25 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <54E75013.9010404@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> Message-ID: <1424446165.3267.13.camel@oracle.com> Hi Jon, On Fri, 2015-02-20 at 07:17 -0800, Jon Masamitsu wrote: > On 2/17/2015 12:35 AM, Thomas Schatzl wrote: > > Hi all, [...] > > That webrev contains a bug that I found shortly after, the roundto() > > method just rounds but does not divide :/ Please re-review the fix for > > that. > > > > After fixing this I went through another big round of testing (perf + > > lots of aurora tests) to make sure that the change is finally good. > > > > Here are the changesets: > > > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2/ (full) > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.1_to_2/ (diff) > > That last change looks fine > > Reviewed. Thanks for the review, Thomas From jon.masamitsu at oracle.com Fri Feb 20 16:21:15 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Feb 2015 08:21:15 -0800 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF96401@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96401@DEWDFEMB12A.global.corp.sap> Message-ID: <54E75EFB.9030008@oracle.com> On 2/18/2015 1:52 AM, Lindenmaier, Goetz wrote: > > Hi Jon, > > > Please revert to the original order of these lines > > > Could you define a variable to hold the heap alignment? > > Done. > Thanks. > > Should the 30*M be aligned? > It works as is, so I didn't want to change it. Also, OldSize is not > aligned to heap_alignment. > > It ends up being 10M, while heap_alignment is 32M on the machine with > 64K pages. > Ok. > > What is the 20*m? > > The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. > Before, the > > flag_value was just chosen accordingly (170M). Now I add +20M to > MaxNewSize > > to assure this, as I have to compute MaxNewSize. > > Is 'overlap' a good name? > Would it be accurate to change overlay (doesn't seem quite) right to over_size and to change the comment to 989 // We intentionally set MaxNewSize + OldSize > MaxHeapSize/*(see over_size)*/. Either way (overlap or over_size) is acceptable so you can decide. Consider this reviewed. I don't want to delay you even longer than I have. Jon > Here's the new webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ > > > Thanks and best regards, > > Goetz. > > *From:*Jon Masamitsu [mailto:jon.masamitsu at oracle.com] > *Sent:* Dienstag, 17. Februar 2015 19:57 > *To:* Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: > > Hi Jon, > > thanks for looking at this change! > > It's not that easy as just aligning to vm_page_size, but I can use > > CollectorPolicy::compute_heap_alignment(): > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ > > > > Please revert to the original order of these lines unless it > makes a difference. > > 990 set_basic_flag_values(); > 991 flag_value = 30 * M; > > > Could you define a variable to hold the heap alignment? > > size_t heap_alignment = CollectorPolicy::compute_heap_alignment() > > just to make it a little more readable. > > Should the 30*M be aligned? > > What is the 20*m? Could you assign it to a variable with a descriptive > name? > > Jon > > Best regards, > > Goetz. > > *From:*hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] > *On Behalf Of *Jon Masamitsu > *Sent:* Donnerstag, 12. Februar 2015 00:35 > *To:* hotspot-gc-dev at openjdk.java.net > > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Goetz, > > Could you have used page alignment to determine the > new expected sizes? > > For example, instead of > > 987 // Calculate what we expect the flag to be. > 988 flag_value = adapted_InitialHeapSize - MaxNewSize; > 989 verify_old_initial(flag_value); > > expected_old_initial = align_size_up(flag_value, os::vm_page_size()) > verify_old_initial(expected_old_initial) > > Jon > > On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: > > Hi, > > could someone please have a look at this change? > > It's really not that big. > > GC-folks maybe? > > Thanks, > > Goetz. > > *From:*Lindenmaier, Goetz > *Sent:* Freitag, 30. Januar 2015 10:36 > *To:* hotspot-dev Source Developers > *Subject:* RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Hi, > > this fixes a final problem with 64-bit page size in the jtreg tests. > > It addresses the internal VM tests of the collector policies. > > Those tests set a row of fixed flag values, and one special value > to test. > > Then they call the heap ergonomics and check the expected result > of the > > special value. > > With 64K page size, the heap ergonomics adapt more values, > breaking the tests. > > Wrt. the adapted flag values the tests are correct though. > > This change makes the expected values depend on the adapted flags, > and the > > tests pass. They only depend on adapted flags that are not subject > of the > > corresponding test. > > Please review this test. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8071822 > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.fazunenko at oracle.com Fri Feb 20 16:40:53 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 20 Feb 2015 19:40:53 +0300 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF96594@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96594@DEWDFEMB12A.global.corp.sap> Message-ID: <54E76395.7090308@oracle.com> Hi Goetz, The following line seems to contain an extra char: 1033 MarkSweepPolicy msp;m I'm afraid the compiler won't like this. Thanks, Dima On 18.02.2015 18:17, Lindenmaier, Goetz wrote: > > Hi, > > I additionally updated the copyright in this webrev ;) > > Best regards, > > Goetz. > > *From:*Lindenmaier, Goetz > *Sent:* Mittwoch, 18. Februar 2015 10:53 > *To:* 'Jon Masamitsu'; hotspot-gc-dev at openjdk.java.net > *Subject:* RE: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Hi Jon, > > > Please revert to the original order of these lines > > > Could you define a variable to hold the heap alignment? > > Done. > > > Should the 30*M be aligned? > It works as is, so I didn't want to change it. Also, OldSize is not > aligned to heap_alignment. > > It ends up being 10M, while heap_alignment is 32M on the machine with > 64K pages. > > > What is the 20*m? > > The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. > Before, the > > flag_value was just chosen accordingly (170M). Now I add +20M to > MaxNewSize > > to assure this, as I have to compute MaxNewSize. > > Is 'overlap' a good name? > > Here's the new webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ > > > Thanks and best regards, > > Goetz. > > *From:*Jon Masamitsu [mailto:jon.masamitsu at oracle.com] > *Sent:* Dienstag, 17. Februar 2015 19:57 > *To:* Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net > > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: > > Hi Jon, > > thanks for looking at this change! > > It's not that easy as just aligning to vm_page_size, but I can use > > CollectorPolicy::compute_heap_alignment(): > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ > > > > Please revert to the original order of these lines unless it > makes a difference. > > 990 set_basic_flag_values(); > 991 flag_value = 30 * M; > > > Could you define a variable to hold the heap alignment? > > size_t heap_alignment = CollectorPolicy::compute_heap_alignment() > > just to make it a little more readable. > > Should the 30*M be aligned? > > What is the 20*m? Could you assign it to a variable with a descriptive > name? > > Jon > > Best regards, > > Goetz. > > *From:*hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] > *On Behalf Of *Jon Masamitsu > *Sent:* Donnerstag, 12. Februar 2015 00:35 > *To:* hotspot-gc-dev at openjdk.java.net > > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Goetz, > > Could you have used page alignment to determine the > new expected sizes? > > For example, instead of > > 987 // Calculate what we expect the flag to be. > 988 flag_value = adapted_InitialHeapSize - MaxNewSize; > 989 verify_old_initial(flag_value); > > expected_old_initial = align_size_up(flag_value, os::vm_page_size()) > verify_old_initial(expected_old_initial) > > Jon > > On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: > > Hi, > > could someone please have a look at this change? > > It's really not that big. > > GC-folks maybe? > > Thanks, > > Goetz. > > *From:*Lindenmaier, Goetz > *Sent:* Freitag, 30. Januar 2015 10:36 > *To:* hotspot-dev Source Developers > *Subject:* RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Hi, > > this fixes a final problem with 64-bit page size in the jtreg tests. > > It addresses the internal VM tests of the collector policies. > > Those tests set a row of fixed flag values, and one special value > to test. > > Then they call the heap ergonomics and check the expected result > of the > > special value. > > With 64K page size, the heap ergonomics adapt more values, > breaking the tests. > > Wrt. the adapted flag values the tests are correct though. > > This change makes the expected values depend on the adapted flags, > and the > > tests pass. They only depend on adapted flags that are not subject > of the > > corresponding test. > > Please review this test. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8071822 > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Feb 20 17:28:06 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Feb 2015 17:28:06 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <54E75EFB.9030008@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96401@DEWDFEMB12A.global.corp.sap> <54E75EFB.9030008@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96BEA@DEWDFEMB12A.global.corp.sap> Hi Jon and Dmitry, Thanks for looking at this! renamed to over_size and removed ;m: http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.04/ I please need a sponsor. Best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Friday, February 20, 2015 5:21 PM To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/18/2015 1:52 AM, Lindenmaier, Goetz wrote: Hi Jon, > Please revert to the original order of these lines > Could you define a variable to hold the heap alignment? Done. Thanks. > Should the 30*M be aligned? It works as is, so I didn't want to change it. Also, OldSize is not aligned to heap_alignment. It ends up being 10M, while heap_alignment is 32M on the machine with 64K pages. Ok. > What is the 20*m? The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. Before, the flag_value was just chosen accordingly (170M). Now I add +20M to MaxNewSize to assure this, as I have to compute MaxNewSize. Is 'overlap' a good name? Would it be accurate to change overlay (doesn't seem quite) right to over_size and to change the comment to 989 // We intentionally set MaxNewSize + OldSize > MaxHeapSize (see over_size). Either way (overlap or over_size) is acceptable so you can decide. Consider this reviewed. I don't want to delay you even longer than I have. Jon Here's the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ Thanks and best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Dienstag, 17. Februar 2015 19:57 To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: Hi Jon, thanks for looking at this change! It's not that easy as just aligning to vm_page_size, but I can use CollectorPolicy::compute_heap_alignment(): http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ Please revert to the original order of these lines unless it makes a difference. 990 set_basic_flag_values(); 991 flag_value = 30 * M; Could you define a variable to hold the heap alignment? size_t heap_alignment = CollectorPolicy::compute_heap_alignment() just to make it a little more readable. Should the 30*M be aligned? What is the 20*m? Could you assign it to a variable with a descriptive name? Jon Best regards, Goetz. From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jon Masamitsu Sent: Donnerstag, 12. Februar 2015 00:35 To: hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Goetz, Could you have used page alignment to determine the new expected sizes? For example, instead of 987 // Calculate what we expect the flag to be. 988 flag_value = adapted_InitialHeapSize - MaxNewSize; 989 verify_old_initial(flag_value); expected_old_initial = align_size_up(flag_value, os::vm_page_size()) verify_old_initial(expected_old_initial) Jon On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Feb 20 19:21:11 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Feb 2015 11:21:11 -0800 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF96BEA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96401@DEWDFEMB12A.global.corp.sap> <54E75EFB.9030008@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96BEA@DEWDFEMB12A.global.corp.sap> Message-ID: <54E78927.7090508@oracle.com> On 2/20/2015 9:28 AM, Lindenmaier, Goetz wrote: > > Hi Jon and Dmitry, > > Thanks for looking at this! > > renamed to over_size and removed ;m: > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.04/ > > > I please need a sponsor. > I'll sponsor. Jon > Best regards, > > Goetz. > > *From:*Jon Masamitsu [mailto:jon.masamitsu at oracle.com] > *Sent:* Friday, February 20, 2015 5:21 PM > *To:* Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > On 2/18/2015 1:52 AM, Lindenmaier, Goetz wrote: > > Hi Jon, > > > Please revert to the original order of these lines > > > Could you define a variable to hold the heap alignment? > > Done. > > > Thanks. > > > > Should the 30*M be aligned? > It works as is, so I didn't want to change it. Also, OldSize is not > aligned to heap_alignment. > > It ends up being 10M, while heap_alignment is 32M on the machine with > 64K pages. > > > Ok. > > > > What is the 20*m? > > The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. > Before, the > > flag_value was just chosen accordingly (170M). Now I add +20M to > MaxNewSize > > to assure this, as I have to compute MaxNewSize. > > Is 'overlap' a good name? > > > Would it be accurate to change overlay (doesn't seem quite) right to > over_size and to change the comment to > > 989 // We intentionally set MaxNewSize + OldSize > MaxHeapSize*/(see over_size)/*. > > > Either way (overlap or over_size) is acceptable so you can decide. > Consider this reviewed. I don't want to delay you even longer than I > have. > > Jon > > > Here's the new webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ > > > Thanks and best regards, > > Goetz. > > *From:*Jon Masamitsu [mailto:jon.masamitsu at oracle.com] > *Sent:* Dienstag, 17. Februar 2015 19:57 > *To:* Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net > > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: > > Hi Jon, > > thanks for looking at this change! > > It's not that easy as just aligning to vm_page_size, but I can use > > CollectorPolicy::compute_heap_alignment(): > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ > > > > Please revert to the original order of these lines unless it > makes a difference. > > 990 set_basic_flag_values(); > 991 flag_value = 30 * M; > > > Could you define a variable to hold the heap alignment? > > size_t heap_alignment = CollectorPolicy::compute_heap_alignment() > > just to make it a little more readable. > > Should the 30*M be aligned? > > What is the 20*m? Could you assign it to a variable with a descriptive > name? > > Jon > > > Best regards, > > Goetz. > > *From:*hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] > *On Behalf Of *Jon Masamitsu > *Sent:* Donnerstag, 12. Februar 2015 00:35 > *To:* hotspot-gc-dev at openjdk.java.net > > *Subject:* Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Goetz, > > Could you have used page alignment to determine the > new expected sizes? > > For example, instead of > > 987 // Calculate what we expect the flag to be. > 988 flag_value = adapted_InitialHeapSize - MaxNewSize; > 989 verify_old_initial(flag_value); > > expected_old_initial = align_size_up(flag_value, os::vm_page_size()) > verify_old_initial(expected_old_initial) > > Jon > > On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: > > Hi, > > could someone please have a look at this change? > > It's really not that big. > > GC-folks maybe? > > Thanks, > > Goetz. > > *From:*Lindenmaier, Goetz > *Sent:* Freitag, 30. Januar 2015 10:36 > *To:* hotspot-dev Source Developers > *Subject:* RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy > internal tests to support 64K pages > > Hi, > > this fixes a final problem with 64-bit page size in the jtreg tests. > > It addresses the internal VM tests of the collector policies. > > Those tests set a row of fixed flag values, and one special value > to test. > > Then they call the heap ergonomics and check the expected result > of the > > special value. > > With 64K page size, the heap ergonomics adapt more values, > breaking the tests. > > Wrt. the adapted flag values the tests are correct though. > > This change makes the expected values depend on the adapted flags, > and the > > tests pass. They only depend on adapted flags that are not subject > of the > > corresponding test. > > Please review this test. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8071822 > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Fri Feb 20 19:48:03 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 20 Feb 2015 14:48:03 -0500 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <54E6EA70.6080203@oracle.com> References: <54E6EA70.6080203@oracle.com> Message-ID: <2727810A-624D-4131-9219-00463D6DA338@oracle.com> Jon, thanks for looking at this. On Feb 20, 2015, at 3:04 AM, Jon Masamitsu wrote: > > > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/utilities/fakeRttiSupport.hpp.html > > 86 TagType _ctag; > > I'd prefer that the variable be named _concrete_tag Sure, I'll change to _concrete_tag. > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp.udiff.html > > + // Concrete tag should be BarrierSet::CardTableExtension. > + // That will presently break things in a bunch of places though. > > Can you expand on these comments. Where would the breakage occur? > > > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp.udiff.html > > - BarrierSet* bs = heap->barrier_set(); > - if (bs->is_a(BarrierSet::ModRef)) { > - ModRefBarrierSet* modBS = (ModRefBarrierSet*)bs; > + ModRefBarrierSet* modBS = barrier_set_cast(heap->barrier_set()); > > > Is this one of the place that breaks because the barrier set is really a CardTableExtension? > > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/memory/cardTableModRefBS.hpp.udiff.html > > + // Concrete tag should be BarrierSet::CardTableForRS. > + // That will presently break things in a bunch of places though. > > > Expand on this comment also about what will break. The concrete tag is used as a dispatch key in many places. I'm not sure all of those places handle BarrierSet::CardTableExtension properly. One place that I think would probably "only" be a performance regression is barrierSet.inline.hpp, where the concrete tag is used to decide whether to devirtualize the call. Since BarrierSet::CardTableForRS is new and not propogated everywhere, using it as the concrete tag would certainly break things badly for relevant collectors. There is a CR for the CardTableExtension case: https://bugs.openjdk.java.net/browse/JDK-8072817 My current thinking is to address some of this by modifications to the barrier set class hierarchy and the elimination of the use of the concrete tag in favor of (now fast) is_a() tests. For example, change the devirtualization in barrierSet.inline.hpp to use is_a(BarrierSet::CardTableModRef). That doesn't presently work, because the G1 barrier sets are derived from there; changing that would be one of the class hierarchy changes I'm thinking about. A goal of introducing barrier_set_cast is to make such refactorings easier. From goetz.lindenmaier at sap.com Fri Feb 20 21:15:42 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Feb 2015 21:15:42 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages In-Reply-To: <54E78927.7090508@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> <54DBE707.4020401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF95ACA@DEWDFEMB12A.global.corp.sap> <54E38EF2.90304@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96401@DEWDFEMB12A.global.corp.sap> <54E75EFB.9030008@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96BEA@DEWDFEMB12A.global.corp.sap> <54E78927.7090508@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96C63@DEWDFEMB12A.global.corp.sap> Thanks a lot!! Best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Friday, February 20, 2015 8:21 PM To: Lindenmaier, Goetz; 'hotspot-gc-dev at openjdk.java.net'; 'Dmitry Fazunenko' Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/20/2015 9:28 AM, Lindenmaier, Goetz wrote: Hi Jon and Dmitry, Thanks for looking at this! renamed to over_size and removed ;m: http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.04/ I please need a sponsor. I'll sponsor. Jon Best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Friday, February 20, 2015 5:21 PM To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/18/2015 1:52 AM, Lindenmaier, Goetz wrote: Hi Jon, > Please revert to the original order of these lines > Could you define a variable to hold the heap alignment? Done. Thanks. > Should the 30*M be aligned? It works as is, so I didn't want to change it. Also, OldSize is not aligned to heap_alignment. It ends up being 10M, while heap_alignment is 32M on the machine with 64K pages. Ok. > What is the 20*m? The tests wants MaxNewSize + OldSize > MaxHeapSize, see comment. Before, the flag_value was just chosen accordingly (170M). Now I add +20M to MaxNewSize to assure this, as I have to compute MaxNewSize. Is 'overlap' a good name? Would it be accurate to change overlay (doesn't seem quite) right to over_size and to change the comment to 989 // We intentionally set MaxNewSize + OldSize > MaxHeapSize (see over_size). Either way (overlap or over_size) is acceptable so you can decide. Consider this reviewed. I don't want to delay you even longer than I have. Jon Here's the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.03/ Thanks and best regards, Goetz. From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Dienstag, 17. Februar 2015 19:57 To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages On 2/16/15 8:33 AM, Lindenmaier, Goetz wrote: Hi Jon, thanks for looking at this change! It's not that easy as just aligning to vm_page_size, but I can use CollectorPolicy::compute_heap_alignment(): http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.02/ Please revert to the original order of these lines unless it makes a difference. 990 set_basic_flag_values(); 991 flag_value = 30 * M; Could you define a variable to hold the heap alignment? size_t heap_alignment = CollectorPolicy::compute_heap_alignment() just to make it a little more readable. Should the 30*M be aligned? What is the 20*m? Could you assign it to a variable with a descriptive name? Jon Best regards, Goetz. From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jon Masamitsu Sent: Donnerstag, 12. Februar 2015 00:35 To: hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Goetz, Could you have used page alignment to determine the new expected sizes? For example, instead of 987 // Calculate what we expect the flag to be. 988 flag_value = adapted_InitialHeapSize - MaxNewSize; 989 verify_old_initial(flag_value); expected_old_initial = align_size_up(flag_value, os::vm_page_size()) verify_old_initial(expected_old_initial) Jon On 2/10/2015 7:43 AM, Lindenmaier, Goetz wrote: Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Feb 20 21:27:15 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Feb 2015 13:27:15 -0800 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <2727810A-624D-4131-9219-00463D6DA338@oracle.com> References: <54E6EA70.6080203@oracle.com> <2727810A-624D-4131-9219-00463D6DA338@oracle.com> Message-ID: <54E7A6B3.9080800@oracle.com> On 2/20/2015 11:48 AM, Kim Barrett wrote: > Jon, thanks for looking at this. > > On Feb 20, 2015, at 3:04 AM, Jon Masamitsu wrote: >> >> http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/utilities/fakeRttiSupport.hpp.html >> >> 86 TagType _ctag; >> >> I'd prefer that the variable be named _concrete_tag > Sure, I'll change to _concrete_tag. > >> http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp.udiff.html >> >> + // Concrete tag should be BarrierSet::CardTableExtension. >> + // That will presently break things in a bunch of places though. >> >> Can you expand on these comments. Where would the breakage occur? >> >> >> http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp.udiff.html >> >> - BarrierSet* bs = heap->barrier_set(); >> - if (bs->is_a(BarrierSet::ModRef)) { >> - ModRefBarrierSet* modBS = (ModRefBarrierSet*)bs; >> + ModRefBarrierSet* modBS = barrier_set_cast(heap->barrier_set()); >> >> >> Is this one of the place that breaks because the barrier set is really a CardTableExtension? >> >> http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00/src/share/vm/memory/cardTableModRefBS.hpp.udiff.html >> >> + // Concrete tag should be BarrierSet::CardTableForRS. >> + // That will presently break things in a bunch of places though. >> >> >> Expand on this comment also about what will break. > The concrete tag is used as a dispatch key in many places. > > I'm not sure all of those places handle BarrierSet::CardTableExtension > properly. One place that I think would probably "only" be a > performance regression is barrierSet.inline.hpp, where the concrete > tag is used to decide whether to devirtualize the call. > > Since BarrierSet::CardTableForRS is new and not propogated everywhere, > using it as the concrete tag would certainly break things badly for > relevant collectors. > > There is a CR for the CardTableExtension case: > https://bugs.openjdk.java.net/browse/JDK-8072817 > > My current thinking is to address some of this by modifications to the > barrier set class hierarchy and the elimination of the use of the > concrete tag in favor of (now fast) is_a() tests. For example, change > the devirtualization in barrierSet.inline.hpp to use > is_a(BarrierSet::CardTableModRef). That doesn't presently work, > because the G1 barrier sets are derived from there; changing that > would be one of the class hierarchy changes I'm thinking about. > > A goal of introducing barrier_set_cast is to make such refactorings > easier. > Thanks for the additional information. I would be happy with a comment along the lines of // Concrete tag should be BarrierSet::CardTableExtension. // The concrete tag is used as a dispatch key in many places // (some yet TBD) and CardTableExtension does not correctly // dispatch in some of those uses. This will be addressed is // as part of a reorganization of the BarrierSet hierarchy. You can choose the exact words. I just thought "breaks in a bunch of places" a little lean on information. Reviewed. Jon From kim.barrett at oracle.com Fri Feb 20 23:03:41 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 20 Feb 2015 18:03:41 -0500 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <54E7A6B3.9080800@oracle.com> References: <54E6EA70.6080203@oracle.com> <2727810A-624D-4131-9219-00463D6DA338@oracle.com> <54E7A6B3.9080800@oracle.com> Message-ID: <6E5512DE-7F61-49E9-95E7-8B871B202F70@oracle.com> On Feb 20, 2015, at 4:27 PM, Jon Masamitsu wrote: > > Reviewed. Thanks for the review. From kim.barrett at oracle.com Mon Feb 23 05:40:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Feb 2015 00:40:53 -0500 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <1424443224.3267.6.camel@oracle.com> References: <1424443224.3267.6.camel@oracle.com> Message-ID: <62EF45E2-0D71-40FB-B505-E7E9F4845210@oracle.com> On Feb 20, 2015, at 9:40 AM, Thomas Schatzl wrote: > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073466 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073466/webrev/ > testing: > jprt, perf benchmarks with G1 and CMS Looks good. Thanks for the thorough description; that made the review pretty easy. One minor comment, and a couple of pre-existing issues to perhaps do something about. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp 148 void reset() { 149 _allocated = 0; 150 _wasted = 0; 151 _unused = 0; 152 } This new private helper function seems to only be used in the one place at the end of adjust_desired_plab_sz, where equivalent code used to be inline. I'm not sure making a helper function is actually beneficial here. The code that actually uses those variables is earlier in the function. Moving the reinitialization far away (and losing the comment about clearing the accumulators) doesn't seem helpful to me. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp 57 // Minimum PLAB size. 58 static const size_t min_size(); 59 // Maximum PLAB size. 60 static const size_t max_size(); Pre-existing: The const qualifier for the return types has no effect. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp 44 assert (min_size() > AlignmentReserve, "Inconsistency!"); 45 // ArrayOopDesc::header_size depends on command line initialization. 46 AlignmentReserve = oopDesc::header_size() > MinObjAlignment ? align_object_size(arrayOopDesc::header_size(T_INT)) : 0; Pre-existing: The assert on line 44 seems oddly placed, given the one and only assignment of AlignmentReserve immediately follows the assertion, and that min_size() depends on AlignmentReserve. From bengt.rutisson at oracle.com Mon Feb 23 08:46:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 23 Feb 2015 09:46:57 +0100 Subject: RFR: 8073543: Circular include dependency between psScavenge.inline.hpp and psPromotionManager.inline.hpp In-Reply-To: <54E73337.50408@oracle.com> References: <54E73337.50408@oracle.com> Message-ID: <54EAE901.90603@oracle.com> Hi StefanK, Looks good. Thanks, Bengt On 2015-02-20 14:14, Stefan Karlsson wrote: > Hi, > > Please review this patch to fix a circular dependency between > PSScavenge and PSPromotionManager: > > http://cr.openjdk.java.net/~stefank/8073543/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8073543 > > The circular dependency can be seen in this call chain: > > PSPromotionManager::process_popped_location_depth(...) > PSScavenge::copy_and_push_safe_barrier(...) > PSPromotionManager::copy_to_survivor_space(...) > > These functions are located in the psScavenge.inline.hpp and > psPromotionManager.inline.hpp. > > Before this patch we have these include paths: > psScavenge.inline.hpp -> psPromotionManager.inline.hpp > psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> > psScavenge.inline.hpp > > The patch moves PSScavenge::copy_and_push_safe_barrier to the > PSPromotionManager class and gets rid of the > psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> > psScavenge.inline.hpp > include chain. > > This change has been performance tested with SPECjbb2005 on Linux x64, > Windows x64, Solaris x64, and Solaris Sparc. > > Thanks, > SstefanK From stefan.karlsson at oracle.com Mon Feb 23 08:55:41 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 23 Feb 2015 09:55:41 +0100 Subject: RFR: 8073543: Circular include dependency between psScavenge.inline.hpp and psPromotionManager.inline.hpp In-Reply-To: <54EAE901.90603@oracle.com> References: <54E73337.50408@oracle.com> <54EAE901.90603@oracle.com> Message-ID: <54EAEB0D.7000002@oracle.com> On 2015-02-23 09:46, Bengt Rutisson wrote: > > Hi StefanK, > > Looks good. Thanks, Bengt. StefanK > > Thanks, > Bengt > > > > On 2015-02-20 14:14, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to fix a circular dependency between >> PSScavenge and PSPromotionManager: >> >> http://cr.openjdk.java.net/~stefank/8073543/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8073543 >> >> The circular dependency can be seen in this call chain: >> >> PSPromotionManager::process_popped_location_depth(...) >> PSScavenge::copy_and_push_safe_barrier(...) >> PSPromotionManager::copy_to_survivor_space(...) >> >> These functions are located in the psScavenge.inline.hpp and >> psPromotionManager.inline.hpp. >> >> Before this patch we have these include paths: >> psScavenge.inline.hpp -> psPromotionManager.inline.hpp >> psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> >> psScavenge.inline.hpp >> >> The patch moves PSScavenge::copy_and_push_safe_barrier to the >> PSPromotionManager class and gets rid of the >> psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> >> psScavenge.inline.hpp >> include chain. >> >> This change has been performance tested with SPECjbb2005 on Linux >> x64, Windows x64, Solaris x64, and Solaris Sparc. >> >> Thanks, >> SstefanK > From mikael.gerdin at oracle.com Mon Feb 23 08:58:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 23 Feb 2015 09:58:54 +0100 Subject: RFR: 8073543: Circular include dependency between psScavenge.inline.hpp and psPromotionManager.inline.hpp In-Reply-To: <54E73337.50408@oracle.com> References: <54E73337.50408@oracle.com> Message-ID: <54EAEBCE.4030908@oracle.com> Hi Stefan, On 2015-02-20 14:14, Stefan Karlsson wrote: > Hi, > > Please review this patch to fix a circular dependency between PSScavenge > and PSPromotionManager: > > http://cr.openjdk.java.net/~stefank/8073543/webrev.01 Looks good. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8073543 > > The circular dependency can be seen in this call chain: > > PSPromotionManager::process_popped_location_depth(...) > PSScavenge::copy_and_push_safe_barrier(...) > PSPromotionManager::copy_to_survivor_space(...) > > These functions are located in the psScavenge.inline.hpp and > psPromotionManager.inline.hpp. > > Before this patch we have these include paths: > psScavenge.inline.hpp -> psPromotionManager.inline.hpp > psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> > psScavenge.inline.hpp > > The patch moves PSScavenge::copy_and_push_safe_barrier to the > PSPromotionManager class and gets rid of the > psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> > psScavenge.inline.hpp > include chain. > > This change has been performance tested with SPECjbb2005 on Linux x64, > Windows x64, Solaris x64, and Solaris Sparc. > > Thanks, > SstefanK From stefan.karlsson at oracle.com Mon Feb 23 08:59:54 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 23 Feb 2015 09:59:54 +0100 Subject: RFR: 8073543: Circular include dependency between psScavenge.inline.hpp and psPromotionManager.inline.hpp In-Reply-To: <54EAEBCE.4030908@oracle.com> References: <54E73337.50408@oracle.com> <54EAEBCE.4030908@oracle.com> Message-ID: <54EAEC0A.2070105@oracle.com> On 2015-02-23 09:58, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-02-20 14:14, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to fix a circular dependency between PSScavenge >> and PSPromotionManager: >> >> http://cr.openjdk.java.net/~stefank/8073543/webrev.01 > > Looks good. Thanks. StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8073543 >> >> The circular dependency can be seen in this call chain: >> >> PSPromotionManager::process_popped_location_depth(...) >> PSScavenge::copy_and_push_safe_barrier(...) >> PSPromotionManager::copy_to_survivor_space(...) >> >> These functions are located in the psScavenge.inline.hpp and >> psPromotionManager.inline.hpp. >> >> Before this patch we have these include paths: >> psScavenge.inline.hpp -> psPromotionManager.inline.hpp >> psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> >> psScavenge.inline.hpp >> >> The patch moves PSScavenge::copy_and_push_safe_barrier to the >> PSPromotionManager class and gets rid of the >> psPromotionManager.inline.hpp -> oop.psgc.inline.hpp -> >> psScavenge.inline.hpp >> include chain. >> >> This change has been performance tested with SPECjbb2005 on Linux x64, >> Windows x64, Solaris x64, and Solaris Sparc. >> >> Thanks, >> SstefanK From thomas.schatzl at oracle.com Mon Feb 23 11:53:10 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 23 Feb 2015 12:53:10 +0100 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <62EF45E2-0D71-40FB-B505-E7E9F4845210@oracle.com> References: <1424443224.3267.6.camel@oracle.com> <62EF45E2-0D71-40FB-B505-E7E9F4845210@oracle.com> Message-ID: <1424692390.3392.2.camel@oracle.com> Hi Kim, On Mon, 2015-02-23 at 00:40 -0500, Kim Barrett wrote: > On Feb 20, 2015, at 9:40 AM, Thomas Schatzl wrote: > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8073466 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev/ > > testing: > > jprt, perf benchmarks with G1 and CMS > > Looks good. > > Thanks for the thorough description; that made the review pretty easy. > > One minor comment, and a couple of pre-existing issues to perhaps do > something about. > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp > 148 void reset() { > 149 _allocated = 0; > 150 _wasted = 0; > 151 _unused = 0; > 152 } > > This new private helper function seems to only be used in the one > place at the end of adjust_desired_plab_sz, where equivalent code used > to be inline. I'm not sure making a helper function is actually > beneficial here. The code that actually uses those variables is > earlier in the function. Moving the reinitialization far away (and > losing the comment about clearing the accumulators) doesn't seem > helpful to me. > I have around 7-8 patches building on that. The second, for JDK-8073013, makes that method virtual since I am going to make special PLAB statistics for G1. We can fix that again if that other CR still does not make the extraction of this method reasonable. > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp > 57 // Minimum PLAB size. > 58 static const size_t min_size(); > 59 // Maximum PLAB size. > 60 static const size_t max_size(); > > Pre-existing: > > The const qualifier for the return types has no effect. Removed. > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp > 44 assert (min_size() > AlignmentReserve, "Inconsistency!"); > 45 // ArrayOopDesc::header_size depends on command line initialization. > 46 AlignmentReserve = oopDesc::header_size() > MinObjAlignment ? align_object_size(arrayOopDesc::header_size(T_INT)) : 0; > > Pre-existing: > > The assert on line 44 seems oddly placed, given the one and only > assignment of AlignmentReserve immediately follows the assertion, and > that min_size() depends on AlignmentReserve. Fixed. I moved it after alignment reserve calculation. Min_size adds something to AlignmentReserve, which is always true, but one could see it as a guard against bad changes. I could also remove it if requested. New webrevs at http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/ http://cr.openjdk.java.net/~tschatzl/8073466/webrev.0_to_1/ Thanks, Thomas From kim.barrett at oracle.com Mon Feb 23 16:50:15 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Feb 2015 11:50:15 -0500 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <1424692390.3392.2.camel@oracle.com> References: <1424443224.3267.6.camel@oracle.com> <62EF45E2-0D71-40FB-B505-E7E9F4845210@oracle.com> <1424692390.3392.2.camel@oracle.com> Message-ID: On Feb 23, 2015, at 6:53 AM, Thomas Schatzl wrote: > > On Mon, 2015-02-23 at 00:40 -0500, Kim Barrett wrote: >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp >> 148 void reset() { >> 149 _allocated = 0; >> 150 _wasted = 0; >> 151 _unused = 0; >> 152 } >> >> This new private helper function seems to only be used in the one >> place at the end of adjust_desired_plab_sz, where equivalent code used >> to be inline. I'm not sure making a helper function is actually >> beneficial here. The code that actually uses those variables is >> earlier in the function. Moving the reinitialization far away (and >> losing the comment about clearing the accumulators) doesn't seem >> helpful to me. >> > > I have around 7-8 patches building on that. The second, for JDK-8073013, > makes that method virtual since I am going to make special PLAB > statistics for G1. OK. > New webrevs at > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/ > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.0_to_1/ Looks good. From sergei.kovalev at oracle.com Wed Feb 25 12:33:34 2015 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 25 Feb 2015 15:33:34 +0300 Subject: RFR(S): 8073850: Introduce needs_NMT_detail group in TEST.grouops file for jtreg execution Message-ID: <54EDC11E.20907@oracle.com> Dear All, Please review small fix in TEST.groups file. We need to put together all tests that requires NMT details output. All tests that contain in source "-XX:NativeMemoryTracking=detail" VM option added to newly created group: needs_NMT_detail. Bug: https://bugs.openjdk.java.net/browse/JDK-8073850 Webrev: http://cr.openjdk.java.net/~skovalev/8073850/webrev.00/ -- With best regards, Sergei From michail.chernov at oracle.com Wed Feb 25 12:42:19 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 25 Feb 2015 15:42:19 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54DCB396.2080807@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> Message-ID: <54EDC32B.7020605@oracle.com> Hi Bengt, I've rewritten test using JMX. I don't see here any reason to use gc log for testing this flag. http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ It seems better solution because it doesn't depend on used GC or log message format. Tested locally with JDK 9 b51 using several GC. Tested using Aurora on all platforms. Thanks, Michail On 12.02.2015 17:07, Bengt Rutisson wrote: > > Hi Michail, > > On 11/02/15 16:33, Michail Chernov wrote: >> Hi Bengt, >> >> Test works with all options passed to jtreg during testing ( see line >> 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't need to >> check all GC's, it will be done during nightly. > > Ah. I see that now. > >> >> 44 public final static String[] PARALLEL_GC_OPTIONS = >> {"UseParallelGC", "UseParallelOldGC"}; >> Here is defined special options. If define one of these options - >> will be used other pattern to match output. > > Right. > >> >> But it seems to me a little bit wrong. I've checked output of GC log >> with different GCs and ExplicitGCInvokesConcurrent. Message "Full GC >> (System.gc())" does not appear only in case of using G1 or CMS with >> ExplicitGCInvokesConcurrent=true. Will fix it. > > OK. > > My main point was that I think the whole structure of the test is > different than how we usually write tests that verify the log output. > I would prefer if the tests look similar. Would you mind re-writing > the test to look like the other tests. > > I much prefer that you explicitly start with the GCs you want to test > than that you use the WhiteBox API to find out which GC you are running. > > I'm having a similar discussion with Dima who recently invented yet > another way to parse the GC log output from tests. I think it gets > very hard to read the tests when they do the same thing in different > ways. > > Thanks, > Bengt >> >> Thanks, >> Michail >> On 11.02.2015 16:15, Bengt Rutisson wrote: >>> >>> Hi Michail, >>> >>> On 11/02/15 13:55, Michail Chernov wrote: >>>> Hi, >>>> >>>> Still hoping for review! >>> >>> Sorry for being so late in looking at this. >>> >>> A couple of questions: >>> >>> Why does the test only test the parallel GC? DisableExplicitGC is >>> valid for all GCs. >>> >>> What do you think about writing this test similar to other tests >>> that validate the output from the GC logging? Here's an example: >>> >>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>> >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>> Hi, >>>>> >>>>> Still waiting for reviews! >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>> Hi, >>>>>> >>>>>> Can someone take a look on these changes, please? >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>>> >>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>> Hi Leonid, >>>>>>> >>>>>>> Issues were fixed: >>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>> >>>>>>> Now all testcases are executed from the same VM. >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>>> >>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Why is it needed to start VM twice for each test. It is very >>>>>>>> expensive especially for low-end devices. >>>>>>>> >>>>>>>> Is it possible to have driver which starts VM several times >>>>>>>> with different combinations of options and check it output/exit >>>>>>>> code etc? Also it would be much easier to read such test. >>>>>>>> >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review the fix with new test for DisableExplicitGC VM >>>>>>>>> flag. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>> >>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>> >>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>> >>>>>>>>> Test tries to call System.gc() and check that VM puts message >>>>>>>>> to stdout. After (in case of 4,5,6 scenarios) test tries to >>>>>>>>> change DisableExplicitGC value and calls System.gc() twice. >>>>>>>>> >>>>>>>>> Test was executed locally on linux-i586 with all available GC >>>>>>>>> and several GC-related flags. Also it was executed using >>>>>>>>> Aurora on other platforms. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Michail >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From jesper.wilhelmsson at oracle.com Wed Feb 25 12:46:03 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Feb 2015 13:46:03 +0100 Subject: RFR(S): 8073850: Introduce needs_NMT_detail group in TEST.grouops file for jtreg execution In-Reply-To: <54EDC11E.20907@oracle.com> References: <54EDC11E.20907@oracle.com> Message-ID: <54EDC40B.9020409@oracle.com> Hi, The change looks good but I would prefer if it was possible to use the @requires tag or some other way to specify in the test that this test should not be run on a specific platform. Anyway, this change will solve the immediate problem with NMT on embedded platforms for now I guess, so you have a go from me :) Thanks, /Jesper Sergei Kovalev skrev den 25/2/15 13:33: > Dear All, > > Please review small fix in TEST.groups file. We need to put together all tests > that requires NMT details output. > All tests that contain in source "-XX:NativeMemoryTracking=detail" VM option > added to newly created group: needs_NMT_detail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073850 > Webrev: http://cr.openjdk.java.net/~skovalev/8073850/webrev.00/ > From andrey.x.zakharov at oracle.com Wed Feb 25 16:50:00 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Wed, 25 Feb 2015 19:50:00 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54E4848A.2010203@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> Message-ID: <54EDFD38.6010002@oracle.com> Hi I've got rid of sum_aux_data_size and now it looks bit more massively, also remove _heap_spacer from sum to return only aux data. webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.03/ testing started on Stockholm JPRT: 2015-02-25-164030.azakharov.hs-gc-clean Observed failure of test on Solaris with ObjectAlignmentInBytes=256. Investigating. Thanks. 18.02.2015 15:24, Mikael Gerdin ?????: > Hi, > > On 2015-02-18 11:16, Thomas Schatzl wrote: >> Hi Andrey, >> >> sorry for the late review... >> >> On Thu, 2015-02-12 at 17:00 +0300, Andrey Zakharov wrote: >>> Hello. >>> Summary: test for auxiliary data in G1 fails as they cannot precisely >>> measure this aux data size. >>> I've added whitebox method to get this size. >>> I've on little question about placement of helper method >>> "sum_memory_usage", which currently placed in >>> gc_implementation/g1/heapRegionManager.hpp but it doesn't logically >>> related to HeapManager itself. >>> If you can advice me where its best place it will be wonderful. >>> >>> webrev: >>> http://cr.openjdk.java.net/~azakharov/8061715/webrev/ >>> bug: >>> JDK-8061715 gc/g1/TestShrinkAuxiliaryData15.java fails with >>> java.lang.RuntimeException: heap decommit failed - after > before >>> >>> Testing done in Stockholm's JPRT (2015-02-12-112315.azakharov.hs-gc) >>> all >>> is fine. >> >> - the changes in the VM look good, there is one point though: the method >> HeapRegionManager::get_auxiliary_data_memory_usage() not only returns >> memory information about auxiliary data structures, but includes the >> heap. >> If this is intentional, the method name should be fixed to not read >> "auxiliary". > > The sum_memory_usage doesn't seem to belong in HeapRegionManager, it > doesn't touch any class members and has no other callers. > > If you really want to factor out the additions in a separate method > I'd prefer it if you put it as a static non-class method just above > HeapRegionManager::get_auxiliary_data_memory_usage. > If you want to keep it, please change it to use pointers instead of > references, we rarely use references as output parameters since it > makes it hard to understand the code at the call site. > > A lot of the JVM code you added has 4 space indentation instead of the > correct 2 spaces. > > /Mikael > > >> >> - in the whitebox.cpp files, in WB_G1AuxiliaryMemoryUsage there seems to >> be a superfluous newline at line 327/328. >> >> - please fix copyright dates >> >> - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. >> Afaik jtreg already automatically puts all output into the log files. >> >> - line 174, I do not understand the comment. What does "if auxdata size >> will be more than page size it would not decommit auxiliary data size is >> about ~3.6% of heap size" seem to be at least two sentences. >> >> - what do the two reasons given in the comment of >> checkEnvApplicability() actually mean? I.e. why do you not run the test >> if large pages are enabled? >> >> I think the check is wrong too, it should check if UseLargePages is >> enabled I think. You should use the HotSpotDiagnosticMXBean's >> getVMOption() method. >> >> Did you check that Whitebox. >> >> The actual code does not help either. >> >> The second check just seems to check whether >> REGION_SIZE*REGIONS_TO_ALLOCATE is smaller than the heap size. Why not >> specify -Xmx of 100M directly when starting the VM instead? >> >> - it would be nice to not call the hot card cache "RSet cache". I do not >> know why the switch has been called G1ConcRSLogCacheSize, but it does >> not have to do much with the remembered set (it decreases the pressure >> on the remembered set, but it has not a lot do to with it other than >> that). >> >> Thanks, >> Thomas >> >> From andreas.eriksson at oracle.com Thu Feb 26 12:19:34 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 26 Feb 2015 13:19:34 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5485E89F.9080306@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> <5485A692.2080908@oracle.com> <5485E418.2030808@oracle.com> <5485E753.6090900@oracle.com> <5485E89F.9080306@oracle.com> Message-ID: <54EF0F56.3040202@oracle.com> Hi, trying this RFR again, since 8u40 rampdown is done now. The bug is JDK-7176220 . The jdk9 changeset still applies cleanly. Regards, Andreas On 2014-12-08 19:06, Andreas Eriksson wrote: > Ok, I'll send out a new review later then. > > Thanks, > Andreas > > On 2014-12-08 19:00, Mikael Gerdin wrote: >> >> >> On 2014-12-08 18:47, Andreas Eriksson wrote: >>> Alright. >>> Do I need to send out this review again at a later time, or could >>> someone review it and I just hold off on the push? >> >> It can be reviewed now and pushed later. But the risk is that you >> will have to re-create the patch by then and may need another round >> of reviews (though I doubt that much will move from now until 8u60). >> >> /Mikael >> >>> >>> - Andreas >>> >>> On 2014-12-08 14:24, Mikael Gerdin wrote: >>>> Andreas, >>>> >>>> On 2014-12-08 14:21, Andreas Eriksson wrote: >>>>> Hi, I would appreciate if someone could take a look at this! >>>> >>>> (I haven't looked at the patch) >>>> This P4 bugfix must be deferred from 8u40 which is in rampdown and >>>> wait until development on 8u60 is open >>>> >>>> /Mikael >>>> >>>>> >>>>> Thanks, >>>>> Andreas >>>>> >>>>> On 2014-12-01 13:28, Andreas Eriksson wrote: >>>>>> Hi, >>>>>> >>>>>> This backport of JDK-7176220 >>>>>> imported cleanly >>>>>> from the jdk9 changeset: >>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 >>>>>> >>>>>> For more information, please see the jdk9 review thread: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Andreas >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.x.zakharov at oracle.com Thu Feb 26 12:21:06 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 26 Feb 2015 15:21:06 +0300 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies Message-ID: <54EF0FB2.1080503@oracle.com> Hi, team. gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies. Ignore it for a while due its unstable even locally - GC Overtime, unexpected OOM and timeouts in a wild. Need more time to fix it. webrev: http://cr.openjdk.java.net/~azakharov/8073669/webrev/ testbug: https://bugs.openjdk.java.net/browse/JDK-8073669 Thanks. From jesper.wilhelmsson at oracle.com Thu Feb 26 12:34:31 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 26 Feb 2015 13:34:31 +0100 Subject: RFR(XS): JDK-8073883 - serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent Message-ID: <54EF12D7.4040505@oracle.com> Hi, Please review this minor fix to add -XX:-ExplicitGCInvokesConcurrent to this test. The test expects messages from a full GC and will not work if ExplicitGCInvokesConcurrent is enabled. This is a critical nightly issue (since it causes the test to fail often enough). Bug: https://bugs.openjdk.java.net/browse/JDK-8073883 Webrev: http://cr.openjdk.java.net/~jwilhelm/8073883/webrev.00/ Thanks, /Jesper From mikael.gerdin at oracle.com Thu Feb 26 12:36:07 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Feb 2015 13:36:07 +0100 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies In-Reply-To: <54EF0FB2.1080503@oracle.com> References: <54EF0FB2.1080503@oracle.com> Message-ID: <54EF1337.7030307@oracle.com> Hi Andrey On 2015-02-26 13:21, Andrey Zakharov wrote: > Hi, team. > gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies. > Ignore it for a while due its unstable even locally - GC Overtime, > unexpected OOM and timeouts in a wild. > Need more time to fix it. > > webrev: > http://cr.openjdk.java.net/~azakharov/8073669/webrev/ @ignore must be after @library, because @ignore is an alias for "@run ignore" and @library must be before all @run statements. With you change I get: $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug gc/TestSoftReferencesBehaviorOnOOME.java Directory "JTwork" not found: creating Directory "JTreport" not found: creating -------------------------------------------------- TEST: gc/TestSoftReferencesBehaviorOnOOME.java ??? TEST RESULT: Error. Parse Exception: `@library' must appear before first `@run' -------------------------------------------------- Test results: error: 1 Moving @ignore to after @library I get $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug gc/TestSoftReferencesBehaviorOnOOME.java -------------------------------------------------- TEST: gc/TestSoftReferencesBehaviorOnOOME.java JDK under test: (/localhome/java/jdk9-local/fastdebug) java version "1.9.0-internal-fastdebug" Java(TM) SE Runtime Environment (build 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00, mixed mode) ACTION: ignore -- Error. Test ignored: 4711 REASON: User specified action: run ignore 4711 TIME: 0.003 seconds messages: command: ignore 4711 reason: User specified action: run ignore 4711 elapsed time (seconds): 0.003 rerun: # @ignore: 4711 exit 1 TEST RESULT: Error. Test ignored: 4711 -------------------------------------------------- Test results: error: 1 /Mikael > > testbug: > https://bugs.openjdk.java.net/browse/JDK-8073669 > > Thanks. > > From mikael.gerdin at oracle.com Thu Feb 26 12:41:34 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Feb 2015 13:41:34 +0100 Subject: RFR(XS): JDK-8073883 - serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <54EF12D7.4040505@oracle.com> References: <54EF12D7.4040505@oracle.com> Message-ID: <54EF147E.2060404@oracle.com> Hi Jesper, On 2015-02-26 13:34, Jesper Wilhelmsson wrote: > Hi, > > Please review this minor fix to add -XX:-ExplicitGCInvokesConcurrent to > this test. The test expects messages from a full GC and will not work if > ExplicitGCInvokesConcurrent is enabled. > > This is a critical nightly issue (since it causes the test to fail often > enough). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073883 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8073883/webrev.00/ The fix looks good. I'd classify this as a small change and I don't think you need to wait 24h before integrating the fix. /Mikael > > Thanks, > /Jesper From andrey.x.zakharov at oracle.com Thu Feb 26 12:45:14 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 26 Feb 2015 15:45:14 +0300 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies In-Reply-To: <54EF1337.7030307@oracle.com> References: <54EF0FB2.1080503@oracle.com> <54EF1337.7030307@oracle.com> Message-ID: <54EF155A.4080605@oracle.com> Sorry, I need to be more attentive. Thanks, Mikael. webrev: http://cr.openjdk.java.net/~azakharov/8073669/webrev.02/ tested: locally Thanks 26.02.2015 15:36, Mikael Gerdin ?????: > Hi Andrey > > On 2015-02-26 13:21, Andrey Zakharov wrote: >> Hi, team. >> gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies. >> Ignore it for a while due its unstable even locally - GC Overtime, >> unexpected OOM and timeouts in a wild. >> Need more time to fix it. >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8073669/webrev/ > > @ignore must be after @library, because @ignore is an alias for "@run > ignore" and @library must be before all @run statements. > > With you change I get: > $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug > gc/TestSoftReferencesBehaviorOnOOME.java > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > -------------------------------------------------- > TEST: gc/TestSoftReferencesBehaviorOnOOME.java > ??? > > TEST RESULT: Error. Parse Exception: `@library' must appear before > first `@run' > -------------------------------------------------- > Test results: error: 1 > > Moving @ignore to after @library I get > $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug > gc/TestSoftReferencesBehaviorOnOOME.java > -------------------------------------------------- > TEST: gc/TestSoftReferencesBehaviorOnOOME.java > JDK under test: (/localhome/java/jdk9-local/fastdebug) > java version "1.9.0-internal-fastdebug" > Java(TM) SE Runtime Environment (build > 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00) > Java HotSpot(TM) 64-Bit Server VM (build > 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00, mixed mode) > > > ACTION: ignore -- Error. Test ignored: 4711 > REASON: User specified action: run ignore 4711 > TIME: 0.003 seconds > messages: > command: ignore 4711 > reason: User specified action: run ignore 4711 > elapsed time (seconds): 0.003 > rerun: > # @ignore: 4711 > exit 1 > > TEST RESULT: Error. Test ignored: 4711 > -------------------------------------------------- > Test results: error: 1 > > /Mikael > >> >> testbug: >> https://bugs.openjdk.java.net/browse/JDK-8073669 >> >> Thanks. >> >> From dmitry.fazunenko at oracle.com Thu Feb 26 12:51:58 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 26 Feb 2015 15:51:58 +0300 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies In-Reply-To: <54EF155A.4080605@oracle.com> References: <54EF0FB2.1080503@oracle.com> <54EF1337.7030307@oracle.com> <54EF155A.4080605@oracle.com> Message-ID: <54EF16EE.8010404@oracle.com> Hi Andrey, Please use a separate CR for test quarantining: https://bugs.openjdk.java.net/browse/JDK-8073950 Besides copyright year, the fix itself looks perfect! Thanks, Dima On 26.02.2015 15:45, Andrey Zakharov wrote: > > Sorry, I need to be more attentive. Thanks, Mikael. > > webrev: > http://cr.openjdk.java.net/~azakharov/8073669/webrev.02/ > > tested: locally > > Thanks > > 26.02.2015 15:36, Mikael Gerdin ?????: >> Hi Andrey >> >> On 2015-02-26 13:21, Andrey Zakharov wrote: >>> Hi, team. >>> gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies. >>> Ignore it for a while due its unstable even locally - GC Overtime, >>> unexpected OOM and timeouts in a wild. >>> Need more time to fix it. >>> >>> webrev: >>> http://cr.openjdk.java.net/~azakharov/8073669/webrev/ >> >> @ignore must be after @library, because @ignore is an alias for "@run >> ignore" and @library must be before all @run statements. >> >> With you change I get: >> $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug >> gc/TestSoftReferencesBehaviorOnOOME.java >> Directory "JTwork" not found: creating >> Directory "JTreport" not found: creating >> -------------------------------------------------- >> TEST: gc/TestSoftReferencesBehaviorOnOOME.java >> ??? >> >> TEST RESULT: Error. Parse Exception: `@library' must appear before >> first `@run' >> -------------------------------------------------- >> Test results: error: 1 >> >> Moving @ignore to after @library I get >> $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug >> gc/TestSoftReferencesBehaviorOnOOME.java >> -------------------------------------------------- >> TEST: gc/TestSoftReferencesBehaviorOnOOME.java >> JDK under test: (/localhome/java/jdk9-local/fastdebug) >> java version "1.9.0-internal-fastdebug" >> Java(TM) SE Runtime Environment (build >> 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00) >> Java HotSpot(TM) 64-Bit Server VM (build >> 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00, mixed mode) >> >> >> ACTION: ignore -- Error. Test ignored: 4711 >> REASON: User specified action: run ignore 4711 >> TIME: 0.003 seconds >> messages: >> command: ignore 4711 >> reason: User specified action: run ignore 4711 >> elapsed time (seconds): 0.003 >> rerun: >> # @ignore: 4711 >> exit 1 >> >> TEST RESULT: Error. Test ignored: 4711 >> -------------------------------------------------- >> Test results: error: 1 >> >> /Mikael >> >>> >>> testbug: >>> https://bugs.openjdk.java.net/browse/JDK-8073669 >>> >>> Thanks. >>> >>> > From jesper.wilhelmsson at oracle.com Thu Feb 26 13:15:17 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 26 Feb 2015 14:15:17 +0100 Subject: RFR(XS): JDK-8073883 - serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <54EF147E.2060404@oracle.com> References: <54EF12D7.4040505@oracle.com> <54EF147E.2060404@oracle.com> Message-ID: <54EF1C65.10304@oracle.com> Thanks Mikael! I agree with the small change classification and will push this in a few hours if there are no complaints. /Jesper Mikael Gerdin skrev den 26/2/15 13:41: > Hi Jesper, > > On 2015-02-26 13:34, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this minor fix to add -XX:-ExplicitGCInvokesConcurrent to >> this test. The test expects messages from a full GC and will not work if >> ExplicitGCInvokesConcurrent is enabled. >> >> This is a critical nightly issue (since it causes the test to fail often >> enough). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073883 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8073883/webrev.00/ > > The fix looks good. > I'd classify this as a small change and I don't think you need to wait 24h > before integrating the fix. > > /Mikael > >> >> Thanks, >> /Jesper From andrey.x.zakharov at oracle.com Thu Feb 26 13:18:57 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 26 Feb 2015 16:18:57 +0300 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies In-Reply-To: <54EF16EE.8010404@oracle.com> References: <54EF0FB2.1080503@oracle.com> <54EF1337.7030307@oracle.com> <54EF155A.4080605@oracle.com> <54EF16EE.8010404@oracle.com> Message-ID: <54EF1D41.8040602@oracle.com> Here is updated webrev with proper changes webrev: http://cr.openjdk.java.net/~azakharov/8073950/webrev/ Please, review. Thanks! 26.02.2015 15:51, Dmitry Fazunenko ?????: > Hi Andrey, > > Please use a separate CR for test quarantining: > https://bugs.openjdk.java.net/browse/JDK-8073950 > > Besides copyright year, the fix itself looks perfect! > > Thanks, > Dima > > > > > > On 26.02.2015 15:45, Andrey Zakharov wrote: >> >> Sorry, I need to be more attentive. Thanks, Mikael. >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8073669/webrev.02/ >> >> tested: locally >> >> Thanks >> >> 26.02.2015 15:36, Mikael Gerdin ?????: >>> Hi Andrey >>> >>> On 2015-02-26 13:21, Andrey Zakharov wrote: >>>> Hi, team. >>>> gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies. >>>> Ignore it for a while due its unstable even locally - GC Overtime, >>>> unexpected OOM and timeouts in a wild. >>>> Need more time to fix it. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~azakharov/8073669/webrev/ >>> >>> @ignore must be after @library, because @ignore is an alias for >>> "@run ignore" and @library must be before all @run statements. >>> >>> With you change I get: >>> $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug >>> gc/TestSoftReferencesBehaviorOnOOME.java >>> Directory "JTwork" not found: creating >>> Directory "JTreport" not found: creating >>> -------------------------------------------------- >>> TEST: gc/TestSoftReferencesBehaviorOnOOME.java >>> ??? >>> >>> TEST RESULT: Error. Parse Exception: `@library' must appear before >>> first `@run' >>> -------------------------------------------------- >>> Test results: error: 1 >>> >>> Moving @ignore to after @library I get >>> $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug >>> gc/TestSoftReferencesBehaviorOnOOME.java >>> -------------------------------------------------- >>> TEST: gc/TestSoftReferencesBehaviorOnOOME.java >>> JDK under test: (/localhome/java/jdk9-local/fastdebug) >>> java version "1.9.0-internal-fastdebug" >>> Java(TM) SE Runtime Environment (build >>> 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00) >>> Java HotSpot(TM) 64-Bit Server VM (build >>> 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00, mixed mode) >>> >>> >>> ACTION: ignore -- Error. Test ignored: 4711 >>> REASON: User specified action: run ignore 4711 >>> TIME: 0.003 seconds >>> messages: >>> command: ignore 4711 >>> reason: User specified action: run ignore 4711 >>> elapsed time (seconds): 0.003 >>> rerun: >>> # @ignore: 4711 >>> exit 1 >>> >>> TEST RESULT: Error. Test ignored: 4711 >>> -------------------------------------------------- >>> Test results: error: 1 >>> >>> /Mikael >>> >>>> >>>> testbug: >>>> https://bugs.openjdk.java.net/browse/JDK-8073669 >>>> >>>> Thanks. >>>> >>>> >> > From mikael.gerdin at oracle.com Thu Feb 26 14:49:39 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Feb 2015 15:49:39 +0100 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies In-Reply-To: <54EF1D41.8040602@oracle.com> References: <54EF0FB2.1080503@oracle.com> <54EF1337.7030307@oracle.com> <54EF155A.4080605@oracle.com> <54EF16EE.8010404@oracle.com> <54EF1D41.8040602@oracle.com> Message-ID: <54EF3283.3060006@oracle.com> Andrey, On 2015-02-26 14:18, Andrey Zakharov wrote: > Here is updated webrev with proper changes > webrev: > http://cr.openjdk.java.net/~azakharov/8073950/webrev/ Looks good. /Mikael > Please, review. > Thanks! > > > 26.02.2015 15:51, Dmitry Fazunenko ?????: >> Hi Andrey, >> >> Please use a separate CR for test quarantining: >> https://bugs.openjdk.java.net/browse/JDK-8073950 >> >> Besides copyright year, the fix itself looks perfect! >> >> Thanks, >> Dima >> >> >> >> >> >> On 26.02.2015 15:45, Andrey Zakharov wrote: >>> >>> Sorry, I need to be more attentive. Thanks, Mikael. >>> >>> webrev: >>> http://cr.openjdk.java.net/~azakharov/8073669/webrev.02/ >>> >>> tested: locally >>> >>> Thanks >>> >>> 26.02.2015 15:36, Mikael Gerdin ?????: >>>> Hi Andrey >>>> >>>> On 2015-02-26 13:21, Andrey Zakharov wrote: >>>>> Hi, team. >>>>> gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies. >>>>> Ignore it for a while due its unstable even locally - GC Overtime, >>>>> unexpected OOM and timeouts in a wild. >>>>> Need more time to fix it. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~azakharov/8073669/webrev/ >>>> >>>> @ignore must be after @library, because @ignore is an alias for >>>> "@run ignore" and @library must be before all @run statements. >>>> >>>> With you change I get: >>>> $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug >>>> gc/TestSoftReferencesBehaviorOnOOME.java >>>> Directory "JTwork" not found: creating >>>> Directory "JTreport" not found: creating >>>> -------------------------------------------------- >>>> TEST: gc/TestSoftReferencesBehaviorOnOOME.java >>>> ??? >>>> >>>> TEST RESULT: Error. Parse Exception: `@library' must appear before >>>> first `@run' >>>> -------------------------------------------------- >>>> Test results: error: 1 >>>> >>>> Moving @ignore to after @library I get >>>> $ jtreg -jdk:/localhome/java/jdk9-local/fastdebug >>>> gc/TestSoftReferencesBehaviorOnOOME.java >>>> -------------------------------------------------- >>>> TEST: gc/TestSoftReferencesBehaviorOnOOME.java >>>> JDK under test: (/localhome/java/jdk9-local/fastdebug) >>>> java version "1.9.0-internal-fastdebug" >>>> Java(TM) SE Runtime Environment (build >>>> 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00) >>>> Java HotSpot(TM) 64-Bit Server VM (build >>>> 1.9.0-internal-fastdebug-_2015_02_24_07_00-b00, mixed mode) >>>> >>>> >>>> ACTION: ignore -- Error. Test ignored: 4711 >>>> REASON: User specified action: run ignore 4711 >>>> TIME: 0.003 seconds >>>> messages: >>>> command: ignore 4711 >>>> reason: User specified action: run ignore 4711 >>>> elapsed time (seconds): 0.003 >>>> rerun: >>>> # @ignore: 4711 >>>> exit 1 >>>> >>>> TEST RESULT: Error. Test ignored: 4711 >>>> -------------------------------------------------- >>>> Test results: error: 1 >>>> >>>> /Mikael >>>> >>>>> >>>>> testbug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8073669 >>>>> >>>>> Thanks. >>>>> >>>>> >>> >> > From thomas.schatzl at oracle.com Thu Feb 26 15:20:43 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Feb 2015 16:20:43 +0100 Subject: RFR: 8073669 - gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies In-Reply-To: <54EF1D41.8040602@oracle.com> References: <54EF0FB2.1080503@oracle.com> <54EF1337.7030307@oracle.com> <54EF155A.4080605@oracle.com> <54EF16EE.8010404@oracle.com> <54EF1D41.8040602@oracle.com> Message-ID: <1424964043.7859.13.camel@oracle.com> Hi, On Thu, 2015-02-26 at 16:18 +0300, Andrey Zakharov wrote: > Here is updated webrev with proper changes > webrev: > http://cr.openjdk.java.net/~azakharov/8073950/webrev/ > Please, review. > Thanks! looks good. Thomas From andrey.x.zakharov at oracle.com Thu Feb 26 17:55:57 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 26 Feb 2015 20:55:57 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54EDFD38.6010002@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> Message-ID: <54EF5E2D.5020503@oracle.com> Updated test with - updated 2 spaces for c++ code and code style - updated copyrights - renamed variable hotCardTableSize - added output for current page size webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.05/ testing: yes (sthjprt 2015-02-26-172927.gtee.auxdata - I will restart solaris on complete) Thanks. >>> >>> - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. >>> Afaik jtreg already automatically puts all output into the log files. This is why this code here: OutputAnalyzer with ProcessBuilder doesn't implicitly output anything. >>> >>> - line 174, I do not understand the comment. What does "if auxdata size >>> will be more than page size it would not decommit auxiliary data >>> size is >>> about ~3.6% of heap size" seem to be at least two sentences. Fixed >>> >>> - what do the two reasons given in the comment of >>> checkEnvApplicability() actually mean? I.e. why do you not run the test >>> if large pages are enabled? I dont want to run this test on box where page size is larger than auxiliary data size for region, where decommitment wouldn't occurs for sure. From andrey.x.zakharov at oracle.com Thu Feb 26 18:03:57 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 26 Feb 2015 21:03:57 +0300 Subject: RFR: 8051984: @ignore should be placed after @test In-Reply-To: <54E247D5.6020106@oracle.com> References: <54E20B96.90509@oracle.com> <54E20FA8.4000302@oracle.com> <54E215CD.8010704@oracle.com> <54E247D5.6020106@oracle.com> Message-ID: <54EF600D.8060100@oracle.com> Do I need another review or review of Bengt is enough? Thanks. 16.02.2015 22:41, Bengt Rutisson ?????: > > Hi again, > > On 16/02/15 17:07, Andrey Zakharov wrote: >> >> 16.02.2015 18:41, Bengt Rutisson ?????: >>> >>> Hi Andrey, >>> >>> On 16/02/15 16:24, Andrey Zakharov wrote: >>>> Hi >>>>> But JDK-8019361 looks like a wrong number. It must be JDK-8051984, I think. >>>> >>>> I'm wrongly got reason of ignore bug for RFR. Thanks, Dima. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~azakharov/8051984/webrev// >>>> >>>> /bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8051984 >>>> >>>>> If so, what about other sources listed in the description: >>>>> ./test/gc/arguments/TestParallelHeapSizeFlags.java >>>>> ./test/gc/arguments/TestUseCompressedOopsErgo.java >>>>> ./test/gc/g1/TestHumongousShrinkHeap.java >>>> Its already fixed either by removing @ignore either by inserting >>>> @requires >>>> / >>>> / >>>>> Why did you change the static import of >>>>> com.oracle.java.testlibrary.Asserts? Seems unrelated to the @ignore >>>>> change and I don't think there is a reason for it either. We use static >>>>> import of the asserts a lot in our test code. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >/ >>>>> />/ Thanks./ >>>> >>>> There is nothing especial in import static here, its only serves >>>> to reduce Asserts package names in code, but it also leads to less >>>> readability and question like "what assertLessThan comes from?". >>>> Asserts.assertLessThan is better - it doesn't junk global >>>> namespace. In only this case - its only code style question. If you >>>> have any other conserns about this, please tell me. >>> >>> For people reading the hotspots tests a lot I think assertLessThan() >>> is more readable than Asserts.assertLessThan(). Please don't change >>> this for this test only. If you feel strongly about this issue I >>> think you should bring it up for a wider discussion so we can agree >>> on a guideline for how to use it. Right now it just seems like a >>> completely unrelated change that is not necessary to solve your bug. >> Ok. At least I must change Asserts.* to Asserts.assertLessThan; > > I still find it odd to do this as part of this change. But ok. > >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8051984/webrev.02/ > > Looks ok. Reviewed. > >> >> Just for information: >> in src/hs-gc/hotspot/test >> >> grep 'import com.oracle.java.testlibrary.Asserts.' -R ./ >> --exclude-dir=.hg | wc -l >> 56 >> >> grep 'import static com.oracle.java.testlibrary.Asserts.' -R ./ >> --exclude-dir=.hg | wc -l >> 66 >> >> grep 'import static com.oracle.java.testlibrary.Asserts.' -R ./gc >> --exclude-dir=.hg | wc -l >> 17 >> >> grep 'import com.oracle.java.testlibrary.Asserts.' -R ./gc >> --exclude-dir=.hg | wc -l >> 5 > > Right, so static import is the more common way for importing the asserts. > > There are also the JFR tests for hotspot: > > $ grep -r 'import static jrockit.Asserts' > jdk/test/closed/com/oracle/jfr/gc/ | wc -l > 36 > > $ grep -r 'import jrockit.Asserts' jdk/test/closed/com/oracle/jfr/gc/ > | wc -l > 3 > > Thanks, > Bengt > >> >> Thanks. >> >>> >>> Thanks, >>> Bengt >>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Fri Feb 27 11:58:38 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 27 Feb 2015 12:58:38 +0100 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <1424443224.3267.6.camel@oracle.com> References: <1424443224.3267.6.camel@oracle.com> Message-ID: <1425038318.3288.53.camel@oracle.com> Hi all, I would like to ask for one Reviewer review. Current webrevs are at: http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/ http://cr.openjdk.java.net/~tschatzl/8073466/webrev.0_to_1/ Thanks, Thomas On Fri, 2015-02-20 at 15:40 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following cleanup? It removes the buffer > retain functionality of ParGCAllocBuffer. > > It has (once I guess, but actually I am not sure because that must have > been long time ago) been used to retain the space at the end of the PLAB > for the next GC. > > Nobody uses it. So that and all related code can be removed. > > Here is a long description of changes: > > ParGCAllocBuffer::flush_stats_and_retire() is always called with true > for "end_of_gc" and false for the "retain" parameter. > When moving that into that call to retire(), you will notice that > retire() is always called with retain=false. > > Looking at ParGCAllocBuffer::retire(), if retain is always false, > _retained will never be true, which means that _retained_filler is never > used. With _retained always false, all of the asserts in retire() always > evaluate to true, so the end_of_gc parameter is useless. > > (Actually the whole _retained_filler is never loaded from, making this > entire functionality non-working in the first place). > > Now looking at what retire() does, there is actually a bug in > flush_stats_and_retire() because retire() adds to the waste (the area > between _top and _hard_top), but flush() is called first. > > Looking at the code, we also only flush stats when ResizePLAB is set, > due to performance concerns. However this means that the output provided > by PrintPLAB will not be updated if ResizePLAB is not set, which is not > desirable at all (for comparison of fragmentation with ResizePLAB > enabled). I did not see the three atomic adds as a performance problem, > as this method is called once per PLAB per GC. > > There is a small additional change in PLABStats::adjust_desired_plab_sz > where I merged the two separate "if (PrintPLAB)" statements. > > Other cleanup changes include: > - removed an obscure "XXX" comment > - removed a PRAGMA > - cleaned up includes (BlockOffsetTable - huh?) > - tried to improve comments > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073466 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073466/webrev/ > testing: > jprt, perf benchmarks with G1 and CMS > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Fri Feb 27 15:38:50 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 27 Feb 2015 16:38:50 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases Message-ID: <54F08F8A.7070901@oracle.com> Hi everyone, Can I have a couple of reviews for this cleanup change? http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8074037 This change is in preparation of adding some new phases to the G1 logging. Currently when a phase for logging parallel work should be added you need to: - add a WorkerDataArray instance variable to G1GCPhaseTimes - make sure the variable is initialized in the G1GCPhaseTimes constructor - make sure the variable is reset in the G1GCPhaseTimes constructor - make sure the variable is verfied in G1GCPhaseTimes::note_gc_end() - add printing to the G1GCPhaseTimes::print() method - add a setter method to the G1GCPhaseTimes interface - call the setter in the code where you want the time to be measured With the proposed patch this is simplified to: - add the new phase to the G1GCPhaseTimes::GCPhases enum - set up the configuration for the phase in the G1GCPhaseTimes constructor - call the generic phase setter in the code where you want the time to be measured The rest is handled automatically. The patch also introduces a new class called G1GCPhaseTimesTracker, which is a scoped object to simplify time measurements. I've also tried to move conversion of times down to when we print the log messages instead of when we store them. This removes several "* 1000.0" in the code. Eventually I would like to replace os::elapsedTime() with os::elapsed_counter(). But that should be done as a separate patch. Note that this patch does not change what the output looks like at all. The logging looks exactly the same for all logging levels. Thanks, Bengt From jesper.wilhelmsson at oracle.com Fri Feb 27 16:16:55 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 27 Feb 2015 17:16:55 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54EF5E2D.5020503@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> Message-ID: <54F09877.3070702@oracle.com> Looks good! /Jesper Andrey Zakharov skrev den 26/2/15 18:55: > Updated test with > - updated 2 spaces for c++ code and code style > - updated copyrights > - renamed variable hotCardTableSize > - added output for current page size > > webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.05/ > > testing: yes (sthjprt 2015-02-26-172927.gtee.auxdata - I will restart solaris on > complete) > > Thanks. > >>>> >>>> - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. >>>> Afaik jtreg already automatically puts all output into the log files. > This is why this code here: OutputAnalyzer with ProcessBuilder doesn't > implicitly output anything. > >>>> >>>> - line 174, I do not understand the comment. What does "if auxdata size >>>> will be more than page size it would not decommit auxiliary data size is >>>> about ~3.6% of heap size" seem to be at least two sentences. > Fixed >>>> >>>> - what do the two reasons given in the comment of >>>> checkEnvApplicability() actually mean? I.e. why do you not run the test >>>> if large pages are enabled? > I dont want to run this test on box where page size is larger than auxiliary > data size for region, where decommitment wouldn't occurs for sure. > From kim.barrett at oracle.com Fri Feb 27 23:43:29 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 27 Feb 2015 18:43:29 -0500 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54F08F8A.7070901@oracle.com> References: <54F08F8A.7070901@oracle.com> Message-ID: <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson wrote: > > Can I have a couple of reviews for this cleanup change? > > http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8074037 > > [?] > The patch also introduces a new class called G1GCPhaseTimesTracker, which is a scoped object to simplify time measurements. I've also tried to move conversion of times down to when we print the log messages instead of when we store them. This removes several "* 1000.0" in the code. Eventually I would like to replace os::elapsedTime() with os::elapsed_counter(). But that should be done as a separate patch. Before I proceed any further with this review, I feel like I'm getting lost in unit changes. In some places values of msecs used to be used but now we're using secs, right? But it seems like there might be some confusion about that, and I'm not sure whether it's me or the code that's confused. For example: src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp 1079 cost_per_card_ms = phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) _pending_cards; 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); I think the values that have been recorded in the phase_times are secs, and average_time appears to just use the values as is. So shouldn't that now be cost_per_card_secs? And the value added to _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? Oh how I wish for a units package! From sangheon.kim at oracle.com Sat Feb 28 00:15:16 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 27 Feb 2015 16:15:16 -0800 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: References: Message-ID: <54F10894.9030303@oracle.com> Hi Kim, Change looks good. But I am not a Reviewer. Thanks, Sangheon On 02/16/2015 03:16 PM, Kim Barrett wrote: > Please review this change that ensures all barrier set downcasts are > checked when running in debug mode. This is a step toward some > cleanups and changes to the barrier set class hierarchy, improving > error checking and making it easier to find places where assumptions > are being made that would be invalidated by changes. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069016 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069016/webrev.00 > > Changeset includes > > * New FakeRttiSupport utility class template. This provides some > infrastructure for performing the checks. It is intended to > ease similar changes in some other class hierarchies where ad hoc > checking or unchecked downcasts are common, such as the > CollectedHeap hierarchy. > > * Re-implementation of BarrierSet's "fake RTTI" to use > FakeRttiSupport. As part of this, BarrierSet::is_a() is now just an > integer bit test rather than a virtual function that needs to walk > up the class hierarchy. > > * Adds barrier_set_cast function template, which uses the improved > is_a() test to assert the validity of the conversion. > > * Adds BarrierSet::CardTableForRS barrier set name tag, so that all > existing classes have an associated tag. > > * Changes all C-style barrier set downcasts to use barrier_set_cast. In > most cases, this is just a mechanical translation. In some cases some > existing checks have been eliminated in favor of the check made by the > new mechanism. In a few places more extensive changes have been made, > as detailed below: > > ** In various g1_write_barrier_post() implementations, downcast to > G1SATBCardTableLoggingModRefBS rather than G1SATBCardTableModRefBS, > since the code being generated includes logging. > > ** In PSMarkSweep::invoke_no_policy(), don't bother conditionalizing > clear/invalidate of barrier set on whether the bs is a modrefbs; it > always will be for parallel scavenge collector. Similarly in > PSParallelCompact::post_compact(). > > ** For VerifyLiveClosure constructor initialization of _bs member, just > use barrier_set_cast of the heap's barrier. If the previous is_a > conditionalization failed it would just lead to a later segfault > when attempting to dereference through the NULL _bs member. > > Testing: > JPRT, local JTREG of test/[closed]/{gc,runtime}, > local RefWorkload using CMS, G1, ParallelOld > From jon.masamitsu at oracle.com Sat Feb 28 00:26:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 27 Feb 2015 16:26:21 -0800 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <1425038318.3288.53.camel@oracle.com> References: <1424443224.3267.6.camel@oracle.com> <1425038318.3288.53.camel@oracle.com> Message-ID: <54F10B2D.90701@oracle.com> Thomas, http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp.frames.html Could you add a comment here that the stats are being "flushed". Something like // Flush the statistics. > 67 stats->add_allocated(_allocated); > 68 // Retire() counts the unused space as wasted. So we need to remove it again > 69 // before updating the statistics. > 70 stats->add_wasted(_wasted - unused); In a context where the unused space at the end of a buffer might be used later (as when there was the "retaining functionality"), I can see that you might want to differentiate between _wasted and unused. Since there is no longer a "retain", it seems all to be just waste. So I don't see the use of passing "_wasted - unused" as opposed to just "_wasted". If you would like to keep the differentiation between "_wasted - used" and "_wasted", consider adding back the "end_of_gc" flag to retire() and moving > 127 _wasted += pointer_delta(_end, _top); // unused space out of invalidate() and into retire() in this fashion if (!end_of_gc) { _wasted += pointer_delta(_end, _top); // unused space } http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp.frames.html Throwaway suggestion (your call, since not in your change) Fix the indentation on the fields > 39 char head[32]; > 40 size_t _word_sz; // In HeapWord units > 48 char tail[32]; Jon On 2/27/2015 3:58 AM, Thomas Schatzl wrote: > Hi all, > > I would like to ask for one Reviewer review. > > Current webrevs are at: > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/ > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.0_to_1/ > > Thanks, > Thomas > > On Fri, 2015-02-20 at 15:40 +0100, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for the following cleanup? It removes the buffer >> retain functionality of ParGCAllocBuffer. >> >> It has (once I guess, but actually I am not sure because that must have >> been long time ago) been used to retain the space at the end of the PLAB >> for the next GC. >> >> Nobody uses it. So that and all related code can be removed. >> >> Here is a long description of changes: >> >> ParGCAllocBuffer::flush_stats_and_retire() is always called with true >> for "end_of_gc" and false for the "retain" parameter. >> When moving that into that call to retire(), you will notice that >> retire() is always called with retain=false. >> >> Looking at ParGCAllocBuffer::retire(), if retain is always false, >> _retained will never be true, which means that _retained_filler is never >> used. With _retained always false, all of the asserts in retire() always >> evaluate to true, so the end_of_gc parameter is useless. >> >> (Actually the whole _retained_filler is never loaded from, making this >> entire functionality non-working in the first place). >> >> Now looking at what retire() does, there is actually a bug in >> flush_stats_and_retire() because retire() adds to the waste (the area >> between _top and _hard_top), but flush() is called first. >> >> Looking at the code, we also only flush stats when ResizePLAB is set, >> due to performance concerns. However this means that the output provided >> by PrintPLAB will not be updated if ResizePLAB is not set, which is not >> desirable at all (for comparison of fragmentation with ResizePLAB >> enabled). I did not see the three atomic adds as a performance problem, >> as this method is called once per PLAB per GC. >> >> There is a small additional change in PLABStats::adjust_desired_plab_sz >> where I merged the two separate "if (PrintPLAB)" statements. >> >> Other cleanup changes include: >> - removed an obscure "XXX" comment >> - removed a PRAGMA >> - cleaned up includes (BlockOffsetTable - huh?) >> - tried to improve comments >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073466 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8073466/webrev/ >> testing: >> jprt, perf benchmarks with G1 and CMS >> >> Thanks, >> Thomas >> >> > From kim.barrett at oracle.com Sat Feb 28 00:48:33 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 27 Feb 2015 19:48:33 -0500 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <54F10894.9030303@oracle.com> References: <54F10894.9030303@oracle.com> Message-ID: <216B4922-A458-4135-9A67-6A0E32FE694F@oracle.com> On Feb 27, 2015, at 7:15 PM, Sangheon Kim wrote: > > Change looks good. > But I am not a Reviewer. Thanks for your review. Jon has also reviewed, so now I just need a sponsor. From kim.barrett at oracle.com Sat Feb 28 00:55:23 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 27 Feb 2015 19:55:23 -0500 Subject: RFR: 8069016: Add BarrierSet downcast support In-Reply-To: <216B4922-A458-4135-9A67-6A0E32FE694F@oracle.com> References: <54F10894.9030303@oracle.com> <216B4922-A458-4135-9A67-6A0E32FE694F@oracle.com> Message-ID: On Feb 27, 2015, at 7:48 PM, Kim Barrett wrote: > > On Feb 27, 2015, at 7:15 PM, Sangheon Kim wrote: >> >> Change looks good. >> But I am not a Reviewer. > > Thanks for your review. Jon has also reviewed, so now I just need a sponsor. Except I overlooked Jon?s offer to sponsor. So I?m all set. Jon, I?ll send you the export file shortly; I?ve got a couple of trivial merge issues to address (copyright update collisions).