From marcus.larsson at oracle.com Mon Sep 1 07:43:57 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 01 Sep 2014 09:43:57 +0200 Subject: RFR (S): 8049341: Parallelize clearing the next mark bitmap In-Reply-To: <53FF0D4F.3040505@oracle.com> References: <53FF0D4F.3040505@oracle.com> Message-ID: <540423BD.7090608@oracle.com> Hi again, Updated the changeset to a more recent version, with changes suggested by Mikael. Webrev: http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8049341v2/ Marcus On 08/28/2014 01:06 PM, Marcus Larsson wrote: > Hi, > > I would like reviews for the following patch to parallelize the > clearing of the next mark bitmap in G1. > > Short summary: > The heap is divided into as many parts as there are workers and each > worker will clear its corresponding part of the bitmap. Workers will > join the suspendible thread set instead of the concurrent mark thread > to properly allow them to yield during clearing work. Added support > for applying heap region closures to a specific part of the heap. > SPECjbb2013 shows a slight performance gain with this change (4%, > using 4 concurrent threads). > > Webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8049341/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8049341 > > Testing: > jprt, SPECjbb2013, SPECjbb2005, SPECjvm2008 > > Thanks, > Marcus From mikael.gerdin at oracle.com Mon Sep 1 07:47:31 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 01 Sep 2014 09:47:31 +0200 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <540108D8.3030504@oracle.com> References: <1819337.ruQN7pby6E@mgerdin03> <540108D8.3030504@oracle.com> Message-ID: <54042493.6030101@oracle.com> Jon, On 2014-08-30 01:12, Jon Masamitsu wrote: > Mikael, > > When an nmethod is made not_entrant, > the G1CodeRootSet::remove() is called > and if the entries in the table go to 0, the > table is deleted (right?). And then a new > table is reallocated if needed again (right?) > If yes and yes, why not just keep the table? Yes and yes. I was just trying to keep memory usage down, I guess. Also, since there is no current policy for going back to a smaller table if the number of entries goes down this is a way to shrink the size if the amount of code roots pointing into a region changes without the region being evacuated. I'm not sure if it's worth it to keep the code for deallocating the table if the size goes to 0, though. /Mikael > > Jon > > > On 8/26/2014 8:42 AM, Mikael Gerdin wrote: >> Hi, >> >> In order to combat the spikes in code root migration times I suggest >> that we >> reimplement the code cache remembered set using hash tables instead of >> the >> current chunked array variant. >> >> While we're at it I suggest that we get rid of the entire migration >> phase and >> update the code cache remembered set during the parallel RSet scanning >> phase. >> The contains()-check when adding during RSet scanning is designed to >> be lock- >> free in order to reduce contention on the HRRS locks. >> This led me to remove some contains-checks in asserts since they were >> done >> during a phase where operations which could not guarantee lock-free >> reads to >> succeed were performed. >> >> Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several industry >> benchmarks and CRM Fuse (where it actually makes a difference since we >> had >> 300ms spikes in code root migration times). >> >> The table sizes in G1CodeRootSet are completely unscientific but seem >> to work >> good enough for now. An even larger table size could possibly be >> considered >> for pathological cases where we get thousands of nmethods (as can >> occur in CRM >> Fuse) but currently the two sizes seem good enough. >> >> This change depends on "JDK-8056084: Refactor Hashtable to allow >> implementations without rehashing support" since the remembered sets are >> allocated and deallocated I needed to allow for deallocation of >> instances of >> HashtableEntry and deallocation of freelist contents. >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268 >> >> a note about g1RemSetSummary.cpp >> the code failed to update _max_code_root_mem_sz, so the code to list >> the most >> expensive code root remset was broken. >> >> /Mikael > From mikael.gerdin at oracle.com Mon Sep 1 07:56:29 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 01 Sep 2014 09:56:29 +0200 Subject: RFR (S): 8049341: Parallelize clearing the next mark bitmap In-Reply-To: <540423BD.7090608@oracle.com> References: <53FF0D4F.3040505@oracle.com> <540423BD.7090608@oracle.com> Message-ID: <540426AD.4090709@oracle.com> Hi Marcus, On 2014-09-01 09:43, Marcus Larsson wrote: > Hi again, > > Updated the changeset to a more recent version, with changes suggested > by Mikael. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8049341v2/ Sorry for being picky, but please align the parameters to heap_region_par_iterate_chunked. I don't need to re-review that, let's just fix it before pushing. Otherwise it looks good. /Mikael > > Marcus > > On 08/28/2014 01:06 PM, Marcus Larsson wrote: >> Hi, >> >> I would like reviews for the following patch to parallelize the >> clearing of the next mark bitmap in G1. >> >> Short summary: >> The heap is divided into as many parts as there are workers and each >> worker will clear its corresponding part of the bitmap. Workers will >> join the suspendible thread set instead of the concurrent mark thread >> to properly allow them to yield during clearing work. Added support >> for applying heap region closures to a specific part of the heap. >> SPECjbb2013 shows a slight performance gain with this change (4%, >> using 4 concurrent threads). >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8049341/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8049341 >> >> Testing: >> jprt, SPECjbb2013, SPECjbb2005, SPECjvm2008 >> >> Thanks, >> Marcus > From thomas.schatzl at oracle.com Mon Sep 1 08:53:42 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 01 Sep 2014 10:53:42 +0200 Subject: RFR (S): 8049341: Parallelize clearing the next mark bitmap In-Reply-To: <540423BD.7090608@oracle.com> References: <53FF0D4F.3040505@oracle.com> <540423BD.7090608@oracle.com> Message-ID: <1409561622.2755.37.camel@cirrus> Hi Marcus, On Mon, 2014-09-01 at 09:43 +0200, Marcus Larsson wrote: > Hi again, > > Updated the changeset to a more recent version, with changes suggested > by Mikael. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8049341v2/ I would prefer if the parallel iteration over the heap regions used the available G1CollectedHeap::heap_region_par_iterate_chunked() mechanism. Using it avoids imbalance of work due to not all regions being available. For this, the per-region claim value (HeapRegion::_claim) should probably be extracted from the HeapRegion (where it imo does not belong in the first place) because the concurrent bitmap clear may be interrupted by young GCs that use it too. Please add a separate refactoring CR for that. Then the pattern established by other parallel gc tasks that use heap_region_par_iterate_chunked() can be reused. With the recent changes I asked this change to be updated with, this task unfortunately also got a lot harder - it includes JDK-8038423 that allows arbitrary regions to be not committed - including the corresponding bitmaps. The change does not take that into account, so the VM fails in any test stressing commit/uncommit of bitmaps. E.g. fails at the assert at heapRegionmanager.cpp:220 when it tries to iterate over known not-available regions. Another requirement that is not met is that the current parallel code must cancel all further clearing of all threads as soon any thread yields and there is an abort of the concurrent mark task. Otherwise threads that do not stop after such a yield may clear valid bits added by some following initial mark. E.g. consider this sequence of GC events: conc-mark-start full gc (clears bitmap already) conc-clear-start (yields) initial-mark (does initial marking) conc-clear-continue (resumes and overwrites valid marks) > On 08/28/2014 01:06 PM, Marcus Larsson wrote: > > Hi, > > > > I would like reviews for the following patch to parallelize the > > clearing of the next mark bitmap in G1. > > > > Short summary: > > The heap is divided into as many parts as there are workers and each > > worker will clear its corresponding part of the bitmap. Workers will > > join the suspendible thread set instead of the concurrent mark thread > > to properly allow them to yield during clearing work. Added support > > for applying heap region closures to a specific part of the heap. > > SPECjbb2013 shows a slight performance gain with this change (4%, > > using 4 concurrent threads). > > > > Webrev: > > http://cr.openjdk.java.net/~brutisso/webrev-8049341/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8049341 > > > > Testing: > > jprt, SPECjbb2013, SPECjbb2005, SPECjvm2008 > > Unfortunately, these tests do not stress region commit/uncommit in combination with full gcs interrupting concurrent marking. Please use the vm.gc.compact.* tests from UTE. They are also included in the vm.gc.* testlists. Thanks, Thomas From mikael.gerdin at oracle.com Mon Sep 1 14:38:15 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 01 Sep 2014 16:38:15 +0200 Subject: Fix for JDK-8048556 (GCLocker issues): feedback and some testing please? In-Reply-To: <53FE8E90.7090508@twitter.com> References: <53FE8E90.7090508@twitter.com> Message-ID: <540484D7.6060303@oracle.com> Hi Tony, On 2014-08-28 04:06, Tony Printezis wrote: > Hi all, > > I have a fix for the GCLocker causing unnecessary young GCs issue > (JDK-8048556). Here's the webrev: > > http://cr.openjdk.java.net/~tonyp/8048556/webrev.0/ > > Any chance of a) getting some feedback on whether the fix is reasonable > and b) getting it through some testing (I did as much testing as I could > but you know how fragile the GCLocker is...)? I've started some testing on this fix (JPRT, GC test suite). > > I didn't really want to change the CollectedHeap API. However, I can't > work out another way to pass the two GC counts to the VM op without > changes to the CollectedHeap. I could have expanded the collect() method > to also accept the count arguments. However, I don't think collect() > should really be used for the GCLocker GC and I feel that a separate > method is appropriate here. I agree that it's reasonable to have a separate collect_for_gc_locker. > > I also ended up renaming an argument to a c'tor from _cause to cause, as > the former should only be used for class members. Hope that's OK. Yep, that's always bothered me. /Mikael > > Thanks, > > Tony > From andrey.x.zakharov at oracle.com Tue Sep 2 10:13:24 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Tue, 02 Sep 2014 14:13:24 +0400 Subject: RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap In-Reply-To: <538F2FEF.30105@oracle.com> References: <5374A502.5030409@oracle.com> <53835E9B.7080102@oracle.com> <538F2FEF.30105@oracle.com> Message-ID: <54059844.50202@oracle.com> Hello, team. Test scenario remains old: * Make enough space for new objects to prevent it going old. * allocate bunch of small objects, and a bit of humongous several times. * free almost all of allocated stuff. Check that heap shrinks after GC. bug: https://bugs.openjdk.java.net/browse/JDK-8041946 webrev: http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/ Currently, I've tested this patch in aurora (574717.ute.hs_jtreg.accept.full) and its looks like, despite of reducing used memory in test it continues to fail on several boxes with OOM. Thanks. On 04.06.2014 18:40, Andrey Zakharov wrote: > Hi, Dmitry. Thanks for corrections. > Here is updated webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/ > testing: > http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full > bug: https://bugs.openjdk.java.net/browse/JDK-8041946 > > > On 26.05.2014 19:32, Dmitry Fazunenko wrote: >> Hi Andrey, >> >> Sorry, it took too long from me to review you change. >> I have several comments: >> - overall fix looks good >> - I think you need to change the subject: you fix 8041946, not 8041506 >> - Replace 'TestHumongousShrinkHeap' with 'TestShrinkDefragmentedHeap' >> - Make MemoryUsagePrinter as static inner class of test (to avoid >> possible conflicts with other tests) >> - It would be good if you provide more text description to the test, >> like >> * allocate small objects mixed with humongous ones >> "ssssHssssHssssHssssHssssH" >> * release all allocated object except the last humongous one >> ".............................................H" >> * invoke gc and check that memory returned to the system (amount >> of committed memory got down) > Done >> - I'm not sure that you can predict the expected amount of committed >> memory at the end... I wouldn't use the expectedCommitted in the test >> (there are many memory consumers, not only your test, so the final >> committed should be either less or greater than expectedCommitted ) > Well, I have tested it a lot with JFR command line options, on all > platforms. I found a lag with JMX on Solaris, and just put sleep > before measure. Also I replaced run/othervm with ProcessBuilder. I'm > planning to replace it in other early our CMM tests. >> - I think you don't need to touch 'test/TEST.groups'. There is >> :needs_g1gc tests group (hs/test/closed/TEST.group) which lists all >> g1 specific tests. >> - Please provide information on how you tested your change. > http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full > > Thanks > >> >> Thanks, >> Dima >> >> >> On 15.05.2014 15:29, Andrey Zakharov wrote: >>> Hi. >>> To proper testing of free list sorting we need to defragment memory >>> with small young and humongous objects >>> This is test scenario: >>> Make enough space for new objects to prevent it going old. >>> - allocate bunch of small objects, and a bit of humongous >>> several times. >>> >>> Free almost all of allocated stuff. Check that heap shrinks after GC. >>> >>> webrev: http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8041506 >>> >>> Thanks. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Sep 2 12:04:29 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 02 Sep 2014 14:04:29 +0200 Subject: RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap In-Reply-To: <54059844.50202@oracle.com> References: <5374A502.5030409@oracle.com> <53835E9B.7080102@oracle.com> <538F2FEF.30105@oracle.com> <54059844.50202@oracle.com> Message-ID: <1409659469.2665.43.camel@cirrus> Hi, On Tue, 2014-09-02 at 14:13 +0400, Andrey Zakharov wrote: > Hello, team. > > Test scenario remains old: > * Make enough space for new objects to prevent it going old. > * allocate bunch of small objects, and a bit of humongous > several times. > * free almost all of allocated stuff. Check that heap shrinks > after GC. > bug: > https://bugs.openjdk.java.net/browse/JDK-8041946 > > webrev: > http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/ > > Currently, I've tested this patch in aurora > (574717.ute.hs_jtreg.accept.full) and its looks like, despite of > reducing used memory in test > it continues to fail on several boxes with OOM. I looked through the Aurora run, and all failures are with 32 bit system. This, and the large initial heap size (700M) suggest that this is a test bug like in JDK-8056237. After trying the test on my local 64 bit machine, the test seems to expand to 1GB at least. This seems too much for a normal 32 bit machine. I suggest to at least halve the memory requirements of both tests and then retry. There does not seem to be need to actually use that much memory: the behavior should be the same even on a much smaller heap. Thanks, Thomas > > > Thanks. > > > On 04.06.2014 18:40, Andrey Zakharov wrote: > > > Hi, Dmitry. Thanks for corrections. > > Here is updated webrev: > > http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/ > > testing: > > http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full > > bug: https://bugs.openjdk.java.net/browse/JDK-8041946 > > > > > > On 26.05.2014 19:32, Dmitry Fazunenko wrote: > > > Hi Andrey, > > > > > > Sorry, it took too long from me to review you change. > > > I have several comments: > > > - overall fix looks good > > > - I think you need to change the subject: you fix 8041946, not > > > 8041506 > > > - Replace 'TestHumongousShrinkHeap' with > > > 'TestShrinkDefragmentedHeap' > > > - Make MemoryUsagePrinter as static inner class of test (to avoid > > > possible conflicts with other tests) > > > - It would be good if you provide more text description to the > > > test, like > > > * allocate small objects mixed with humongous ones > > > "ssssHssssHssssHssssHssssH" > > > * release all allocated object except the last humongous one > > > ".............................................H" > > > * invoke gc and check that memory returned to the system > > > (amount of committed memory got down) > > Done > > > - I'm not sure that you can predict the expected amount of > > > committed memory at the end... I wouldn't use the > > > expectedCommitted in the test (there are many memory consumers, > > > not only your test, so the final committed should be either less > > > or greater than expectedCommitted ) > > Well, I have tested it a lot with JFR command line options, on all > > platforms. I found a lag with JMX on Solaris, and just put sleep > > before measure. Also I replaced run/othervm with ProcessBuilder. I'm > > planning to replace it in other early our CMM tests. > > > - I think you don't need to touch 'test/TEST.groups'. There > > > is :needs_g1gc tests group (hs/test/closed/TEST.group) which lists > > > all g1 specific tests. > > > - Please provide information on how you tested your change. > > http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full > > Thanks > > > > > > > > Thanks, > > > Dima > > > > > > > > > On 15.05.2014 15:29, Andrey Zakharov wrote: > > > > Hi. > > > > To proper testing of free list sorting we need to defragment > > > > memory with small young and humongous objects > > > > This is test scenario: > > > > Make enough space for new objects to prevent it going old. > > > > - allocate bunch of small objects, and a bit of humongous > > > > several times. > > > > > > > > Free almost all of allocated stuff. Check that heap shrinks > > > > after GC. > > > > > > > > webrev: http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8041506 > > > > > > > > Thanks. > > > > > > > > > > From thomas.schatzl at oracle.com Tue Sep 2 12:25:40 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 02 Sep 2014 14:25:40 +0200 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <1819337.ruQN7pby6E@mgerdin03> References: <1819337.ruQN7pby6E@mgerdin03> Message-ID: <1409660740.2665.47.camel@cirrus> Hi, On Tue, 2014-08-26 at 17:42 +0200, Mikael Gerdin wrote: > Hi, > > In order to combat the spikes in code root migration times I suggest that we > reimplement the code cache remembered set using hash tables instead of the > current chunked array variant. [...] > > This change depends on "JDK-8056084: Refactor Hashtable to allow > implementations without rehashing support" since the remembered sets are > allocated and deallocated I needed to allow for deallocation of instances of > HashtableEntry and deallocation of freelist contents. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268 > > a note about g1RemSetSummary.cpp > the code failed to update _max_code_root_mem_sz, so the code to list the most > expensive code root remset was broken. Looks good. One comment about naming of the lock_add_strong_code_root/add_strong_code_root methods. Typically (I think) when we provide both a method that requires existing locking and one that does the locking itself (and calls the other method), we use the combination XXX() and XXX_locked(), where the _locked() method is the one that should only be called when the locks have been taken. The current naming (lock_add... and add...) is somewhat inconsistent with other code. Do you mind fixing that? Thanks, Thomas From bengt.rutisson at oracle.com Tue Sep 2 12:50:52 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Sep 2014 14:50:52 +0200 Subject: RFR: JDK-8025564: gc/memory/UniThread/Linear1 times out during heap verification Message-ID: <5405BD2C.1040706@oracle.com> Hi all, Can I have some reviews for this fix? http://cr.openjdk.java.net/~brutisso/8025564/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8025564 From the bug report: Running the gc/vector/ObjectArrayHigh test with a fastdebug build takes 9 minutes and 21 seconds on my workstation. A little over 1 minute is spent running the test. The rest of the time (8 minutes) is spent vefirying the BOT. The reason the BOT verification takes such a long time is that for each object on the heap G1 looks up the corresponding value in the BOT and iterates forward to find the same object again. This can get very expensive since the BOT is lazily refined and may be in a state where you more or less have to iterate from the start of each heap region to find the correct object. By replacing this expesive verification with a single pass over the BOT that just verifies that the BOT has consistent values the execution time is reduced significantly. With this more explicit BOT verification the test finishes in 1 minute and 3 seconds on my workstation. Note that the requirements on the BOT are very relaxed. Basically a BOT entry can point arbitrarily far back in a HeapRegion as long as it points to an object. From that object you can then iterate forward to find the last object that you are interested in. This means that there are few values that can be considered wrong in the BOT. Thanks, Bengt From stefan.karlsson at oracle.com Tue Sep 2 13:03:26 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 02 Sep 2014 15:03:26 +0200 Subject: RFR: 8057037: Verification in ClassLoaderData::is_alive is too slow Message-ID: <5405C01E.8080600@oracle.com> Hi all, Please review this patch to remove some verification code that was added during the G1 Class Unloading project. The code was added to make sure we catch any class unloading bugs as early as possible. This verification code is run too often and is causing large GC times in our fastdebug test runs. In one of the tests I investigated, the Full GCs take 8 seconds with this verification and 0.2 seconds without it. Most of the verified pointers are already verified before and after GCs in ClassLoaderDataGraph::verify(). http://cr.openjdk.java.net/~stefank/8057037/webrev.00/ thanks, StefanK From bengt.rutisson at oracle.com Tue Sep 2 13:05:16 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Sep 2014 15:05:16 +0200 Subject: RFR: 8057037: Verification in ClassLoaderData::is_alive is too slow In-Reply-To: <5405C01E.8080600@oracle.com> References: <5405C01E.8080600@oracle.com> Message-ID: <5405C08C.5050600@oracle.com> Stefan, Looks good. Bengt On 2014-09-02 15:03, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove some verification code that was > added during the G1 Class Unloading project. The code was added to > make sure we catch any class unloading bugs as early as possible. This > verification code is run too often and is causing large GC times in > our fastdebug test runs. In one of the tests I investigated, the Full > GCs take 8 seconds with this verification and 0.2 seconds without it. > Most of the verified pointers are already verified before and after > GCs in ClassLoaderDataGraph::verify(). > > http://cr.openjdk.java.net/~stefank/8057037/webrev.00/ > > thanks, > StefanK From mikael.gerdin at oracle.com Tue Sep 2 13:16:35 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 02 Sep 2014 15:16:35 +0200 Subject: RFR: 8057037: Verification in ClassLoaderData::is_alive is too slow In-Reply-To: <5405C01E.8080600@oracle.com> References: <5405C01E.8080600@oracle.com> Message-ID: <5405C333.8070909@oracle.com> Hi Stefan, On 2014-09-02 15:03, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove some verification code that was added > during the G1 Class Unloading project. The code was added to make sure > we catch any class unloading bugs as early as possible. This > verification code is run too often and is causing large GC times in our > fastdebug test runs. In one of the tests I investigated, the Full GCs > take 8 seconds with this verification and 0.2 seconds without it. Most > of the verified pointers are already verified before and after GCs in > ClassLoaderDataGraph::verify(). > > http://cr.openjdk.java.net/~stefank/8057037/webrev.00/ Looks good. Thanks for fixing this. /Mikael > > thanks, > StefanK From mikael.gerdin at oracle.com Tue Sep 2 13:18:18 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 02 Sep 2014 15:18:18 +0200 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <1409660740.2665.47.camel@cirrus> References: <1819337.ruQN7pby6E@mgerdin03> <1409660740.2665.47.camel@cirrus> Message-ID: <5405C39A.1050201@oracle.com> Hi Thomas, On 2014-09-02 14:25, Thomas Schatzl wrote: > Hi, > > > On Tue, 2014-08-26 at 17:42 +0200, Mikael Gerdin wrote: >> Hi, >> >> In order to combat the spikes in code root migration times I suggest that we >> reimplement the code cache remembered set using hash tables instead of the >> current chunked array variant. > [...] >> >> This change depends on "JDK-8056084: Refactor Hashtable to allow >> implementations without rehashing support" since the remembered sets are >> allocated and deallocated I needed to allow for deallocation of instances of >> HashtableEntry and deallocation of freelist contents. >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268 >> >> a note about g1RemSetSummary.cpp >> the code failed to update _max_code_root_mem_sz, so the code to list the most >> expensive code root remset was broken. > > Looks good. One comment about naming of the > lock_add_strong_code_root/add_strong_code_root methods. Typically (I > think) when we provide both a method that requires existing locking and > one that does the locking itself (and calls the other method), we use > the combination XXX() and XXX_locked(), where the _locked() method is > the one that should only be called when the locks have been taken. > > The current naming (lock_add... and add...) is somewhat inconsistent > with other code. Do you mind fixing that? Sure. I've also fixed some other naming issues that Bengt brought up during a code walkthrough. Incremental webrev at: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.0_to_1/ Full webrev at: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.1/ /Mikael > > Thanks, > Thomas > From thomas.schatzl at oracle.com Tue Sep 2 13:20:40 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 02 Sep 2014 15:20:40 +0200 Subject: RFR: 8057037: Verification in ClassLoaderData::is_alive is too slow In-Reply-To: <5405C01E.8080600@oracle.com> References: <5405C01E.8080600@oracle.com> Message-ID: <1409664040.2665.65.camel@cirrus> Hi, On Tue, 2014-09-02 at 15:03 +0200, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove some verification code that was added > during the G1 Class Unloading project. The code was added to make sure > we catch any class unloading bugs as early as possible. This > verification code is run too often and is causing large GC times in our > fastdebug test runs. In one of the tests I investigated, the Full GCs > take 8 seconds with this verification and 0.2 seconds without it. Most > of the verified pointers are already verified before and after GCs in > ClassLoaderDataGraph::verify(). > > http://cr.openjdk.java.net/~stefank/8057037/webrev.00/ > looks good. Thomas From bengt.rutisson at oracle.com Tue Sep 2 13:31:57 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Sep 2014 15:31:57 +0200 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <5405C39A.1050201@oracle.com> References: <1819337.ruQN7pby6E@mgerdin03> <1409660740.2665.47.camel@cirrus> <5405C39A.1050201@oracle.com> Message-ID: <5405C6CD.50908@oracle.com> Hi Mikael, Latest webrev looks good to me. Bengt On 2014-09-02 15:18, Mikael Gerdin wrote: > Hi Thomas, > > On 2014-09-02 14:25, Thomas Schatzl wrote: >> Hi, >> >> >> On Tue, 2014-08-26 at 17:42 +0200, Mikael Gerdin wrote: >>> Hi, >>> >>> In order to combat the spikes in code root migration times I suggest >>> that we >>> reimplement the code cache remembered set using hash tables instead >>> of the >>> current chunked array variant. >> [...] >>> >>> This change depends on "JDK-8056084: Refactor Hashtable to allow >>> implementations without rehashing support" since the remembered sets >>> are >>> allocated and deallocated I needed to allow for deallocation of >>> instances of >>> HashtableEntry and deallocation of freelist contents. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/ >>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268 >>> >>> a note about g1RemSetSummary.cpp >>> the code failed to update _max_code_root_mem_sz, so the code to list >>> the most >>> expensive code root remset was broken. >> >> Looks good. One comment about naming of the >> lock_add_strong_code_root/add_strong_code_root methods. Typically (I >> think) when we provide both a method that requires existing locking and >> one that does the locking itself (and calls the other method), we use >> the combination XXX() and XXX_locked(), where the _locked() method is >> the one that should only be called when the locks have been taken. >> >> The current naming (lock_add... and add...) is somewhat inconsistent >> with other code. Do you mind fixing that? > > Sure. > I've also fixed some other naming issues that Bengt brought up during > a code walkthrough. > > Incremental webrev at: > http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.0_to_1/ > > Full webrev at: > http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.1/ > > /Mikael > >> >> Thanks, >> Thomas >> From jon.masamitsu at oracle.com Tue Sep 2 16:49:19 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 02 Sep 2014 09:49:19 -0700 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <54042493.6030101@oracle.com> References: <1819337.ruQN7pby6E@mgerdin03> <540108D8.3030504@oracle.com> <54042493.6030101@oracle.com> Message-ID: <5405F50F.6070204@oracle.com> On 9/1/2014 12:47 AM, Mikael Gerdin wrote: > Jon, > > On 2014-08-30 01:12, Jon Masamitsu wrote: >> Mikael, >> >> When an nmethod is made not_entrant, >> the G1CodeRootSet::remove() is called >> and if the entries in the table go to 0, the >> table is deleted (right?). And then a new >> table is reallocated if needed again (right?) >> If yes and yes, why not just keep the table? > > Yes and yes. > I was just trying to keep memory usage down, I guess. > Also, since there is no current policy for going back to a smaller > table if the number of entries goes down this is a way to shrink the > size if the amount of code roots pointing into a region changes > without the region being evacuated. OK. That's sufficient reason. Changes look good. I have not looked at some of the recent renaming but don't wait for me on that since Thomas and Bengt has looked at that. Reviewed. Jon > I'm not sure if it's worth it to keep the code for deallocating the > table if the size goes to 0, though. > > /Mikael > >> >> Jon >> >> >> On 8/26/2014 8:42 AM, Mikael Gerdin wrote: >>> Hi, >>> >>> In order to combat the spikes in code root migration times I suggest >>> that we >>> reimplement the code cache remembered set using hash tables instead of >>> the >>> current chunked array variant. >>> >>> While we're at it I suggest that we get rid of the entire migration >>> phase and >>> update the code cache remembered set during the parallel RSet scanning >>> phase. >>> The contains()-check when adding during RSet scanning is designed to >>> be lock- >>> free in order to reduce contention on the HRRS locks. >>> This led me to remove some contains-checks in asserts since they were >>> done >>> during a phase where operations which could not guarantee lock-free >>> reads to >>> succeed were performed. >>> >>> Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several >>> industry >>> benchmarks and CRM Fuse (where it actually makes a difference since we >>> had >>> 300ms spikes in code root migration times). >>> >>> The table sizes in G1CodeRootSet are completely unscientific but seem >>> to work >>> good enough for now. An even larger table size could possibly be >>> considered >>> for pathological cases where we get thousands of nmethods (as can >>> occur in CRM >>> Fuse) but currently the two sizes seem good enough. >>> >>> This change depends on "JDK-8056084: Refactor Hashtable to allow >>> implementations without rehashing support" since the remembered sets >>> are >>> allocated and deallocated I needed to allow for deallocation of >>> instances of >>> HashtableEntry and deallocation of freelist contents. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/ >>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268 >>> >>> a note about g1RemSetSummary.cpp >>> the code failed to update _max_code_root_mem_sz, so the code to list >>> the most >>> expensive code root remset was broken. >>> >>> /Mikael >> From mikael.gerdin at oracle.com Tue Sep 2 18:15:34 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 02 Sep 2014 20:15:34 +0200 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <5405F50F.6070204@oracle.com> References: <1819337.ruQN7pby6E@mgerdin03> <54042493.6030101@oracle.com> <5405F50F.6070204@oracle.com> Message-ID: <3518734.r9RaE60U8q@vboxbuntu> On Tuesday 02 September 2014 09.49.19 Jon Masamitsu wrote: > On 9/1/2014 12:47 AM, Mikael Gerdin wrote: > > Jon, > > > > On 2014-08-30 01:12, Jon Masamitsu wrote: > >> Mikael, > >> > >> When an nmethod is made not_entrant, > >> the G1CodeRootSet::remove() is called > >> and if the entries in the table go to 0, the > >> table is deleted (right?). And then a new > >> table is reallocated if needed again (right?) > >> If yes and yes, why not just keep the table? > > > > Yes and yes. > > I was just trying to keep memory usage down, I guess. > > Also, since there is no current policy for going back to a smaller > > table if the number of entries goes down this is a way to shrink the > > size if the amount of code roots pointing into a region changes > > without the region being evacuated. > > OK. That's sufficient reason. > > Changes look good. I have not looked at some of the recent renaming > but don't wait for me on that since Thomas and Bengt has looked at > that. Thanks Jon. I plan to push this tomorrow morning Stockholm time. /Mikael > > Reviewed. > > Jon > > > I'm not sure if it's worth it to keep the code for deallocating the > > table if the size goes to 0, though. > > > > /Mikael > > > >> Jon > >> > >> On 8/26/2014 8:42 AM, Mikael Gerdin wrote: > >>> Hi, > >>> > >>> In order to combat the spikes in code root migration times I suggest > >>> that we > >>> reimplement the code cache remembered set using hash tables instead of > >>> the > >>> current chunked array variant. > >>> > >>> While we're at it I suggest that we get rid of the entire migration > >>> phase and > >>> update the code cache remembered set during the parallel RSet scanning > >>> phase. > >>> The contains()-check when adding during RSet scanning is designed to > >>> be lock- > >>> free in order to reduce contention on the HRRS locks. > >>> This led me to remove some contains-checks in asserts since they were > >>> done > >>> during a phase where operations which could not guarantee lock-free > >>> reads to > >>> succeed were performed. > >>> > >>> Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several > >>> industry > >>> benchmarks and CRM Fuse (where it actually makes a difference since we > >>> had > >>> 300ms spikes in code root migration times). > >>> > >>> The table sizes in G1CodeRootSet are completely unscientific but seem > >>> to work > >>> good enough for now. An even larger table size could possibly be > >>> considered > >>> for pathological cases where we get thousands of nmethods (as can > >>> occur in CRM > >>> Fuse) but currently the two sizes seem good enough. > >>> > >>> This change depends on "JDK-8056084: Refactor Hashtable to allow > >>> implementations without rehashing support" since the remembered sets > >>> are > >>> allocated and deallocated I needed to allow for deallocation of > >>> instances of > >>> HashtableEntry and deallocation of freelist contents. > >>> > >>> Webrev: > >>> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/ > >>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268 > >>> > >>> a note about g1RemSetSummary.cpp > >>> the code failed to update _max_code_root_mem_sz, so the code to list > >>> the most > >>> expensive code root remset was broken. > >>> > >>> /Mikael From erik.osterlund at lnu.se Tue Sep 2 18:52:06 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 2 Sep 2014 18:52:06 +0000 Subject: Single byte CAS Message-ID: Heya guys, Any good reason why single byte CAS is emulated using a pointer word sized CAS in a loop even on platforms that support single word CAS natively (e.g. X86 using lock cmpxchgb)? Thinking this could be useful for instance for manipulating card entries faster etc. If anyone is interested in this (and there is no good reason not to do this) I could perhaps provide a patch that fixes it as I have already fixed it for my platform. /Erik From jon.masamitsu at oracle.com Tue Sep 2 20:33:24 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 02 Sep 2014 13:33:24 -0700 Subject: RFR (3*XS): Backports to 8u40 of 8054819, 8055919, 8056043 In-Reply-To: <1409219130.2658.35.camel@cirrus> References: <1409219130.2658.35.camel@cirrus> Message-ID: <54062994.9080803@oracle.com> Thomas, No correctness issues so looks good. A few minor things. Ignore them if they would make future backports less automatic. Could you fix the indentation (line-up the variables) here? http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html class RebuildRegionSetsClosure : public HeapRegionClosure { private: bool _free_list_only; HeapRegionSet* _old_set; - HeapRegionSeq* _hrs; + HeapRegionManager* _hrm; size_t _total_used; also class VerifyRegionListsClosure : public HeapRegionClosure { private: HeapRegionSet* _old_set; HeapRegionSet* _humongous_set; - HeapRegionSeq* _hrs; + HeapRegionManager* _hrm; http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp.udiff.html - RegionIdx_t from_hrs_ind = (RegionIdx_t) from_hr->hrs_index(); + RegionIdx_t from_hrs_ind = (RegionIdx_t) from_hr->hrm_index(); Variable name to from_hrm_ind ? which would flow into this change - "overflow(f: %d, t: %d)", - tid, from_hrs_ind, cur_hrs_ind); + "overflow(f: %d, t: %u)", + tid, from_hrs_ind, cur_hrm_ind); from_hrs_ind ? Reviewed. Jon On 8/28/2014 2:45 AM, Thomas Schatzl wrote: > Hi all, > > can I have a few reviews for these backports that have a few minor > merge errors? > > 8054819: Rename HeapRegionSeq to HeapRegionManager: > > There were some merge failures due to whitespace differences: > > - at HeapRegionManager::HeapRegionManager() > - in heapRegionRemSet.cpp line 497: > > if (G1TraceHeapRegionRememberedSet) { > gclog_or_tty->print_cr(" [tid %d] sparse table entry " > "overflow(f: %d, t: %d)", (*) > tid, from_hrs_ind, cur_hrs_ind); > } > > (*) the second %d has already been fixed in 9 but not in 8u > > Original webrev: > http://cr.openjdk.java.net/~tschatzl/8054819/webrev/ > New webrev: > http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/ > > 8055919: Remove dead code in G1 concurrent marking code > > Merge failures due to typos not fixed in 8uX: > > concurrentMark.hpp: > > line 946: 8u has "reponsibility", 9 has "responsibility" > line 950: 8u has "unconditinally", 9 has "unconditionally" > > concurrentMark.inline.hpp > > line 108: 8u has "incremement", 9 has "increment" > line 225: 8u has "unconditinally", 9 has "unconditionally" > > Original webrev: > http://cr.openjdk.java.net/~tschatzl/8055919/webrev.1/ > New webrev: > http://cr.openjdk.java.net/~tschatzl/8055919/webrev.8u40 > > 8037925: CMM Testing: an allocated humongous object at the end of the > heap should not prevents shrinking the heap > > had to backport this one too, no failures though. > > 8056043: G1 does not uncommit within the heap after JDK-8038423 > > There are merge errors in the test case > test/gc/g1/TestHumongousShrinkHeap.java that has been re-enabled in this > CR. The 8u test case does not have the @ignore line. > This has been added in another CR (8044132: Quarantine unstable/broken > GC tests), but that one has dependencies on many other unrelated CRs, so > I did not try to backport it. > > Original webrev: > http://cr.openjdk.java.net/~tschatzl/8056043/webrev/ > New webrev: > http://cr.openjdk.java.net/~tschatzl/8056043/webrev.8u40/ > > Please review these differences. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Sep 2 20:57:05 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 02 Sep 2014 22:57:05 +0200 Subject: RFR (3*XS): Backports to 8u40 of 8054819, 8055919, 8056043 In-Reply-To: <54062994.9080803@oracle.com> References: <1409219130.2658.35.camel@cirrus> <54062994.9080803@oracle.com> Message-ID: <1409691425.2933.12.camel@cirrus> Hi Jon, On Tue, 2014-09-02 at 13:33 -0700, Jon Masamitsu wrote: > Thomas, > > No correctness issues so looks good. > > A few minor things. Ignore them if they would make future backports > less automatic. Unfortunately it does not matter. We did not backport a few typo fixes to 8u, so we have merge errors all over the place. Also parts of the p2i()/PTR_FORMAT mess-up are not in 8u yet. So there is already quite a lot of need for manual fixing :( > > Could you fix the indentation (line-up the variables) here? > http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > class RebuildRegionSetsClosure : public HeapRegionClosure { > private: > bool _free_list_only; > HeapRegionSet* _old_set; > - HeapRegionSeq* _hrs; > + HeapRegionManager* _hrm; > size_t _total_used; > > also > > class VerifyRegionListsClosure : public HeapRegionClosure { > private: > HeapRegionSet* _old_set; > HeapRegionSet* _humongous_set; > - HeapRegionSeq* _hrs; > + HeapRegionManager* _hrm; I will look at this. Spacing seems to be correct here (at least in the jdk9 tree and the diff), but at the moment I do not have access to my 8u-tree with that change applied. If there is, I will fix it in the change mentioned below. > http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp.udiff.html > > > - RegionIdx_t from_hrs_ind = (RegionIdx_t) from_hr->hrs_index(); > + RegionIdx_t from_hrs_ind = (RegionIdx_t) from_hr->hrm_index(); > > Variable name to from_hrm_ind ? > > which would flow into this change > > - "overflow(f: %d, t: %d)", > - tid, from_hrs_ind, cur_hrs_ind); > + "overflow(f: %d, t: %u)", > + tid, from_hrs_ind, cur_hrm_ind); > > from_hrs_ind ? I already noticed that. It's not in the original change too, so I did not change that. I will fix at least the latter in a separate change. Thanks a lot, Thomas From tprintezis at twitter.com Tue Sep 2 21:14:57 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 02 Sep 2014 17:14:57 -0400 Subject: Fix for JDK-8048556 (GCLocker issues): feedback and some testing please? In-Reply-To: <540484D7.6060303@oracle.com> References: <53FE8E90.7090508@twitter.com> <540484D7.6060303@oracle.com> Message-ID: <54063351.3080306@twitter.com> Mikael, Inline. On 9/1/14, 10:38 AM, Mikael Gerdin wrote: > Hi Tony, > > On 2014-08-28 04:06, Tony Printezis wrote: >> Hi all, >> >> I have a fix for the GCLocker causing unnecessary young GCs issue >> (JDK-8048556). Here's the webrev: >> >> http://cr.openjdk.java.net/~tonyp/8048556/webrev.0/ >> >> Any chance of a) getting some feedback on whether the fix is reasonable >> and b) getting it through some testing (I did as much testing as I could >> but you know how fragile the GCLocker is...)? > > I've started some testing on this fix (JPRT, GC test suite). Thanks! >> >> I didn't really want to change the CollectedHeap API. However, I can't >> work out another way to pass the two GC counts to the VM op without >> changes to the CollectedHeap. I could have expanded the collect() method >> to also accept the count arguments. However, I don't think collect() >> should really be used for the GCLocker GC and I feel that a separate >> method is appropriate here. > > I agree that it's reasonable to have a separate collect_for_gc_locker. Definitely less confusing in the long term... >> >> I also ended up renaming an argument to a c'tor from _cause to cause, as >> the former should only be used for class members. Hope that's OK. > > Yep, that's always bothered me. I aim to please. :-) Tony >> >> Thanks, >> >> Tony >> -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From tprintezis at twitter.com Tue Sep 2 22:21:51 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 02 Sep 2014 18:21:51 -0400 Subject: The GCLocker strikes again (bad remark / GCLocker interaction) Message-ID: <540642FF.6050108@twitter.com> Hi there, In addition to the GCLocker issue I've already mentioned (JDK-8048556: unnecessary young GCs due to the GCLocker) we're also hitting a second one, which in some ways is more severe in some cases. We use quite large edens and we run with -XX:+CMSScavengeBeforeRemark to empty the eden before each remark to keep remark times reasonable. It turns out that when the remark pause is scheduled it doesn't try to synchronize with the GCLocker at all. The result is that, quite often, the scavenge before remark aborts because the GCLocker is active. This leads to substantially longer remarks. A side-effect of this is that the remark pause with the aborted scavenge is immediately followed by a GCLocker-initiated GC (with the eden being half empty). The aborted scavenge checks whether the GCLocker is active with check_active_before_gc() which tells the GCLocker to do a young GC if it's active. And the young GC is done without waiting for the eden to fill up. The issue is very easy to reproduce with a test similar to what I posted on JDK-8048556 (force concurrent cycles by adding a thread that calls System.gc() every say 10 secs and set -XX:+ExplicitGCInvokesConcurrent). I can reproduce this with the current hotspot-gc repo. We were wondering whether this is a known issue and whether someone is working on it. FWIW, the fix could be a bit tricky. Thanks, Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From thomas.schatzl at oracle.com Wed Sep 3 08:12:26 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Sep 2014 10:12:26 +0200 Subject: RFR 8048268: G1 Code Root Migration performs poorly In-Reply-To: <5405C39A.1050201@oracle.com> References: <1819337.ruQN7pby6E@mgerdin03> <1409660740.2665.47.camel@cirrus> <5405C39A.1050201@oracle.com> Message-ID: <1409731946.2657.0.camel@cirrus> Hi Mikael, On Tue, 2014-09-02 at 15:18 +0200, Mikael Gerdin wrote: > Hi Thomas, > > On 2014-09-02 14:25, Thomas Schatzl wrote: > > Hi, > >[...] > > Looks good. One comment about naming of the > > lock_add_strong_code_root/add_strong_code_root methods. Typically (I > > think) when we provide both a method that requires existing locking and > > one that does the locking itself (and calls the other method), we use > > the combination XXX() and XXX_locked(), where the _locked() method is > > the one that should only be called when the locks have been taken. > > > > The current naming (lock_add... and add...) is somewhat inconsistent > > with other code. Do you mind fixing that? > > Sure. > I've also fixed some other naming issues that Bengt brought up during a > code walkthrough. > > Incremental webrev at: > http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.0_to_1/ > > Full webrev at: > http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.1/ Looks good. Thanks. Thomas From thomas.schatzl at oracle.com Wed Sep 3 12:03:30 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Sep 2014 14:03:30 +0200 Subject: RFR (XXS): 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq Message-ID: <1409745810.6573.2.camel@cirrus> Hi all, can I have reviews for the following tiny cleanup that fixes some variable names? In JDK-8054819 the HeapRegionSeq class has been renamed to HeapRegionManager. During that, variables containing HeapRegionSeq references were renamed, changing "hrs" to "hrm". There are some missing not renamed variables heapRegionRemSet.cpp. CR: https://bugs.openjdk.java.net/browse/JDK-8057143 Webrev: http://cr.openjdk.java.net/~tschatzl/8057143/webrev/ Thanks, Thomas From jesper.wilhelmsson at oracle.com Wed Sep 3 13:34:53 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 03 Sep 2014 15:34:53 +0200 Subject: RFR (XXS): 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq In-Reply-To: <1409745810.6573.2.camel@cirrus> References: <1409745810.6573.2.camel@cirrus> Message-ID: <540718FD.4010205@oracle.com> Looks legit. Ship it! /Jesper Thomas Schatzl skrev 3/9/14 14:03: > Hi all, > > can I have reviews for the following tiny cleanup that fixes some > variable names? > > In JDK-8054819 the HeapRegionSeq class has been renamed to > HeapRegionManager. During that, variables containing HeapRegionSeq > references were renamed, changing "hrs" to "hrm". > > There are some missing not renamed variables heapRegionRemSet.cpp. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8057143 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8057143/webrev/ > > Thanks, > Thomas > > From John.Coomes at oracle.com Wed Sep 3 13:52:49 2014 From: John.Coomes at oracle.com (John.Coomes at oracle.com) Date: Wed, 3 Sep 2014 06:52:49 -0700 Subject: review request (XS): 8054970: gc src file exclusion & alt sources Message-ID: <21511.7473.12538.953609@mykonos.us.oracle.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-redhat-linux-gnu) Reply-To: John Coomes From: John Coomes Organization: Oracle Corp. X-Attribution: jwc I'd appreciate reviews of this small change to extend gc source file exclusion to alternate sources. 8054970: gc src file exclusion should exclude alternative sources http://cr.openjdk.java.net/~jcoomes/8u/8u40/8054970-gc-exclude-alt/ Thanks for any feedback. -John From tprintezis at twitter.com Wed Sep 3 14:47:16 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Wed, 03 Sep 2014 10:47:16 -0400 Subject: RFR (XXS): 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq In-Reply-To: <1409745810.6573.2.camel@cirrus> References: <1409745810.6573.2.camel@cirrus> Message-ID: <540729F4.8020405@twitter.com> Thomas, Ship it. On 9/3/14, 8:03 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following tiny cleanup that fixes some > variable names? > > In JDK-8054819 the HeapRegionSeq class has been renamed to > HeapRegionManager. During that, variables containing HeapRegionSeq > references were renamed, changing "hrs" to "hrm". > > There are some missing not renamed variables heapRegionRemSet.cpp. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8057143 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8057143/webrev/ > > Thanks, > Thomas > > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From thomas.schatzl at oracle.com Wed Sep 3 15:06:25 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Sep 2014 17:06:25 +0200 Subject: RFR (XXS): 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq In-Reply-To: <540729F4.8020405@twitter.com> References: <1409745810.6573.2.camel@cirrus> <540729F4.8020405@twitter.com> Message-ID: <1409756785.6573.4.camel@cirrus> Hi Tony, Jesper, On Wed, 2014-09-03 at 10:47 -0400, Tony Printezis wrote: > Thomas, > > Ship it. thanks for the reviews. Thomas From andrey.x.zakharov at oracle.com Wed Sep 3 16:22:47 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Wed, 03 Sep 2014 20:22:47 +0400 Subject: RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap In-Reply-To: <1409659469.2665.43.camel@cirrus> References: <5374A502.5030409@oracle.com> <53835E9B.7080102@oracle.com> <538F2FEF.30105@oracle.com> <54059844.50202@oracle.com> <1409659469.2665.43.camel@cirrus> Message-ID: <54074057.10707@oracle.com> Hi, all. I've reduced memory footprint for test. Now its passed good (577908.ute.hs_jtreg.accept.full) webrev: http://cr.openjdk.java.net/~jwilhelm/8041946/webrev.02/ Thanks. On 02.09.2014 16:04, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-02 at 14:13 +0400, Andrey Zakharov wrote: >> Hello, team. >> >> Test scenario remains old: >> * Make enough space for new objects to prevent it going old. >> * allocate bunch of small objects, and a bit of humongous >> several times. >> * free almost all of allocated stuff. Check that heap shrinks >> after GC. >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8041946 >> >> webrev: >> http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/ >> >> Currently, I've tested this patch in aurora >> (574717.ute.hs_jtreg.accept.full) and its looks like, despite of >> reducing used memory in test >> it continues to fail on several boxes with OOM. > I looked through the Aurora run, and all failures are with 32 bit > system. This, and the large initial heap size (700M) suggest that this > is a test bug like in JDK-8056237. > > After trying the test on my local 64 bit machine, the test seems to > expand to 1GB at least. This seems too much for a normal 32 bit machine. > > I suggest to at least halve the memory requirements of both tests and > then retry. > > There does not seem to be need to actually use that much memory: the > behavior should be the same even on a much smaller heap. > > Thanks, > Thomas >> >> Thanks. >> >> >> On 04.06.2014 18:40, Andrey Zakharov wrote: >> >>> Hi, Dmitry. Thanks for corrections. >>> Here is updated webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/ >>> testing: >>> http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full >>> bug: https://bugs.openjdk.java.net/browse/JDK-8041946 >>> >>> >>> On 26.05.2014 19:32, Dmitry Fazunenko wrote: >>>> Hi Andrey, >>>> >>>> Sorry, it took too long from me to review you change. >>>> I have several comments: >>>> - overall fix looks good >>>> - I think you need to change the subject: you fix 8041946, not >>>> 8041506 >>>> - Replace 'TestHumongousShrinkHeap' with >>>> 'TestShrinkDefragmentedHeap' >>>> - Make MemoryUsagePrinter as static inner class of test (to avoid >>>> possible conflicts with other tests) >>>> - It would be good if you provide more text description to the >>>> test, like >>>> * allocate small objects mixed with humongous ones >>>> "ssssHssssHssssHssssHssssH" >>>> * release all allocated object except the last humongous one >>>> ".............................................H" >>>> * invoke gc and check that memory returned to the system >>>> (amount of committed memory got down) >>> Done >>>> - I'm not sure that you can predict the expected amount of >>>> committed memory at the end... I wouldn't use the >>>> expectedCommitted in the test (there are many memory consumers, >>>> not only your test, so the final committed should be either less >>>> or greater than expectedCommitted ) >>> Well, I have tested it a lot with JFR command line options, on all >>> platforms. I found a lag with JMX on Solaris, and just put sleep >>> before measure. Also I replaced run/othervm with ProcessBuilder. I'm >>> planning to replace it in other early our CMM tests. >>>> - I think you don't need to touch 'test/TEST.groups'. There >>>> is :needs_g1gc tests group (hs/test/closed/TEST.group) which lists >>>> all g1 specific tests. >>>> - Please provide information on how you tested your change. >>> http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full >>> Thanks >>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 15.05.2014 15:29, Andrey Zakharov wrote: >>>>> Hi. >>>>> To proper testing of free list sorting we need to defragment >>>>> memory with small young and humongous objects >>>>> This is test scenario: >>>>> Make enough space for new objects to prevent it going old. >>>>> - allocate bunch of small objects, and a bit of humongous >>>>> several times. >>>>> >>>>> Free almost all of allocated stuff. Check that heap shrinks >>>>> after GC. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041506 >>>>> >>>>> Thanks. >>>>> > From jon.masamitsu at oracle.com Wed Sep 3 16:47:30 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 03 Sep 2014 09:47:30 -0700 Subject: RFR (XXS): 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq In-Reply-To: <1409745810.6573.2.camel@cirrus> References: <1409745810.6573.2.camel@cirrus> Message-ID: <54074622.8070904@oracle.com> Changes look good. Thanks. Reviewed. Jon On 9/3/2014 5:03 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following tiny cleanup that fixes some > variable names? > > In JDK-8054819 the HeapRegionSeq class has been renamed to > HeapRegionManager. During that, variables containing HeapRegionSeq > references were renamed, changing "hrs" to "hrm". > > There are some missing not renamed variables heapRegionRemSet.cpp. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8057143 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8057143/webrev/ > > Thanks, > Thomas > > From ysr1729 at gmail.com Wed Sep 3 19:11:17 2014 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 3 Sep 2014 12:11:17 -0700 Subject: The GCLocker strikes again (bad remark / GCLocker interaction) In-Reply-To: <540642FF.6050108@twitter.com> References: <540642FF.6050108@twitter.com> Message-ID: Hi Tony -- The scavenge-before-remark bailing if the gc-locker is active was an expedient solution and one that I did not expend much thought to as gc-lockers were considered infrequent enough not to affect the bottom-line by much. I can imagine though that with very frequent gc-locker activity and extremely large Edens, that this can be an issue. The fact that the scavenge might bail was already considered as some of the comments in that section of code indicate. A ticklish dilemma here is whether the CMS thread should wait for the JNI CS to clear or just plough on as is the case today. The thinking there was that it's better to have a longish remark pause because of not emptying Eden than to delay the CMS collection and risk a concurrent mode failure which would be much more expensive. As you alluded to in your email, the issue is a bit tricky because of the way scavenge before remark is currently implemented ... CMS decides to do a remark, stops all the mutators, then decides that it must do a scavenge, which now cannot be done because the gc-locker is held, so we bail from the scavenge and just do the remark pause (this is safe because no objects are moved). The whole set-up of CMS' vm-ops was predicated on the assumption of non-interference with other operations because these are in some sense "read-only" wrt the heap, so we can safely schedule the safepoint at any time without any worries about moving objects. Scavenge-before-remark is the only wrinkle in this otherwise flat and smooth landscape. I suspect the correct way to deal with this one and for all in a uniform manner might be to have vm ops that need a vacant gc-locker to be enqueued on a separate vm-ops queue whose operations are executed as soon as the gc-locker has been vacated (this would likely be all the vm-ops other than perhaps a handful of CMS vm-ops today). But this would be a fairly intrusive and delicate rewrite of the vm-op and gc-locker subsystems. A quicker point-solution might be to split the scavenge-and-remark vm-op into two separate vm ops -- one that does a (guaranteed) scavenge, followed by another that does a remark -- each in a separate safepoint, i.e. two separate vm-ops. One way to do this might be for the CMS thread to take the jni critical lock, set needs_gc() if the gc locker is active, and then wait on the jni critical lock for it to be cleared (which it will be by the last thread exiting a JNI CS) which would initiate the scavenge. If the gc locker isn't active, the scavenge can be initiated straightaway by the CMS thread in the same way that a JNI thread would have initiated it when it was the last one exiting a JNI CS.. Once the scavenge has happened, the CMS thread can then do the remark in the normal way. Some allocation would have happened in Eden between the scavenge and the remark to follow, but hopefully that would be sufficiently small as not to affect the performance of the remark. The delicate part here is the synchronization between gc locker state, the cms thread initiating the vm-op for scavenge/remark and the jni threads, but this protocol would be identical to the existing one, except that the CMS thread would now be a participant in that proctocol, which it never was before (this might call for some scaffolding in the CMS thread so it can participate). All this having been said, I am slightly surprised that remark pauses for large Edens are so poor. I would normally expect that pointers from young to old would be quite few and with the Eden being scanned multi-threaded (at sampled "top" boundaries -- perhaps this should use TLAB boundaries instead), we would be able to scale OK to larger Edens. Have you looked at the distribution of Eden scanning times during the remark pause? Does Eden scanning dominate the remark cost? (I was also wondering if it might be possible to avoid using whatever was causing such frequent gc-locker activity as a temporary workaround until the issue w/CMS is fixed?) -- ramki On Tue, Sep 2, 2014 at 3:21 PM, Tony Printezis wrote: > Hi there, > > In addition to the GCLocker issue I've already mentioned (JDK-8048556: > unnecessary young GCs due to the GCLocker) we're also hitting a second one, > which in some ways is more severe in some cases. > > We use quite large edens and we run with -XX:+CMSScavengeBeforeRemark to > empty the eden before each remark to keep remark times reasonable. It turns > out that when the remark pause is scheduled it doesn't try to synchronize > with the GCLocker at all. The result is that, quite often, the scavenge > before remark aborts because the GCLocker is active. This leads to > substantially longer remarks. > > A side-effect of this is that the remark pause with the aborted scavenge > is immediately followed by a GCLocker-initiated GC (with the eden being > half empty). The aborted scavenge checks whether the GCLocker is active > with check_active_before_gc() which tells the GCLocker to do a young GC if > it's active. And the young GC is done without waiting for the eden to fill > up. > > The issue is very easy to reproduce with a test similar to what I posted > on JDK-8048556 (force concurrent cycles by adding a thread that calls > System.gc() every say 10 secs and set -XX:+ExplicitGCInvokesConcurrent). > I can reproduce this with the current hotspot-gc repo. > > We were wondering whether this is a known issue and whether someone is > working on it. FWIW, the fix could be a bit tricky. > > Thanks, > > Tony > > -- > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > tprintezis at twitter.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Coomes at oracle.com Thu Sep 4 09:30:25 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 02:30:25 -0700 Subject: review request (S): 8057531: refactor gc arg processing code slightly Message-ID: <21512.12593.819887.681376@mykonos.us.oracle.com> Please review this small refactoring of gc argument processing code: http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ Thanks for any feedback. -John From mikael.gerdin at oracle.com Thu Sep 4 09:58:37 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Sep 2014 11:58:37 +0200 Subject: review request (S): 8057531: refactor gc arg processing code slightly In-Reply-To: <21512.12593.819887.681376@mykonos.us.oracle.com> References: <21512.12593.819887.681376@mykonos.us.oracle.com> Message-ID: <1655880.sGAVeYYZO1@mgerdin-lap> Hi John, On Thursday 04 September 2014 02.30.25 John Coomes wrote: > Please review this small refactoring of gc argument processing code: > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ I'm by no means an expert on the argument processing code but this ?ooks like a good cleanup. I noticed that the conditions for ending up in 1537 if (should_auto_select_low_pause_collector()) { from 1541 if (!UseSerialGC && 1542 !UseConcMarkSweepGC && 1543 !UseG1GC && 1544 !UseParNewGC && 1545 FLAG_IS_DEFAULT(UseParallelGC)) { to 611 return UseConcMarkSweepGC || UseG1GC || UseParallelGC || UseParallelOldGC || 612 UseParNewGC || UseSerialGC; 613 } I think that's a good change. Before your change it seems like setting -XX:+UseParallelOldGC could still end up in should_auto_select_low_pause_collector since set_parallel_gc_flags() was called after set_ergonomics_flags() and the condition only looked at UseParallelGC. The change overall looks ok to me, but I'm not a 8u Reviewer. /Mikael > > Thanks for any feedback. > > -John From thomas.schatzl at oracle.com Thu Sep 4 10:07:36 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 04 Sep 2014 12:07:36 +0200 Subject: review request (S): 8057531: refactor gc arg processing code slightly In-Reply-To: <21512.12593.819887.681376@mykonos.us.oracle.com> References: <21512.12593.819887.681376@mykonos.us.oracle.com> Message-ID: <1409825256.2707.9.camel@cirrus> Hi, On Thu, 2014-09-04 at 02:30 -0700, John Coomes wrote: > Please review this small refactoring of gc argument processing code: > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ > > Thanks for any feedback. Looks good. I am not a jdk8u Reviewer though. Thomas From jesper.wilhelmsson at oracle.com Thu Sep 4 10:45:36 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 04 Sep 2014 12:45:36 +0200 Subject: RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap In-Reply-To: <54074057.10707@oracle.com> References: <5374A502.5030409@oracle.com> <53835E9B.7080102@oracle.com> <538F2FEF.30105@oracle.com> <54059844.50202@oracle.com> <1409659469.2665.43.camel@cirrus> <54074057.10707@oracle.com> Message-ID: <540842D0.50009@oracle.com> Looks good. /Jesper Andrey Zakharov skrev 3/9/14 18:22: > Hi, all. > > I've reduced memory footprint for test. > Now its passed good (577908.ute.hs_jtreg.accept.full) > > webrev: > http://cr.openjdk.java.net/~jwilhelm/8041946/webrev.02/ > > Thanks. > > > On 02.09.2014 16:04, Thomas Schatzl wrote: >> Hi, >> >> On Tue, 2014-09-02 at 14:13 +0400, Andrey Zakharov wrote: >>> Hello, team. >>> >>> Test scenario remains old: >>> * Make enough space for new objects to prevent it going old. >>> * allocate bunch of small objects, and a bit of humongous >>> several times. >>> * free almost all of allocated stuff. Check that heap shrinks >>> after GC. >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8041946 >>> >>> webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/ >>> >>> Currently, I've tested this patch in aurora >>> (574717.ute.hs_jtreg.accept.full) and its looks like, despite of >>> reducing used memory in test >>> it continues to fail on several boxes with OOM. >> I looked through the Aurora run, and all failures are with 32 bit >> system. This, and the large initial heap size (700M) suggest that this >> is a test bug like in JDK-8056237. >> >> After trying the test on my local 64 bit machine, the test seems to >> expand to 1GB at least. This seems too much for a normal 32 bit machine. >> >> I suggest to at least halve the memory requirements of both tests and >> then retry. >> >> There does not seem to be need to actually use that much memory: the >> behavior should be the same even on a much smaller heap. >> >> Thanks, >> Thomas >>> >>> Thanks. >>> >>> >>> On 04.06.2014 18:40, Andrey Zakharov wrote: >>> >>>> Hi, Dmitry. Thanks for corrections. >>>> Here is updated webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/ >>>> testing: >>>> http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041946 >>>> >>>> >>>> On 26.05.2014 19:32, Dmitry Fazunenko wrote: >>>>> Hi Andrey, >>>>> >>>>> Sorry, it took too long from me to review you change. >>>>> I have several comments: >>>>> - overall fix looks good >>>>> - I think you need to change the subject: you fix 8041946, not >>>>> 8041506 >>>>> - Replace 'TestHumongousShrinkHeap' with >>>>> 'TestShrinkDefragmentedHeap' >>>>> - Make MemoryUsagePrinter as static inner class of test (to avoid >>>>> possible conflicts with other tests) >>>>> - It would be good if you provide more text description to the >>>>> test, like >>>>> * allocate small objects mixed with humongous ones >>>>> "ssssHssssHssssHssssHssssH" >>>>> * release all allocated object except the last humongous one >>>>> ".............................................H" >>>>> * invoke gc and check that memory returned to the system >>>>> (amount of committed memory got down) >>>> Done >>>>> - I'm not sure that you can predict the expected amount of >>>>> committed memory at the end... I wouldn't use the >>>>> expectedCommitted in the test (there are many memory consumers, >>>>> not only your test, so the final committed should be either less >>>>> or greater than expectedCommitted ) >>>> Well, I have tested it a lot with JFR command line options, on all >>>> platforms. I found a lag with JMX on Solaris, and just put sleep >>>> before measure. Also I replaced run/othervm with ProcessBuilder. I'm >>>> planning to replace it in other early our CMM tests. >>>>> - I think you don't need to touch 'test/TEST.groups'. There >>>>> is :needs_g1gc tests group (hs/test/closed/TEST.group) which lists >>>>> all g1 specific tests. >>>>> - Please provide information on how you tested your change. >>>> http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures¶meters=[batchNames]501230.ute.hs_jtreg.accept.full >>>> >>>> Thanks >>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 15.05.2014 15:29, Andrey Zakharov wrote: >>>>>> Hi. >>>>>> To proper testing of free list sorting we need to defragment >>>>>> memory with small young and humongous objects >>>>>> This is test scenario: >>>>>> Make enough space for new objects to prevent it going old. >>>>>> - allocate bunch of small objects, and a bit of humongous >>>>>> several times. >>>>>> >>>>>> Free almost all of allocated stuff. Check that heap shrinks >>>>>> after GC. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041506 >>>>>> >>>>>> Thanks. >>>>>> >> > From stefan.johansson at oracle.com Thu Sep 4 12:45:30 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 04 Sep 2014 14:45:30 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations Message-ID: <54085EEA.8060303@oracle.com> Hi, Please review these changes for: https://bugs.openjdk.java.net/browse/JDK-8057536 Webrev: http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ Summary: These changes are made to allow G1 to do context specific allocation. As part of this a G1Allocator class has be refactored out of G1CollectedHeap which can be extended to implement the specific context code. Currently only the G1DefaultAllocator is implemented, this allocator only makes use of one context to have the same behavior as prior to this enhancement. Testing: * JPRT * Manual verification * Local ute runs of vm.quick.testlist Thanks, Stefan From erik.helin at oracle.com Thu Sep 4 14:25:50 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 04 Sep 2014 16:25:50 +0200 Subject: review request (XS): 8054970: gc src file exclusion & alt sources In-Reply-To: <21511.7473.12538.953609@mykonos.us.oracle.com> References: <21511.7473.12538.953609@mykonos.us.oracle.com> Message-ID: <5408766E.9040102@oracle.com> Hi John, the change looks good. I'm not a Reviewer in jdk8u/hsx, just committer. Thanks, Erik On 2014-09-03 15:52, John.Coomes at oracle.com wrote: > X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-redhat-linux-gnu) > Reply-To: John Coomes > From: John Coomes > Organization: Oracle Corp. > X-Attribution: jwc > > I'd appreciate reviews of this small change to extend gc source file > exclusion to alternate sources. > > 8054970: gc src file exclusion should exclude alternative sources > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8054970-gc-exclude-alt/ > > Thanks for any feedback. > > -John > From stefan.karlsson at oracle.com Thu Sep 4 14:51:27 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 04 Sep 2014 16:51:27 +0200 Subject: review request (XS): 8054970: gc src file exclusion & alt sources In-Reply-To: <21511.7473.12538.953609@mykonos.us.oracle.com> References: <21511.7473.12538.953609@mykonos.us.oracle.com> Message-ID: <54087C6F.90101@oracle.com> On 2014-09-03 15:52, John.Coomes at oracle.com wrote: > X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-redhat-linux-gnu) > Reply-To: John Coomes > From: John Coomes > Organization: Oracle Corp. > X-Attribution: jwc > > I'd appreciate reviews of this small change to extend gc source file > exclusion to alternate sources. > > 8054970: gc src file exclusion should exclude alternative sources > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8054970-gc-exclude-alt/ Looks good. StefanK > > Thanks for any feedback. > > -John From mikael.gerdin at oracle.com Thu Sep 4 15:04:09 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Sep 2014 17:04:09 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <54085EEA.8060303@oracle.com> References: <54085EEA.8060303@oracle.com> Message-ID: <1657077.8dc3rYaaKs@mgerdin03> Hi Stefan, On Thursday 04 September 2014 14.45.30 Stefan Johansson wrote: > Hi, > > Please review these changes for: > https://bugs.openjdk.java.net/browse/JDK-8057536 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ g1Allocator.hpp: reuse_retaind_... => reuse_retained_... G1ParGCAllocator::allocate does not have the SurvivorAlignmentInBytes change when it was broken out from G1ParScanThreadState. g1Allocator.cpp: reuse_retaind_... => reuse_retained_... two spaces after return type of retire_alloc_buffers align parameters to flush_stats_and_retire g1CollectedHeap.hpp: align the parameters to "attempt_allocation_at_safepoint", "survivor_attempt_allocation", "old_attempt_allocation" g1CollectedHeap.cpp: You didn't move the methods of Mutator/SurvivorGC/OldGC alloc region to g1Allocator.cpp align the parameters at the call to "attempt_allocation" align the parameters to "attempt_allocation_at_safepoint" g1CollectedHeap.inline.hpp: align the parameters at the call to "attempt_allocation" align the parameters to "survivor_attempt_allocation", "old_attempt_allocation" heapRegion.cpp: HeapRegion::print_on is designed to produce short output. Can you shorten the output? Either by disabling the printout if contexts aren't used or disable it for context-0 regions. Or have a format like "C%4u". For most of the style changes I'm ok with a follow-up change to address them. The rest of the change looks ok to me. I'm not a 8u Reviewer. /Mikael > > Summary: > These changes are made to allow G1 to do context specific allocation. As > part of this a G1Allocator class has be refactored out of > G1CollectedHeap which can be extended to implement the specific context > code. Currently only the G1DefaultAllocator is implemented, this > allocator only makes use of one context to have the same behavior as > prior to this enhancement. > > Testing: > * JPRT > * Manual verification > * Local ute runs of vm.quick.testlist > > Thanks, > Stefan From bengt.rutisson at oracle.com Thu Sep 4 15:07:49 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 04 Sep 2014 17:07:49 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <54085EEA.8060303@oracle.com> References: <54085EEA.8060303@oracle.com> Message-ID: <54088045.9020707@oracle.com> Hi Stefan, On 2014-09-04 14:45, Stefan Johansson wrote: > Hi, > > Please review these changes for: > https://bugs.openjdk.java.net/browse/JDK-8057536 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ Overall I think this i a nice refactoring. Some comments below. Mostly style and code comments. Thanks, Bengt G1Allocator.java //size_t _summary_bytes_used; Should probably not be there. G1CollectedHeap.java public long used() { Address g1AllocatorAddr = g1Allocator.getValue(addr); G1Allocator allocator = (G1Allocator) VMObjectFactory.newObject(G1Allocator.class, g1AllocatorAddr); return allocator.getSummaryBytes(); } Maybe introduce a allocator() method similar to the hrm() and g1mm() methods? g1Allocator.hpp In this file we are mixing non-indented private, protected, public declarations with one-space-indented ones. Would be good to keep the same style in the file. Would it be possible to move MutatorAllocRegion, SurvivorGCAllocRegion and OldGCAllocRegion into g1AllocRegion.hpp instead? // Outside of GC pauses, the number of bytes used in all regions other // than the current allocation region. size_t _summary_bytes_used; I don't think _summary_bytes_used needs to be aligned with the previous instance variable since the comment kind of breaks up the alignment anyway. if (hr != NULL) result += hr->used(); Please add {}. class G1ParGCAllocBuffer: public ParGCAllocBuffer { private: bool _retired; Alignment of single instance variable not necessary. class G1ParGCAllocator : public CHeapObj { friend class G1ParScanThreadState; protected: G1CollectedHeap* _g1h; size_t _alloc_buffer_waste; size_t _undo_waste; void add_to_alloc_buffer_waste(size_t waste) { _alloc_buffer_waste += waste; } void add_to_undo_waste(size_t waste) { _undo_waste += waste; } Alignment... g1AllocationContext.hpp #ifndef SHARE_VM_GC_IMPLEMENTATION_G1_G1ALLOCATIONCONTEXT_HPP Should not be called ...EXT_HPP. typedef unsigned char AllocationContext_t; Don't think we normally call types _t. g1AllocRegion.cpp G1AllocRegion::uupdate_alloc_region(). Second call to trace() should probably be trace("updated"). G1AllocRegion::G1AllocRegion(). I would prefer if there was a special value in AllocationContext that could be used as a default value rather than using 0 explicitly in the initialization list here. _allocation_context(0). g1CollectedHeap.hpp Same as above. Calls like AllocationContext_t context = 0 kind of leaks what we are trying to hide with the AllocationContext_t type. Would be better with an explicit default value in AllocationContext. (Holds for this call in g1CollectedHeap.cpp too: r->set_allocation_context(0) and in heapRegion.hpp "AllocationContext_t context = 0" and in heapRegion.cpp: "set_allocation_context(0)".) // Allocation attempt during GC for a survivor object / PLAB. inline HeapWord* survivor_attempt_allocation(size_t word_size, AllocationContext_t context); // Allocation attempt during GC for an old object / PLAB. inline HeapWord* old_attempt_allocation(size_t word_size, AllocationContext_t context); Alignment. g1CollectedHeap.cpp I think the newline after this comment should be left as it was: // Methods for the GC alloc regions g1CollectedHeap.inline.hpp inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t word_size, AllocationContext_t context) { inline HeapWord* G1CollectedHeap::old_attempt_allocation(size_t word_size, AllocationContext_t context) { Alignment. g1ParScanThreadState.cpp G1ParScanThreadState::~G1ParScanThreadState() Can we introduce a G1ParGCAllocator::relese_allocator() instead of doing "delete _g1_par_allocator"? heapRegion.cpp void HeapRegion::print_on(outputStream* st) const { st->print("Context: %4u", allocation_context()); Is it worth trying to hide the formatting of allocation_context? > > Summary: > These changes are made to allow G1 to do context specific allocation. > As part of this a G1Allocator class has be refactored out of > G1CollectedHeap which can be extended to implement the specific > context code. Currently only the G1DefaultAllocator is implemented, > this allocator only makes use of one context to have the same behavior > as prior to this enhancement. > > Testing: > * JPRT > * Manual verification > * Local ute runs of vm.quick.testlist > > Thanks, > Stefan From tprintezis at twitter.com Thu Sep 4 15:20:39 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 04 Sep 2014 11:20:39 -0400 Subject: The GCLocker strikes again (bad remark / GCLocker interaction) In-Reply-To: References: <540642FF.6050108@twitter.com> Message-ID: <54088347.1070105@twitter.com> Hi Ramki, Thanks for taking the time to reply! To follow-up on a couple of points in your e-mail: "A ticklish dilemma here is whether the CMS thread should wait for the JNI CS to clear or just plough on as is the case today. The thinking there was that it's better to have a longish remark pause because of not emptying Eden than to delay the CMS collection and risk a concurrent mode failure which would be much more expensive." Yeah, it's an interesting trade-off. You're right that holding up the remark while waiting for the GCLocker to drain could cause a concurrent mode failure. And, yes, the remark could be loonger too (more cards can be potentially dirtied while we're waiting). On the other hand, if the critical sections are properly written (i.e., they are bounded / they don't block; and in our case they definitely seem to be) the remark will only be delayed by a very short amount of time. Of course, as we all know, the above "if" is really big "IF". :-) But, we should not be penalizing correctly behaving code to make sure misbehaving code doesn't misbehave even more (read this like: we can put the new behavior on a flag). Regarding a concurrent mode failure being more expensive than a longer remark: Of course! But, our remarks when a scavenge fails tend to be two orders of magnitude longer than the scavenge suceeds, so quite disruptive. From a small test run on my MacBook that's trying to cause this often: with a 3G young gen, normal remarks are 20ms-25ms, when the scavenge fails remarks last over 1 sec. "As you alluded to in your email, the issue is a bit tricky" Oh, yes. This is why, unlike JDK-8048556 (the other GCLocker issue), I didn't attempt to immediately work on a fix and opted to discuss this first on the list. "I suspect the correct way to deal with this one and for all in a uniform manner might be to have vm ops that need a vacant gc-locker to be enqueued on a separate vm-ops queue whose operations are executed as soon as the gc-locker has been vacated" I do like the idea of having a way for a VM op to indicate that it requires the GCLocker to be inactive when the threads stop. This will add all the logic "in one place" (OK, spread out on the GCLocker, VM thread, etc. but you know what I mean) and we will be able to re-use it wherever we need it, instead of re-inventing the wheel everywhere we need this. BTW, in other but related news :-), explicit GCs also suffer from this problem. So, it's possible for a System.gc() to be completely ignored if the GCLocker is active during the safepoint (I can reproduce this with both CMS and ParOld). Like remark, the code that schedules the System.gc() VM op also doesn't synchronize properly with the GCLocker. And, yes, instead of a Full GC this also causes a GCLocker-induced young GC with a non-full eden (for the same reason it happens after the remarks with the failed scavenge which I described in my original e-mail). This is another use for the "this VM op should only be scheduled when the GCLocker is inactive" feature. "All this having been said, I am slightly surprised that remark pauses for large Edens are so poor." They are quite large edens. :-) "Have you looked at the distribution of Eden scanning times during the remark pause? Does Eden scanning dominate the remark cost?" I assumed it did, the long remarks only happen when the eden is not empty. However, I haven't looked at the scanning times. Is there existing instrumentation that will tell us that? We can always add some ourselves. "(I was also wondering if it might be possible to avoid using whatever was causing such frequent gc-locker activity as a temporary workaround until the issue w/CMS is fixed?)" We're looking into this. BTW, I'll create new CRs for the remark / GCLocker interaction and the System.gc() / GCLocker interaction to properly track both issues. Tony On 9/3/14, 3:11 PM, Srinivas Ramakrishna wrote: > Hi Tony -- > > The scavenge-before-remark bailing if the gc-locker is active was an > expedient solution and one that I did not expend much thought to > as gc-lockers were considered infrequent enough not to affect the > bottom-line by much. I can imagine though that with very frequent > gc-locker > activity and extremely large Edens, that this can be an issue. The > fact that the scavenge might bail was already considered as some of the > comments in that section of code indicate. A ticklish dilemma here is > whether the CMS thread should wait for the JNI CS to clear or just plough > on as is the case today. The thinking there was that it's better to > have a longish remark pause because of not emptying Eden than to delay the > CMS collection and risk a concurrent mode failure which would be much > more expensive. > > As you alluded to in your email, the issue is a bit tricky because of > the way scavenge before remark is currently implemented ... CMS decides to > do a remark, stops all the mutators, then decides that it must do a > scavenge, which now cannot be done because the gc-locker is held, so > we bail from > the scavenge and just do the remark pause (this is safe because no > objects are moved). The whole set-up of CMS' vm-ops was predicated on the > assumption of non-interference with other operations because these are > in some sense "read-only" wrt the heap, so we can safely > schedule the safepoint at any time without any worries about moving > objects. > > Scavenge-before-remark is the only wrinkle in this otherwise flat and > smooth landscape. > > I suspect the correct way to deal with this one and for all in a > uniform manner might be to have vm ops that need a vacant gc-locker to > be enqueued on a separate vm-ops queue whose operations are executed > as soon as the gc-locker has been vacated (this would likely > be all the vm-ops other than perhaps a handful of CMS vm-ops today). > But this would be a fairly intrusive and delicate rewrite of the > vm-op and gc-locker subsystems. > > A quicker point-solution might be to split the scavenge-and-remark > vm-op into two separate vm ops -- one that does a (guaranteed) scavenge, > followed by another that does a remark -- each in a separate > safepoint, i.e. two separate vm-ops. One way to do this might be for > the CMS > thread to take the jni critical lock, set needs_gc() if the gc locker > is active, and then wait on the jni critical lock for it to be cleared > (which it > will be by the last thread exiting a JNI CS) which would initiate the > scavenge. If the gc locker isn't active, the scavenge can be initiated > straightaway > by the CMS thread in the same way that a JNI thread would have > initiated it when it was the last one exiting a JNI CS.. Once the > scavenge has > happened, the CMS thread can then do the remark in the normal way. > Some allocation would have happened in Eden between the scavenge and > the remark to follow, but hopefully that would be sufficiently small > as not to affect the performance of the remark. The delicate part here > is the > synchronization between gc locker state, the cms thread initiating the > vm-op for scavenge/remark and the jni threads, but this protocol would > be identical to the existing one, except that the CMS thread would now > be a participant in that proctocol, which it never was before (this might > call for some scaffolding in the CMS thread so it can participate). > > All this having been said, I am slightly surprised that remark pauses > for large Edens are so poor. I would normally expect that pointers > from young > to old would be quite few and with the Eden being scanned > multi-threaded (at sampled "top" boundaries -- perhaps this should use > TLAB > boundaries instead), we would be able to scale OK to larger Edens. > Have you looked at the distribution of Eden scanning times during the > remark pause? Does Eden scanning dominate the remark cost? (I was also > wondering if it might be possible to avoid using whatever was > causing such frequent gc-locker activity as a temporary workaround > until the issue w/CMS is fixed?) > > -- ramki > > > > On Tue, Sep 2, 2014 at 3:21 PM, Tony Printezis > wrote: > > Hi there, > > In addition to the GCLocker issue I've already mentioned > (JDK-8048556: unnecessary young GCs due to the GCLocker) we're > also hitting a second one, which in some ways is more severe in > some cases. > > We use quite large edens and we run with > -XX:+CMSScavengeBeforeRemark to empty the eden before each remark > to keep remark times reasonable. It turns out that when the remark > pause is scheduled it doesn't try to synchronize with the GCLocker > at all. The result is that, quite often, the scavenge before > remark aborts because the GCLocker is active. This leads to > substantially longer remarks. > > A side-effect of this is that the remark pause with the aborted > scavenge is immediately followed by a GCLocker-initiated GC (with > the eden being half empty). The aborted scavenge checks whether > the GCLocker is active with check_active_before_gc() which tells > the GCLocker to do a young GC if it's active. And the young GC is > done without waiting for the eden to fill up. > > The issue is very easy to reproduce with a test similar to what I > posted on JDK-8048556 (force concurrent cycles by adding a thread > that calls System.gc() every say 10 secs and set > -XX:+ExplicitGCInvokesConcurrent). I can reproduce this with the > current hotspot-gc repo. > > We were wondering whether this is a known issue and whether > someone is working on it. FWIW, the fix could be a bit tricky. > > Thanks, > > Tony > > -- > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > tprintezis at twitter.com > > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Thu Sep 4 15:55:33 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 04 Sep 2014 11:55:33 -0400 Subject: The GCLocker strikes again (bad remark / GCLocker interaction) In-Reply-To: <54088347.1070105@twitter.com> References: <540642FF.6050108@twitter.com> <54088347.1070105@twitter.com> Message-ID: <54088B75.5080404@twitter.com> FYI: I just created: JDK-8057573: CMSScavengeBeforeRemark ignored if GCLocker is active JDK-8057586: Explicit GC ignored if GCLocker is active Tony On 9/4/14, 11:20 AM, Tony Printezis wrote: > Hi Ramki, > > Thanks for taking the time to reply! To follow-up on a couple of > points in your e-mail: > > "A ticklish dilemma here is whether the CMS thread should wait for the > JNI CS to clear or just plough on as is the case today. The thinking > there was that it's better to have a longish remark pause because of > not emptying Eden than to delay the CMS collection and risk a > concurrent mode failure which would be much more expensive." > > Yeah, it's an interesting trade-off. You're right that holding up the > remark while waiting for the GCLocker to drain could cause a > concurrent mode failure. And, yes, the remark could be loonger too > (more cards can be potentially dirtied while we're waiting). On the > other hand, if the critical sections are properly written (i.e., they > are bounded / they don't block; and in our case they definitely seem > to be) the remark will only be delayed by a very short amount of time. > Of course, as we all know, the above "if" is really big "IF". :-) But, > we should not be penalizing correctly behaving code to make sure > misbehaving code doesn't misbehave even more (read this like: we can > put the new behavior on a flag). > > Regarding a concurrent mode failure being more expensive than a longer > remark: Of course! But, our remarks when a scavenge fails tend to be > two orders of magnitude longer than the scavenge suceeds, so quite > disruptive. From a small test run on my MacBook that's trying to cause > this often: with a 3G young gen, normal remarks are 20ms-25ms, when > the scavenge fails remarks last over 1 sec. > > "As you alluded to in your email, the issue is a bit tricky" > > Oh, yes. This is why, unlike JDK-8048556 (the other GCLocker issue), I > didn't attempt to immediately work on a fix and opted to discuss this > first on the list. > > "I suspect the correct way to deal with this one and for all in a > uniform manner might be to have vm ops that need a vacant gc-locker to > be enqueued on a separate vm-ops queue whose operations are executed > as soon as the gc-locker has been vacated" > > I do like the idea of having a way for a VM op to indicate that it > requires the GCLocker to be inactive when the threads stop. This will > add all the logic "in one place" (OK, spread out on the GCLocker, VM > thread, etc. but you know what I mean) and we will be able to re-use > it wherever we need it, instead of re-inventing the wheel everywhere > we need this. > > BTW, in other but related news :-), explicit GCs also suffer from this > problem. So, it's possible for a System.gc() to be completely ignored > if the GCLocker is active during the safepoint (I can reproduce this > with both CMS and ParOld). Like remark, the code that schedules the > System.gc() VM op also doesn't synchronize properly with the GCLocker. > And, yes, instead of a Full GC this also causes a GCLocker-induced > young GC with a non-full eden (for the same reason it happens after > the remarks with the failed scavenge which I described in my original > e-mail). This is another use for the "this VM op should only be > scheduled when the GCLocker is inactive" feature. > > "All this having been said, I am slightly surprised that remark pauses > for large Edens are so poor." > > They are quite large edens. :-) > > "Have you looked at the distribution of Eden scanning times during the > remark pause? Does Eden scanning dominate the remark cost?" > > I assumed it did, the long remarks only happen when the eden is not > empty. However, I haven't looked at the scanning times. Is there > existing instrumentation that will tell us that? We can always add > some ourselves. > > "(I was also wondering if it might be possible to avoid using whatever > was causing such frequent gc-locker activity as a temporary workaround > until the issue w/CMS is fixed?)" > > We're looking into this. > > BTW, I'll create new CRs for the remark / GCLocker interaction and the > System.gc() / GCLocker interaction to properly track both issues. > > Tony > > On 9/3/14, 3:11 PM, Srinivas Ramakrishna wrote: >> Hi Tony -- >> >> The scavenge-before-remark bailing if the gc-locker is active was an >> expedient solution and one that I did not expend much thought to >> as gc-lockers were considered infrequent enough not to affect the >> bottom-line by much. I can imagine though that with very frequent >> gc-locker >> activity and extremely large Edens, that this can be an issue. The >> fact that the scavenge might bail was already considered as some of the >> comments in that section of code indicate. A ticklish dilemma here is >> whether the CMS thread should wait for the JNI CS to clear or just plough >> on as is the case today. The thinking there was that it's better to >> have a longish remark pause because of not emptying Eden than to >> delay the >> CMS collection and risk a concurrent mode failure which would be much >> more expensive. >> >> As you alluded to in your email, the issue is a bit tricky because of >> the way scavenge before remark is currently implemented ... CMS >> decides to >> do a remark, stops all the mutators, then decides that it must do a >> scavenge, which now cannot be done because the gc-locker is held, so >> we bail from >> the scavenge and just do the remark pause (this is safe because no >> objects are moved). The whole set-up of CMS' vm-ops was predicated on the >> assumption of non-interference with other operations because these >> are in some sense "read-only" wrt the heap, so we can safely >> schedule the safepoint at any time without any worries about moving >> objects. >> >> Scavenge-before-remark is the only wrinkle in this otherwise flat and >> smooth landscape. >> >> I suspect the correct way to deal with this one and for all in a >> uniform manner might be to have vm ops that need a vacant gc-locker to >> be enqueued on a separate vm-ops queue whose operations are executed >> as soon as the gc-locker has been vacated (this would likely >> be all the vm-ops other than perhaps a handful of CMS vm-ops today). >> But this would be a fairly intrusive and delicate rewrite of the >> vm-op and gc-locker subsystems. >> >> A quicker point-solution might be to split the scavenge-and-remark >> vm-op into two separate vm ops -- one that does a (guaranteed) scavenge, >> followed by another that does a remark -- each in a separate >> safepoint, i.e. two separate vm-ops. One way to do this might be for >> the CMS >> thread to take the jni critical lock, set needs_gc() if the gc locker >> is active, and then wait on the jni critical lock for it to be >> cleared (which it >> will be by the last thread exiting a JNI CS) which would initiate the >> scavenge. If the gc locker isn't active, the scavenge can be >> initiated straightaway >> by the CMS thread in the same way that a JNI thread would have >> initiated it when it was the last one exiting a JNI CS.. Once the >> scavenge has >> happened, the CMS thread can then do the remark in the normal way. >> Some allocation would have happened in Eden between the scavenge and >> the remark to follow, but hopefully that would be sufficiently small >> as not to affect the performance of the remark. The delicate part >> here is the >> synchronization between gc locker state, the cms thread initiating >> the vm-op for scavenge/remark and the jni threads, but this protocol >> would >> be identical to the existing one, except that the CMS thread would >> now be a participant in that proctocol, which it never was before >> (this might >> call for some scaffolding in the CMS thread so it can participate). >> >> All this having been said, I am slightly surprised that remark pauses >> for large Edens are so poor. I would normally expect that pointers >> from young >> to old would be quite few and with the Eden being scanned >> multi-threaded (at sampled "top" boundaries -- perhaps this should >> use TLAB >> boundaries instead), we would be able to scale OK to larger Edens. >> Have you looked at the distribution of Eden scanning times during the >> remark pause? Does Eden scanning dominate the remark cost? (I was >> also wondering if it might be possible to avoid using whatever was >> causing such frequent gc-locker activity as a temporary workaround >> until the issue w/CMS is fixed?) >> >> -- ramki >> >> >> >> On Tue, Sep 2, 2014 at 3:21 PM, Tony Printezis >> > wrote: >> >> Hi there, >> >> In addition to the GCLocker issue I've already mentioned >> (JDK-8048556: unnecessary young GCs due to the GCLocker) we're >> also hitting a second one, which in some ways is more severe in >> some cases. >> >> We use quite large edens and we run with >> -XX:+CMSScavengeBeforeRemark to empty the eden before each remark >> to keep remark times reasonable. It turns out that when the >> remark pause is scheduled it doesn't try to synchronize with the >> GCLocker at all. The result is that, quite often, the scavenge >> before remark aborts because the GCLocker is active. This leads >> to substantially longer remarks. >> >> A side-effect of this is that the remark pause with the aborted >> scavenge is immediately followed by a GCLocker-initiated GC (with >> the eden being half empty). The aborted scavenge checks whether >> the GCLocker is active with check_active_before_gc() which tells >> the GCLocker to do a young GC if it's active. And the young GC is >> done without waiting for the eden to fill up. >> >> The issue is very easy to reproduce with a test similar to what I >> posted on JDK-8048556 (force concurrent cycles by adding a thread >> that calls System.gc() every say 10 secs and set >> -XX:+ExplicitGCInvokesConcurrent). I can reproduce this with the >> current hotspot-gc repo. >> >> We were wondering whether this is a known issue and whether >> someone is working on it. FWIW, the fix could be a bit tricky. >> >> Thanks, >> >> Tony >> >> -- >> Tony Printezis | JVM/GC Engineer / VM Team | Twitter >> >> @TonyPrintezis >> tprintezis at twitter.com >> >> > > -- > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > tprintezis at twitter.com -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Coomes at oracle.com Thu Sep 4 16:17:28 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 09:17:28 -0700 Subject: review request (S): 8057531: refactor gc arg processing code slightly In-Reply-To: <1655880.sGAVeYYZO1@mgerdin-lap> References: <21512.12593.819887.681376@mykonos.us.oracle.com> <1655880.sGAVeYYZO1@mgerdin-lap> Message-ID: <21512.37016.514843.503995@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > Hi John, > > On Thursday 04 September 2014 02.30.25 John Coomes wrote: > > Please review this small refactoring of gc argument processing code: > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ > > I'm by no means an expert on the argument processing code but this ?ooks like > a good cleanup. Thanks for looking at it! > I noticed that the conditions for ending up in > 1537 if (should_auto_select_low_pause_collector()) { > > from > 1541 if (!UseSerialGC && > 1542 !UseConcMarkSweepGC && > 1543 !UseG1GC && > 1544 !UseParNewGC && > 1545 FLAG_IS_DEFAULT(UseParallelGC)) { > > to > 611 return UseConcMarkSweepGC || UseG1GC || UseParallelGC || > UseParallelOldGC || > 612 UseParNewGC || UseSerialGC; > 613 } > > I think that's a good change. Yes, there was a missing case before. It rarely (never?) mattered since should_auto_select_low_pause_collector() is off by default. -John > Before your change it seems like setting -XX:+UseParallelOldGC could still end > up in should_auto_select_low_pause_collector since set_parallel_gc_flags() was > called after set_ergonomics_flags() and the condition only looked at > UseParallelGC. > > The change overall looks ok to me, but I'm not a 8u Reviewer. > > Thanks for any feedback. > > > > -John > From John.Coomes at oracle.com Thu Sep 4 16:17:55 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 09:17:55 -0700 Subject: review request (S): 8057531: refactor gc arg processing code slightly In-Reply-To: <1409825256.2707.9.camel@cirrus> References: <21512.12593.819887.681376@mykonos.us.oracle.com> <1409825256.2707.9.camel@cirrus> Message-ID: <21512.37043.590535.834807@mykonos.us.oracle.com> Thomas Schatzl (thomas.schatzl at oracle.com) wrote: > Hi, > > On Thu, 2014-09-04 at 02:30 -0700, John Coomes wrote: > > Please review this small refactoring of gc argument processing code: > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ > > > > Thanks for any feedback. > > Looks good. I am not a jdk8u Reviewer though. Thanks for taking a look! -John From John.Coomes at oracle.com Thu Sep 4 16:29:44 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 09:29:44 -0700 Subject: review request (XS): 8054970: gc src file exclusion & alt sources In-Reply-To: <5408766E.9040102@oracle.com> References: <21511.7473.12538.953609@mykonos.us.oracle.com> <5408766E.9040102@oracle.com> Message-ID: <21512.37752.250746.586421@mykonos.us.oracle.com> Erik Helin (erik.helin at oracle.com) wrote: > Hi John, > > the change looks good. I'm not a Reviewer in jdk8u/hsx, just committer. Thanks! -John > On 2014-09-03 15:52, John.Coomes at oracle.com wrote: > > X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-redhat-linux-gnu) > > Reply-To: John Coomes > > From: John Coomes > > Organization: Oracle Corp. > > X-Attribution: jwc > > > > I'd appreciate reviews of this small change to extend gc source file > > exclusion to alternate sources. > > > > 8054970: gc src file exclusion should exclude alternative sources > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8054970-gc-exclude-alt/ > > > > Thanks for any feedback. > > > > -John > > From John.Coomes at oracle.com Thu Sep 4 16:30:33 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 09:30:33 -0700 Subject: review request (XS): 8054970: gc src file exclusion & alt sources In-Reply-To: <54087C6F.90101@oracle.com> References: <21511.7473.12538.953609@mykonos.us.oracle.com> <54087C6F.90101@oracle.com> Message-ID: <21512.37801.175104.307019@mykonos.us.oracle.com> Stefan Karlsson (stefan.karlsson at oracle.com) wrote: > On 2014-09-03 15:52, John.Coomes at oracle.com wrote: > > > > I'd appreciate reviews of this small change to extend gc source file > > exclusion to alternate sources. > > > > 8054970: gc src file exclusion should exclude alternative sources > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8054970-gc-exclude-alt/ > > Looks good. Hi Stefan, Many thanks! -John From stefan.johansson at oracle.com Thu Sep 4 19:01:11 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 04 Sep 2014 21:01:11 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <1657077.8dc3rYaaKs@mgerdin03> References: <54085EEA.8060303@oracle.com> <1657077.8dc3rYaaKs@mgerdin03> Message-ID: <5408B6F7.5030702@oracle.com> Hi Mikael, On 2014-09-04 17:04, Mikael Gerdin wrote: > Hi Stefan, > > On Thursday 04 September 2014 14.45.30 Stefan Johansson wrote: >> Hi, >> >> Please review these changes for: >> https://bugs.openjdk.java.net/browse/JDK-8057536 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ > g1Allocator.hpp: > > reuse_retaind_... => reuse_retained_... > > G1ParGCAllocator::allocate does not have the SurvivorAlignmentInBytes change > when it was broken out from G1ParScanThreadState. Fixed. > g1Allocator.cpp: > > reuse_retaind_... => reuse_retained_... > two spaces after return type of retire_alloc_buffers > align parameters to flush_stats_and_retire Fixed. > g1CollectedHeap.hpp: > > align the parameters to "attempt_allocation_at_safepoint", > "survivor_attempt_allocation", "old_attempt_allocation" Fixed. > g1CollectedHeap.cpp: > > You didn't move the methods of Mutator/SurvivorGC/OldGC alloc region to > g1Allocator.cpp Realized that those were missed when moving stuff before, and Bengt pointed out that they probably should move to G1AllocRegion.hpp as well, so that has been done. > align the parameters at the call to "attempt_allocation" > align the parameters to "attempt_allocation_at_safepoint" Fixed. > g1CollectedHeap.inline.hpp: > > align the parameters at the call to "attempt_allocation" > > align the parameters to "survivor_attempt_allocation", > "old_attempt_allocation" Fixed. > heapRegion.cpp: > > HeapRegion::print_on is designed to produce short output. Can you shorten the > output? Either by disabling the printout if contexts aren't used or disable it > for context-0 regions. Or have a format like "C%4u". Change to "AC%4u". > For most of the style changes I'm ok with a follow-up change to address them. > The rest of the change looks ok to me. As you see I've addressed most of them, here is an updated webrev as well as a diff between the two: http://cr.openjdk.java.net/~sjohanss/8057536/webrev.01/ http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ I also had to do a small addition in vm_operations.hpp, which was forgotten in the previous webrev. Thanks for doing a through review, Stefan > I'm not a 8u Reviewer. > > /Mikael > >> Summary: >> These changes are made to allow G1 to do context specific allocation. As >> part of this a G1Allocator class has be refactored out of >> G1CollectedHeap which can be extended to implement the specific context >> code. Currently only the G1DefaultAllocator is implemented, this >> allocator only makes use of one context to have the same behavior as >> prior to this enhancement. >> >> Testing: >> * JPRT >> * Manual verification >> * Local ute runs of vm.quick.testlist >> >> Thanks, >> Stefan From stefan.johansson at oracle.com Thu Sep 4 19:01:19 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 04 Sep 2014 21:01:19 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <54088045.9020707@oracle.com> References: <54085EEA.8060303@oracle.com> <54088045.9020707@oracle.com> Message-ID: <5408B6FF.7050501@oracle.com> Hi Bengt, On 2014-09-04 17:07, Bengt Rutisson wrote: > > > Hi Stefan, > > On 2014-09-04 14:45, Stefan Johansson wrote: >> Hi, >> >> Please review these changes for: >> https://bugs.openjdk.java.net/browse/JDK-8057536 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ > > Overall I think this i a nice refactoring. Some comments below. Mostly > style and code comments. > Thanks for the in depth review, here's the new webrev and a diff against the first: http://cr.openjdk.java.net/~sjohanss/8035057/webrev.01/ http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ I also had to do a small addition in vm_operations.hpp, which was forgotten in the previous webrev. Cheers, Stefan > Thanks, > Bengt > > > G1Allocator.java > > //size_t _summary_bytes_used; > Should probably not be there. > Actually this seems to be the way to show what type this field corresponds to in the VM, see G1CollectedHeap.java for other examples. > > G1CollectedHeap.java > > public long used() { > Address g1AllocatorAddr = g1Allocator.getValue(addr); > G1Allocator allocator = (G1Allocator) > VMObjectFactory.newObject(G1Allocator.class, g1AllocatorAddr); > return allocator.getSummaryBytes(); > } > > Maybe introduce a allocator() method similar to the hrm() and g1mm() > methods? > Fixed. > > g1Allocator.hpp > > In this file we are mixing non-indented private, protected, public > declarations with one-space-indented ones. Would be good to keep the > same style in the file. Change all to no space since that was most common already. > > Would it be possible to move MutatorAllocRegion, SurvivorGCAllocRegion > and OldGCAllocRegion into g1AllocRegion.hpp instead? > Done. > > // Outside of GC pauses, the number of bytes used in all regions other > // than the current allocation region. > size_t _summary_bytes_used; > > I don't think _summary_bytes_used needs to be aligned with the > previous instance variable since the comment kind of breaks up the > alignment anyway. > Fixed. > > > if (hr != NULL) > result += hr->used(); > > Please add {}. > > Fixed. > > class G1ParGCAllocBuffer: public ParGCAllocBuffer { > private: > bool _retired; > > Alignment of single instance variable not necessary. > > Fixed. > > class G1ParGCAllocator : public CHeapObj { > friend class G1ParScanThreadState; > protected: > G1CollectedHeap* _g1h; > > size_t _alloc_buffer_waste; > size_t _undo_waste; > > void add_to_alloc_buffer_waste(size_t waste) { _alloc_buffer_waste > += waste; } > void add_to_undo_waste(size_t waste) { _undo_waste += > waste; } > > Alignment... > > Hope you like the new better. > > g1AllocationContext.hpp > > #ifndef SHARE_VM_GC_IMPLEMENTATION_G1_G1ALLOCATIONCONTEXT_HPP > > Should not be called ...EXT_HPP. > But it is, CONTEXT_HPP =) Leaving it as is, for now. > > typedef unsigned char AllocationContext_t; > > Don't think we normally call types _t. > > Not sure why we/I did this, will open a bug about changing that later, and maybe do some more refactoring around it. > > g1AllocRegion.cpp > > G1AllocRegion::uupdate_alloc_region(). Second call to trace() should > probably be trace("updated"). > Fixed. > G1AllocRegion::G1AllocRegion(). I would prefer if there was a special > value in AllocationContext that could be used as a default value > rather than using 0 explicitly in the initialization list here. > _allocation_context(0). > I like this, but I'm not sure what's the best way. I added a system() method similar to current(), which returns the system context (could not use default). > g1CollectedHeap.hpp > > Same as above. Calls like AllocationContext_t context = 0 kind of > leaks what we are trying to hide with the AllocationContext_t type. > Would be better with an explicit default value in AllocationContext. > (Holds for this call in g1CollectedHeap.cpp too: > r->set_allocation_context(0) and in heapRegion.hpp > "AllocationContext_t context = 0" and in heapRegion.cpp: > "set_allocation_context(0)".) > > Using AllocationContext::system() for those as well. > > // Allocation attempt during GC for a survivor object / PLAB. > inline HeapWord* survivor_attempt_allocation(size_t word_size, > AllocationContext_t context); > > // Allocation attempt during GC for an old object / PLAB. > inline HeapWord* old_attempt_allocation(size_t word_size, > AllocationContext_t context); > > > Alignment. > > Fixed. > > g1CollectedHeap.cpp > > I think the newline after this comment should be left as it was: > // Methods for the GC alloc regions > > Yes, done. > > g1CollectedHeap.inline.hpp > > inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t > word_size, > AllocationContext_t context) { > > inline HeapWord* G1CollectedHeap::old_attempt_allocation(size_t > word_size, > AllocationContext_t > context) { > Alignment. > > Fixed. > > g1ParScanThreadState.cpp > > G1ParScanThreadState::~G1ParScanThreadState() > Can we introduce a G1ParGCAllocator::relese_allocator() instead of > doing "delete _g1_par_allocator"? > That would require to pass the _g1_par_allocator along to release and then do the delete in there. I can add this if you prefer but otherwise keep it as is. > heapRegion.cpp > > void HeapRegion::print_on(outputStream* st) const { > st->print("Context: %4u", allocation_context()); > > Is it worth trying to hide the formatting of allocation_context? > I see your point, I shortened it to AC%4u for now since Mikael wanted a more compact output. This might be something to do if we re-design the allocation context. > >> >> Summary: >> These changes are made to allow G1 to do context specific allocation. >> As part of this a G1Allocator class has be refactored out of >> G1CollectedHeap which can be extended to implement the specific >> context code. Currently only the G1DefaultAllocator is implemented, >> this allocator only makes use of one context to have the same >> behavior as prior to this enhancement. >> >> Testing: >> * JPRT >> * Manual verification >> * Local ute runs of vm.quick.testlist >> >> Thanks, >> Stefan > From jon.masamitsu at oracle.com Thu Sep 4 22:26:12 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 04 Sep 2014 15:26:12 -0700 Subject: review request (S): 8057531: refactor gc arg processing code slightly In-Reply-To: <21512.12593.819887.681376@mykonos.us.oracle.com> References: <21512.12593.819887.681376@mykonos.us.oracle.com> Message-ID: <5408E704.4070202@oracle.com> Changes look good. If you haven't, could you run your change with -XX:+NeverActAsServerClassMachine -XX:+PrintGCDetails -version and verify that the serial-gc is selected. Reviewed. Jon On 09/04/2014 02:30 AM, John Coomes wrote: > Please review this small refactoring of gc argument processing code: > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ > > Thanks for any feedback. > > -John From John.Coomes at oracle.com Thu Sep 4 23:13:20 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 16:13:20 -0700 Subject: review request (S): 8057531: refactor gc arg processing code slightly In-Reply-To: <5408E704.4070202@oracle.com> References: <21512.12593.819887.681376@mykonos.us.oracle.com> <5408E704.4070202@oracle.com> Message-ID: <21512.61968.57929.827200@mykonos.us.oracle.com> Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > Changes look good. Thank you! > If you haven't, could you run your change with > > -XX:+NeverActAsServerClassMachine -XX:+PrintGCDetails -version > > and verify that the serial-gc is selected. I have a script that runs with all the collectors (plus no collector specified). I added NeverActAsServerClassMachine and the results were the same as an unmodified vm. -John > Reviewed. > > Jon > > > On 09/04/2014 02:30 AM, John Coomes wrote: > > Please review this small refactoring of gc argument processing code: > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057531-refactor-gc-arg-proc/ > > > > Thanks for any feedback. > > > > -John > From jesper.wilhelmsson at oracle.com Thu Sep 4 23:54:05 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 05 Sep 2014 01:54:05 +0200 Subject: RFR: 8057632 - Remove auxiliary code used to handle the generations array Message-ID: <5408FB9D.4000302@oracle.com> Hi, This is the next part of the generation array removal. I have split this change into several parts to ease the review. These webrevs build on top of each other. 1. Removing prev_gen(), next_gen(), and get_gen(int) Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/remove_get_gen/ 2. Move the genspecs from GenCollectedHeap to GenCollectorPolicy Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/move_genspecs/ 3. Remove n_gen() Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/remove_n_gen/ 4. Remove the levels concept. Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/remove_levels/ 5. Random cleanups made throughout this work Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/cleanup/ If you prefer to look at all changes at once, this is a webrev with all these changes: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev/ The bug I have filed for this work is: https://bugs.openjdk.java.net/browse/JDK-8057632 I will probably file more RFEs and push these different parts one by one. Thanks, /Jesper From John.Coomes at oracle.com Fri Sep 5 01:03:39 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 4 Sep 2014 18:03:39 -0700 Subject: review request (S): 8057623: extension class for argument handling Message-ID: <21513.3051.666777.695836@mykonos.us.oracle.com> Hi, Please review this change to add an extension class for argument handling: http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ It's intended to allow easier customization of consistency checks and ergonomic gc selection. -John From mikael.gerdin at oracle.com Fri Sep 5 07:15:38 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 05 Sep 2014 09:15:38 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <5408B6F7.5030702@oracle.com> References: <54085EEA.8060303@oracle.com> <1657077.8dc3rYaaKs@mgerdin03> <5408B6F7.5030702@oracle.com> Message-ID: <2798595.Lnfec9Pa2Z@mgerdin03> Hi Stefan, On Thursday 04 September 2014 21.01.11 Stefan Johansson wrote: > Hi Mikael, > > On 2014-09-04 17:04, Mikael Gerdin wrote: > > Hi Stefan, > > > > On Thursday 04 September 2014 14.45.30 Stefan Johansson wrote: > >> Hi, > >> > >> Please review these changes for: > >> https://bugs.openjdk.java.net/browse/JDK-8057536 > >> > >> Webrev: > >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ > > > > g1Allocator.hpp: > > > > reuse_retaind_... => reuse_retained_... > > > > G1ParGCAllocator::allocate does not have the SurvivorAlignmentInBytes > > change when it was broken out from G1ParScanThreadState. > > Fixed. > > > g1Allocator.cpp: > > > > reuse_retaind_... => reuse_retained_... > > two spaces after return type of retire_alloc_buffers > > align parameters to flush_stats_and_retire > > Fixed. > > > g1CollectedHeap.hpp: > > > > align the parameters to "attempt_allocation_at_safepoint", > > "survivor_attempt_allocation", "old_attempt_allocation" > > Fixed. > > > g1CollectedHeap.cpp: > > > > You didn't move the methods of Mutator/SurvivorGC/OldGC alloc region to > > g1Allocator.cpp > > Realized that those were missed when moving stuff before, and Bengt > pointed out that they probably should move to G1AllocRegion.hpp as well, > so that has been done. > > > align the parameters at the call to "attempt_allocation" > > align the parameters to "attempt_allocation_at_safepoint" > > Fixed. > > > g1CollectedHeap.inline.hpp: > > > > align the parameters at the call to "attempt_allocation" > > > > align the parameters to "survivor_attempt_allocation", > > "old_attempt_allocation" > > Fixed. > > > heapRegion.cpp: > > > > HeapRegion::print_on is designed to produce short output. Can you shorten > > the output? Either by disabling the printout if contexts aren't used or > > disable it for context-0 regions. Or have a format like "C%4u". > > Change to "AC%4u". > > > For most of the style changes I'm ok with a follow-up change to address > > them. The rest of the change looks ok to me. > > As you see I've addressed most of them, here is an updated webrev as > well as a diff between the two: > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.01/ > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ Looks good. /Mikael > > I also had to do a small addition in vm_operations.hpp, which was > forgotten in the previous webrev. > > Thanks for doing a through review, > Stefan > > > I'm not a 8u Reviewer. > > > > /Mikael > > > >> Summary: > >> These changes are made to allow G1 to do context specific allocation. As > >> part of this a G1Allocator class has be refactored out of > >> G1CollectedHeap which can be extended to implement the specific context > >> code. Currently only the G1DefaultAllocator is implemented, this > >> allocator only makes use of one context to have the same behavior as > >> prior to this enhancement. > >> > >> Testing: > >> * JPRT > >> * Manual verification > >> * Local ute runs of vm.quick.testlist > >> > >> Thanks, > >> Stefan H From bengt.rutisson at oracle.com Fri Sep 5 07:39:24 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 05 Sep 2014 09:39:24 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <5408B6FF.7050501@oracle.com> References: <54085EEA.8060303@oracle.com> <54088045.9020707@oracle.com> <5408B6FF.7050501@oracle.com> Message-ID: <540968AC.6090300@oracle.com> Hi Stefan, On 2014-09-04 21:01, Stefan Johansson wrote: > Hi Bengt, > > On 2014-09-04 17:07, Bengt Rutisson wrote: >> >> >> Hi Stefan, >> >> On 2014-09-04 14:45, Stefan Johansson wrote: >>> Hi, >>> >>> Please review these changes for: >>> https://bugs.openjdk.java.net/browse/JDK-8057536 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ >> >> Overall I think this i a nice refactoring. Some comments below. >> Mostly style and code comments. >> > Thanks for the in depth review, here's the new webrev and a diff > against the first: > http://cr.openjdk.java.net/~sjohanss/8035057/webrev.01/ > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ > > I also had to do a small addition in vm_operations.hpp, which was > forgotten in the previous webrev. Thanks for fixing all this! I think it would be good to remove the default values for the parameters to these functions: 454 HeapWord* humongous_obj_allocate_initialize_regions(uint first, 455 uint num_regions, 456 size_t word_size, 457 AllocationContext_t context = AllocationContext::system()); 458 459 // Attempt to allocate a humongous object of the given size. Return 460 // NULL if unsuccessful. 461 HeapWord* humongous_obj_allocate(size_t word_size, AllocationContext_t context = AllocationContext::system()); The declarations get very long and there is only one place where the default value is actually necessary. Better to explicitly pass AllocationContext::system() there. Other than that it looks good. Thanks, Bengt > > Cheers, > Stefan > >> Thanks, >> Bengt >> >> >> G1Allocator.java >> >> //size_t _summary_bytes_used; >> Should probably not be there. >> > Actually this seems to be the way to show what type this field > corresponds to in the VM, see G1CollectedHeap.java for other examples. >> >> G1CollectedHeap.java >> >> public long used() { >> Address g1AllocatorAddr = g1Allocator.getValue(addr); >> G1Allocator allocator = (G1Allocator) >> VMObjectFactory.newObject(G1Allocator.class, g1AllocatorAddr); >> return allocator.getSummaryBytes(); >> } >> >> Maybe introduce a allocator() method similar to the hrm() and g1mm() >> methods? >> > Fixed. >> >> g1Allocator.hpp >> >> In this file we are mixing non-indented private, protected, public >> declarations with one-space-indented ones. Would be good to keep the >> same style in the file. > Change all to no space since that was most common already. >> >> Would it be possible to move MutatorAllocRegion, >> SurvivorGCAllocRegion and OldGCAllocRegion into g1AllocRegion.hpp >> instead? >> > Done. >> >> // Outside of GC pauses, the number of bytes used in all regions other >> // than the current allocation region. >> size_t _summary_bytes_used; >> >> I don't think _summary_bytes_used needs to be aligned with the >> previous instance variable since the comment kind of breaks up the >> alignment anyway. >> > Fixed. >> >> >> if (hr != NULL) >> result += hr->used(); >> >> Please add {}. >> >> > Fixed. >> >> class G1ParGCAllocBuffer: public ParGCAllocBuffer { >> private: >> bool _retired; >> >> Alignment of single instance variable not necessary. >> >> > Fixed. >> >> class G1ParGCAllocator : public CHeapObj { >> friend class G1ParScanThreadState; >> protected: >> G1CollectedHeap* _g1h; >> >> size_t _alloc_buffer_waste; >> size_t _undo_waste; >> >> void add_to_alloc_buffer_waste(size_t waste) { >> _alloc_buffer_waste += waste; } >> void add_to_undo_waste(size_t waste) { _undo_waste += >> waste; } >> >> Alignment... >> >> > Hope you like the new better. >> >> g1AllocationContext.hpp >> >> #ifndef SHARE_VM_GC_IMPLEMENTATION_G1_G1ALLOCATIONCONTEXT_HPP >> >> Should not be called ...EXT_HPP. >> > But it is, CONTEXT_HPP =) Leaving it as is, for now. >> >> typedef unsigned char AllocationContext_t; >> >> Don't think we normally call types _t. >> >> > Not sure why we/I did this, will open a bug about changing that later, > and maybe do some more refactoring around it. >> >> g1AllocRegion.cpp >> >> G1AllocRegion::uupdate_alloc_region(). Second call to trace() should >> probably be trace("updated"). >> > Fixed. >> G1AllocRegion::G1AllocRegion(). I would prefer if there was a special >> value in AllocationContext that could be used as a default value >> rather than using 0 explicitly in the initialization list here. >> _allocation_context(0). >> > I like this, but I'm not sure what's the best way. I added a system() > method similar to current(), which returns the system context (could > not use default). >> g1CollectedHeap.hpp >> >> Same as above. Calls like AllocationContext_t context = 0 kind of >> leaks what we are trying to hide with the AllocationContext_t type. >> Would be better with an explicit default value in AllocationContext. >> (Holds for this call in g1CollectedHeap.cpp too: >> r->set_allocation_context(0) and in heapRegion.hpp >> "AllocationContext_t context = 0" and in heapRegion.cpp: >> "set_allocation_context(0)".) >> >> > Using AllocationContext::system() for those as well. >> >> // Allocation attempt during GC for a survivor object / PLAB. >> inline HeapWord* survivor_attempt_allocation(size_t word_size, >> AllocationContext_t context); >> >> // Allocation attempt during GC for an old object / PLAB. >> inline HeapWord* old_attempt_allocation(size_t word_size, >> AllocationContext_t context); >> >> >> Alignment. >> >> > Fixed. >> >> g1CollectedHeap.cpp >> >> I think the newline after this comment should be left as it was: >> // Methods for the GC alloc regions >> >> > Yes, done. >> >> g1CollectedHeap.inline.hpp >> >> inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t >> word_size, >> AllocationContext_t context) { >> >> inline HeapWord* G1CollectedHeap::old_attempt_allocation(size_t >> word_size, >> AllocationContext_t >> context) { >> Alignment. >> >> > Fixed. >> >> g1ParScanThreadState.cpp >> >> G1ParScanThreadState::~G1ParScanThreadState() >> Can we introduce a G1ParGCAllocator::relese_allocator() instead of >> doing "delete _g1_par_allocator"? >> > That would require to pass the _g1_par_allocator along to release and > then do the delete in there. I can add this if you prefer but > otherwise keep it as is. >> heapRegion.cpp >> >> void HeapRegion::print_on(outputStream* st) const { >> st->print("Context: %4u", allocation_context()); >> >> Is it worth trying to hide the formatting of allocation_context? >> > I see your point, I shortened it to AC%4u for now since Mikael wanted > a more compact output. This might be something to do if we re-design > the allocation context. >> >>> >>> Summary: >>> These changes are made to allow G1 to do context specific >>> allocation. As part of this a G1Allocator class has be refactored >>> out of G1CollectedHeap which can be extended to implement the >>> specific context code. Currently only the G1DefaultAllocator is >>> implemented, this allocator only makes use of one context to have >>> the same behavior as prior to this enhancement. >>> >>> Testing: >>> * JPRT >>> * Manual verification >>> * Local ute runs of vm.quick.testlist >>> >>> Thanks, >>> Stefan >> > From stefan.johansson at oracle.com Fri Sep 5 07:57:05 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 05 Sep 2014 09:57:05 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <2798595.Lnfec9Pa2Z@mgerdin03> References: <54085EEA.8060303@oracle.com> <1657077.8dc3rYaaKs@mgerdin03> <5408B6F7.5030702@oracle.com> <2798595.Lnfec9Pa2Z@mgerdin03> Message-ID: <54096CD1.8000209@oracle.com> On 2014-09-05 09:15, Mikael Gerdin wrote: > Hi Stefan, > > > On Thursday 04 September 2014 21.01.11 Stefan Johansson wrote: >> Hi Mikael, >> >> On 2014-09-04 17:04, Mikael Gerdin wrote: >>> Hi Stefan, >>> >>> On Thursday 04 September 2014 14.45.30 Stefan Johansson wrote: >>>> Hi, >>>> >>>> Please review these changes for: >>>> https://bugs.openjdk.java.net/browse/JDK-8057536 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ >>> g1Allocator.hpp: >>> >>> reuse_retaind_... => reuse_retained_... >>> >>> G1ParGCAllocator::allocate does not have the SurvivorAlignmentInBytes >>> change when it was broken out from G1ParScanThreadState. >> Fixed. >> >>> g1Allocator.cpp: >>> >>> reuse_retaind_... => reuse_retained_... >>> two spaces after return type of retire_alloc_buffers >>> align parameters to flush_stats_and_retire >> Fixed. >> >>> g1CollectedHeap.hpp: >>> >>> align the parameters to "attempt_allocation_at_safepoint", >>> "survivor_attempt_allocation", "old_attempt_allocation" >> Fixed. >> >>> g1CollectedHeap.cpp: >>> >>> You didn't move the methods of Mutator/SurvivorGC/OldGC alloc region to >>> g1Allocator.cpp >> Realized that those were missed when moving stuff before, and Bengt >> pointed out that they probably should move to G1AllocRegion.hpp as well, >> so that has been done. >> >>> align the parameters at the call to "attempt_allocation" >>> align the parameters to "attempt_allocation_at_safepoint" >> Fixed. >> >>> g1CollectedHeap.inline.hpp: >>> >>> align the parameters at the call to "attempt_allocation" >>> >>> align the parameters to "survivor_attempt_allocation", >>> "old_attempt_allocation" >> Fixed. >> >>> heapRegion.cpp: >>> >>> HeapRegion::print_on is designed to produce short output. Can you shorten >>> the output? Either by disabling the printout if contexts aren't used or >>> disable it for context-0 regions. Or have a format like "C%4u". >> Change to "AC%4u". >> >>> For most of the style changes I'm ok with a follow-up change to address >>> them. The rest of the change looks ok to me. >> As you see I've addressed most of them, here is an updated webrev as >> well as a diff between the two: >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.01/ >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ > Looks good. > /Mikael Many big thanks for the review Mikael! Stefan >> I also had to do a small addition in vm_operations.hpp, which was >> forgotten in the previous webrev. >> >> Thanks for doing a through review, >> Stefan >> >>> I'm not a 8u Reviewer. >>> >>> /Mikael >>> >>>> Summary: >>>> These changes are made to allow G1 to do context specific allocation. As >>>> part of this a G1Allocator class has be refactored out of >>>> G1CollectedHeap which can be extended to implement the specific context >>>> code. Currently only the G1DefaultAllocator is implemented, this >>>> allocator only makes use of one context to have the same behavior as >>>> prior to this enhancement. >>>> >>>> Testing: >>>> * JPRT >>>> * Manual verification >>>> * Local ute runs of vm.quick.testlist >>>> >>>> Thanks, >>>> Stefan > H From stefan.johansson at oracle.com Fri Sep 5 08:02:28 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 05 Sep 2014 10:02:28 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <540968AC.6090300@oracle.com> References: <54085EEA.8060303@oracle.com> <54088045.9020707@oracle.com> <5408B6FF.7050501@oracle.com> <540968AC.6090300@oracle.com> Message-ID: <54096E14.4020205@oracle.com> On 2014-09-05 09:39, Bengt Rutisson wrote: > > Hi Stefan, > > On 2014-09-04 21:01, Stefan Johansson wrote: >> Hi Bengt, >> >> On 2014-09-04 17:07, Bengt Rutisson wrote: >>> >>> >>> Hi Stefan, >>> >>> On 2014-09-04 14:45, Stefan Johansson wrote: >>>> Hi, >>>> >>>> Please review these changes for: >>>> https://bugs.openjdk.java.net/browse/JDK-8057536 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ >>> >>> Overall I think this i a nice refactoring. Some comments below. >>> Mostly style and code comments. >>> >> Thanks for the in depth review, here's the new webrev and a diff >> against the first: >> http://cr.openjdk.java.net/~sjohanss/8035057/webrev.01/ >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ >> >> I also had to do a small addition in vm_operations.hpp, which was >> forgotten in the previous webrev. > > Thanks for fixing all this! > > I think it would be good to remove the default values for the > parameters to these functions: > > > 454 HeapWord* humongous_obj_allocate_initialize_regions(uint first, > 455 uint > num_regions, > 456 size_t > word_size, > 457 AllocationContext_t context = AllocationContext::system()); > 458 > 459 // Attempt to allocate a humongous object of the given size. > Return > 460 // NULL if unsuccessful. > 461 HeapWord* humongous_obj_allocate(size_t word_size, > AllocationContext_t context = AllocationContext::system()); > > The declarations get very long and there is only one place where the > default value is actually necessary. Better to explicitly pass > AllocationContext::system() there. > Agree, here's the diff for just those changes: http://cr.openjdk.java.net/~sjohanss/8057536/webrev.01-fixes/ Thanks for the review! Stefan > Other than that it looks good. > > Thanks, > Bengt > >> >> Cheers, >> Stefan >> >>> Thanks, >>> Bengt >>> >>> >>> G1Allocator.java >>> >>> //size_t _summary_bytes_used; >>> Should probably not be there. >>> >> Actually this seems to be the way to show what type this field >> corresponds to in the VM, see G1CollectedHeap.java for other examples. >>> >>> G1CollectedHeap.java >>> >>> public long used() { >>> Address g1AllocatorAddr = g1Allocator.getValue(addr); >>> G1Allocator allocator = (G1Allocator) >>> VMObjectFactory.newObject(G1Allocator.class, g1AllocatorAddr); >>> return allocator.getSummaryBytes(); >>> } >>> >>> Maybe introduce a allocator() method similar to the hrm() and g1mm() >>> methods? >>> >> Fixed. >>> >>> g1Allocator.hpp >>> >>> In this file we are mixing non-indented private, protected, public >>> declarations with one-space-indented ones. Would be good to keep the >>> same style in the file. >> Change all to no space since that was most common already. >>> >>> Would it be possible to move MutatorAllocRegion, >>> SurvivorGCAllocRegion and OldGCAllocRegion into g1AllocRegion.hpp >>> instead? >>> >> Done. >>> >>> // Outside of GC pauses, the number of bytes used in all regions >>> other >>> // than the current allocation region. >>> size_t _summary_bytes_used; >>> >>> I don't think _summary_bytes_used needs to be aligned with the >>> previous instance variable since the comment kind of breaks up the >>> alignment anyway. >>> >> Fixed. >>> >>> >>> if (hr != NULL) >>> result += hr->used(); >>> >>> Please add {}. >>> >>> >> Fixed. >>> >>> class G1ParGCAllocBuffer: public ParGCAllocBuffer { >>> private: >>> bool _retired; >>> >>> Alignment of single instance variable not necessary. >>> >>> >> Fixed. >>> >>> class G1ParGCAllocator : public CHeapObj { >>> friend class G1ParScanThreadState; >>> protected: >>> G1CollectedHeap* _g1h; >>> >>> size_t _alloc_buffer_waste; >>> size_t _undo_waste; >>> >>> void add_to_alloc_buffer_waste(size_t waste) { >>> _alloc_buffer_waste += waste; } >>> void add_to_undo_waste(size_t waste) { _undo_waste += >>> waste; } >>> >>> Alignment... >>> >>> >> Hope you like the new better. >>> >>> g1AllocationContext.hpp >>> >>> #ifndef SHARE_VM_GC_IMPLEMENTATION_G1_G1ALLOCATIONCONTEXT_HPP >>> >>> Should not be called ...EXT_HPP. >>> >> But it is, CONTEXT_HPP =) Leaving it as is, for now. >>> >>> typedef unsigned char AllocationContext_t; >>> >>> Don't think we normally call types _t. >>> >>> >> Not sure why we/I did this, will open a bug about changing that >> later, and maybe do some more refactoring around it. >>> >>> g1AllocRegion.cpp >>> >>> G1AllocRegion::uupdate_alloc_region(). Second call to trace() should >>> probably be trace("updated"). >>> >> Fixed. >>> G1AllocRegion::G1AllocRegion(). I would prefer if there was a >>> special value in AllocationContext that could be used as a default >>> value rather than using 0 explicitly in the initialization list >>> here. _allocation_context(0). >>> >> I like this, but I'm not sure what's the best way. I added a system() >> method similar to current(), which returns the system context (could >> not use default). >>> g1CollectedHeap.hpp >>> >>> Same as above. Calls like AllocationContext_t context = 0 kind of >>> leaks what we are trying to hide with the AllocationContext_t type. >>> Would be better with an explicit default value in AllocationContext. >>> (Holds for this call in g1CollectedHeap.cpp too: >>> r->set_allocation_context(0) and in heapRegion.hpp >>> "AllocationContext_t context = 0" and in heapRegion.cpp: >>> "set_allocation_context(0)".) >>> >>> >> Using AllocationContext::system() for those as well. >>> >>> // Allocation attempt during GC for a survivor object / PLAB. >>> inline HeapWord* survivor_attempt_allocation(size_t word_size, >>> AllocationContext_t context); >>> >>> // Allocation attempt during GC for an old object / PLAB. >>> inline HeapWord* old_attempt_allocation(size_t word_size, >>> AllocationContext_t context); >>> >>> >>> Alignment. >>> >>> >> Fixed. >>> >>> g1CollectedHeap.cpp >>> >>> I think the newline after this comment should be left as it was: >>> // Methods for the GC alloc regions >>> >>> >> Yes, done. >>> >>> g1CollectedHeap.inline.hpp >>> >>> inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t >>> word_size, >>> AllocationContext_t context) { >>> >>> inline HeapWord* G1CollectedHeap::old_attempt_allocation(size_t >>> word_size, >>> AllocationContext_t context) { >>> Alignment. >>> >>> >> Fixed. >>> >>> g1ParScanThreadState.cpp >>> >>> G1ParScanThreadState::~G1ParScanThreadState() >>> Can we introduce a G1ParGCAllocator::relese_allocator() instead of >>> doing "delete _g1_par_allocator"? >>> >> That would require to pass the _g1_par_allocator along to release and >> then do the delete in there. I can add this if you prefer but >> otherwise keep it as is. >>> heapRegion.cpp >>> >>> void HeapRegion::print_on(outputStream* st) const { >>> st->print("Context: %4u", allocation_context()); >>> >>> Is it worth trying to hide the formatting of allocation_context? >>> >> I see your point, I shortened it to AC%4u for now since Mikael wanted >> a more compact output. This might be something to do if we re-design >> the allocation context. >>> >>>> >>>> Summary: >>>> These changes are made to allow G1 to do context specific >>>> allocation. As part of this a G1Allocator class has be refactored >>>> out of G1CollectedHeap which can be extended to implement the >>>> specific context code. Currently only the G1DefaultAllocator is >>>> implemented, this allocator only makes use of one context to have >>>> the same behavior as prior to this enhancement. >>>> >>>> Testing: >>>> * JPRT >>>> * Manual verification >>>> * Local ute runs of vm.quick.testlist >>>> >>>> Thanks, >>>> Stefan >>> >> > From bengt.rutisson at oracle.com Fri Sep 5 07:59:40 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 05 Sep 2014 09:59:40 +0200 Subject: review request (S): 8057623: extension class for argument handling In-Reply-To: <21513.3051.666777.695836@mykonos.us.oracle.com> References: <21513.3051.666777.695836@mykonos.us.oracle.com> Message-ID: <54096D6C.7000807@oracle.com> Hi John, On 2014-09-05 03:03, John Coomes wrote: > Hi, > > Please review this change to add an extension class for argument > handling: > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ > > It's intended to allow easier customization of consistency checks and > ergonomic gc selection. Looks good. Bengt > > -John From bengt.rutisson at oracle.com Fri Sep 5 08:01:25 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 05 Sep 2014 10:01:25 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <54096E14.4020205@oracle.com> References: <54085EEA.8060303@oracle.com> <54088045.9020707@oracle.com> <5408B6FF.7050501@oracle.com> <540968AC.6090300@oracle.com> <54096E14.4020205@oracle.com> Message-ID: <54096DD5.3000405@oracle.com> On 2014-09-05 10:02, Stefan Johansson wrote: > On 2014-09-05 09:39, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> On 2014-09-04 21:01, Stefan Johansson wrote: >>> Hi Bengt, >>> >>> On 2014-09-04 17:07, Bengt Rutisson wrote: >>>> >>>> >>>> Hi Stefan, >>>> >>>> On 2014-09-04 14:45, Stefan Johansson wrote: >>>>> Hi, >>>>> >>>>> Please review these changes for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8057536 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ >>>> >>>> Overall I think this i a nice refactoring. Some comments below. >>>> Mostly style and code comments. >>>> >>> Thanks for the in depth review, here's the new webrev and a diff >>> against the first: >>> http://cr.openjdk.java.net/~sjohanss/8035057/webrev.01/ >>> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ >>> >>> I also had to do a small addition in vm_operations.hpp, which was >>> forgotten in the previous webrev. >> >> Thanks for fixing all this! >> >> I think it would be good to remove the default values for the >> parameters to these functions: >> >> >> 454 HeapWord* humongous_obj_allocate_initialize_regions(uint first, >> 455 uint >> num_regions, >> 456 size_t word_size, >> 457 AllocationContext_t context = AllocationContext::system()); >> 458 >> 459 // Attempt to allocate a humongous object of the given size. >> Return >> 460 // NULL if unsuccessful. >> 461 HeapWord* humongous_obj_allocate(size_t word_size, >> AllocationContext_t context = AllocationContext::system()); >> >> The declarations get very long and there is only one place where the >> default value is actually necessary. Better to explicitly pass >> AllocationContext::system() there. >> > Agree, here's the diff for just those changes: > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.01-fixes/ Looks good. Bengt > > Thanks for the review! > Stefan >> Other than that it looks good. >> >> Thanks, >> Bengt >> >>> >>> Cheers, >>> Stefan >>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> G1Allocator.java >>>> >>>> //size_t _summary_bytes_used; >>>> Should probably not be there. >>>> >>> Actually this seems to be the way to show what type this field >>> corresponds to in the VM, see G1CollectedHeap.java for other examples. >>>> >>>> G1CollectedHeap.java >>>> >>>> public long used() { >>>> Address g1AllocatorAddr = g1Allocator.getValue(addr); >>>> G1Allocator allocator = (G1Allocator) >>>> VMObjectFactory.newObject(G1Allocator.class, g1AllocatorAddr); >>>> return allocator.getSummaryBytes(); >>>> } >>>> >>>> Maybe introduce a allocator() method similar to the hrm() and >>>> g1mm() methods? >>>> >>> Fixed. >>>> >>>> g1Allocator.hpp >>>> >>>> In this file we are mixing non-indented private, protected, public >>>> declarations with one-space-indented ones. Would be good to keep >>>> the same style in the file. >>> Change all to no space since that was most common already. >>>> >>>> Would it be possible to move MutatorAllocRegion, >>>> SurvivorGCAllocRegion and OldGCAllocRegion into g1AllocRegion.hpp >>>> instead? >>>> >>> Done. >>>> >>>> // Outside of GC pauses, the number of bytes used in all regions >>>> other >>>> // than the current allocation region. >>>> size_t _summary_bytes_used; >>>> >>>> I don't think _summary_bytes_used needs to be aligned with the >>>> previous instance variable since the comment kind of breaks up the >>>> alignment anyway. >>>> >>> Fixed. >>>> >>>> >>>> if (hr != NULL) >>>> result += hr->used(); >>>> >>>> Please add {}. >>>> >>>> >>> Fixed. >>>> >>>> class G1ParGCAllocBuffer: public ParGCAllocBuffer { >>>> private: >>>> bool _retired; >>>> >>>> Alignment of single instance variable not necessary. >>>> >>>> >>> Fixed. >>>> >>>> class G1ParGCAllocator : public CHeapObj { >>>> friend class G1ParScanThreadState; >>>> protected: >>>> G1CollectedHeap* _g1h; >>>> >>>> size_t _alloc_buffer_waste; >>>> size_t _undo_waste; >>>> >>>> void add_to_alloc_buffer_waste(size_t waste) { >>>> _alloc_buffer_waste += waste; } >>>> void add_to_undo_waste(size_t waste) { _undo_waste += >>>> waste; } >>>> >>>> Alignment... >>>> >>>> >>> Hope you like the new better. >>>> >>>> g1AllocationContext.hpp >>>> >>>> #ifndef SHARE_VM_GC_IMPLEMENTATION_G1_G1ALLOCATIONCONTEXT_HPP >>>> >>>> Should not be called ...EXT_HPP. >>>> >>> But it is, CONTEXT_HPP =) Leaving it as is, for now. >>>> >>>> typedef unsigned char AllocationContext_t; >>>> >>>> Don't think we normally call types _t. >>>> >>>> >>> Not sure why we/I did this, will open a bug about changing that >>> later, and maybe do some more refactoring around it. >>>> >>>> g1AllocRegion.cpp >>>> >>>> G1AllocRegion::uupdate_alloc_region(). Second call to trace() >>>> should probably be trace("updated"). >>>> >>> Fixed. >>>> G1AllocRegion::G1AllocRegion(). I would prefer if there was a >>>> special value in AllocationContext that could be used as a default >>>> value rather than using 0 explicitly in the initialization list >>>> here. _allocation_context(0). >>>> >>> I like this, but I'm not sure what's the best way. I added a >>> system() method similar to current(), which returns the system >>> context (could not use default). >>>> g1CollectedHeap.hpp >>>> >>>> Same as above. Calls like AllocationContext_t context = 0 kind of >>>> leaks what we are trying to hide with the AllocationContext_t type. >>>> Would be better with an explicit default value in >>>> AllocationContext. (Holds for this call in g1CollectedHeap.cpp too: >>>> r->set_allocation_context(0) and in heapRegion.hpp >>>> "AllocationContext_t context = 0" and in heapRegion.cpp: >>>> "set_allocation_context(0)".) >>>> >>>> >>> Using AllocationContext::system() for those as well. >>>> >>>> // Allocation attempt during GC for a survivor object / PLAB. >>>> inline HeapWord* survivor_attempt_allocation(size_t word_size, >>>> AllocationContext_t context); >>>> >>>> // Allocation attempt during GC for an old object / PLAB. >>>> inline HeapWord* old_attempt_allocation(size_t word_size, >>>> AllocationContext_t context); >>>> >>>> >>>> Alignment. >>>> >>>> >>> Fixed. >>>> >>>> g1CollectedHeap.cpp >>>> >>>> I think the newline after this comment should be left as it was: >>>> // Methods for the GC alloc regions >>>> >>>> >>> Yes, done. >>>> >>>> g1CollectedHeap.inline.hpp >>>> >>>> inline HeapWord* >>>> G1CollectedHeap::survivor_attempt_allocation(size_t word_size, >>>> AllocationContext_t context) { >>>> >>>> inline HeapWord* G1CollectedHeap::old_attempt_allocation(size_t >>>> word_size, >>>> AllocationContext_t context) { >>>> Alignment. >>>> >>>> >>> Fixed. >>>> >>>> g1ParScanThreadState.cpp >>>> >>>> G1ParScanThreadState::~G1ParScanThreadState() >>>> Can we introduce a G1ParGCAllocator::relese_allocator() instead of >>>> doing "delete _g1_par_allocator"? >>>> >>> That would require to pass the _g1_par_allocator along to release >>> and then do the delete in there. I can add this if you prefer but >>> otherwise keep it as is. >>>> heapRegion.cpp >>>> >>>> void HeapRegion::print_on(outputStream* st) const { >>>> st->print("Context: %4u", allocation_context()); >>>> >>>> Is it worth trying to hide the formatting of allocation_context? >>>> >>> I see your point, I shortened it to AC%4u for now since Mikael >>> wanted a more compact output. This might be something to do if we >>> re-design the allocation context. >>>> >>>>> >>>>> Summary: >>>>> These changes are made to allow G1 to do context specific >>>>> allocation. As part of this a G1Allocator class has be refactored >>>>> out of G1CollectedHeap which can be extended to implement the >>>>> specific context code. Currently only the G1DefaultAllocator is >>>>> implemented, this allocator only makes use of one context to have >>>>> the same behavior as prior to this enhancement. >>>>> >>>>> Testing: >>>>> * JPRT >>>>> * Manual verification >>>>> * Local ute runs of vm.quick.testlist >>>>> >>>>> Thanks, >>>>> Stefan >>>> >>> >> > From thomas.schatzl at oracle.com Fri Sep 5 08:50:35 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 05 Sep 2014 10:50:35 +0200 Subject: RFR: 8057536: Refactor G1 to allow context specific allocations In-Reply-To: <5408B6FF.7050501@oracle.com> References: <54085EEA.8060303@oracle.com> <54088045.9020707@oracle.com> <5408B6FF.7050501@oracle.com> Message-ID: <1409907035.2681.16.camel@cirrus> Hi Stefan, On Thu, 2014-09-04 at 21:01 +0200, Stefan Johansson wrote: > Hi Bengt, > > On 2014-09-04 17:07, Bengt Rutisson wrote: > > > > > > Hi Stefan, > > > > On 2014-09-04 14:45, Stefan Johansson wrote: > >> Hi, > >> > >> Please review these changes for: > >> https://bugs.openjdk.java.net/browse/JDK-8057536 > >> > >> Webrev: > >> http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00/ > > > > Overall I think this i a nice refactoring. Some comments below. Mostly > > style and code comments. > > > Thanks for the in depth review, here's the new webrev and a diff against > the first: > http://cr.openjdk.java.net/~sjohanss/8035057/webrev.01/ > http://cr.openjdk.java.net/~sjohanss/8057536/webrev.00-01/ > > I also had to do a small addition in vm_operations.hpp, which was > forgotten in the previous webrev. Overall it looks good; there are some minor superfluous newlines/spaces I will list here, but they are not that important. - declaration of G1DefaultParGCAllocator::retire_alloc_buffers() has an extra space before the semicolon. - extra newline in the G1DefaultParGCAllocator::G1DefaultParGCAllocator implementation. - extra newlines at the end of g1AllocRegion.cpp ;) Some comments for future improvements; feel free to push without considering them due to the urgency: - Is it possible to document the new classes. "Base class for G1 allocators" does not explain anything to me. Same for "The default allocator for G1" does not tell anything either. - Maybe it is useful to name the region allocators (G1Allocator subtypes) slightly more differently than the PLAB allocator (G1ParGCAllocator). At least G1Allocator is really unspecific to me. Maybe G1RegionAllocator? And rename G1ParGCAllocBuffer to G1PLABAllocator. - I think G1Allocator is very specific to the current purpose: i.e. manages regions for exactly one mutator, survivor and old gc allocation region. Also G1ParGCAllocator is also rather tightly tuned to it. - given that G1ParGCAllocator and G1Allocator are rather tightly coupled, it might make sense to use that. I think it is possible to actually remove the need to pass AllocationContext_t completely for the current G1ParGCAllocator implementation. - GCAllocPurpose and PLAB statistics should go in there (from G1CollectedHeap) or at least move out of G1CollectedHeap as well imo. This is really specific to the current generational setup and to how G1ParGCAllocator work now. Thanks, Thomas From John.Coomes at oracle.com Fri Sep 5 11:06:49 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 5 Sep 2014 04:06:49 -0700 Subject: review request (S): 8057623: extension class for argument handling In-Reply-To: <54096D6C.7000807@oracle.com> References: <21513.3051.666777.695836@mykonos.us.oracle.com> <54096D6C.7000807@oracle.com> Message-ID: <21513.39241.184800.367135@mykonos.us.oracle.com> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > > Hi John, > > On 2014-09-05 03:03, John Coomes wrote: > > Hi, > > > > Please review this change to add an extension class for argument > > handling: > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ > > > > It's intended to allow easier customization of consistency checks and > > ergonomic gc selection. > > Looks good. Thanks! -John From mikael.gerdin at oracle.com Fri Sep 5 11:30:33 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 05 Sep 2014 13:30:33 +0200 Subject: review request (S): 8057623: extension class for argument handling In-Reply-To: <21513.3051.666777.695836@mykonos.us.oracle.com> References: <21513.3051.666777.695836@mykonos.us.oracle.com> Message-ID: <3490426.4srUMjLjpr@mgerdin03> Hi John, On Thursday 04 September 2014 18.03.39 John Coomes wrote: > Hi, > > Please review this change to add an extension class for argument > handling: > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ > > It's intended to allow easier customization of consistency checks and > ergonomic gc selection. Seems ok to me. /Mikael > > -John From thomas.schatzl at oracle.com Fri Sep 5 11:36:47 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 05 Sep 2014 13:36:47 +0200 Subject: review request (S): 8057623: extension class for argument handling In-Reply-To: <21513.3051.666777.695836@mykonos.us.oracle.com> References: <21513.3051.666777.695836@mykonos.us.oracle.com> Message-ID: <1409917007.2681.22.camel@cirrus> Hi, On Thu, 2014-09-04 at 18:03 -0700, John Coomes wrote: > Hi, > > Please review this change to add an extension class for argument > handling: > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ > > It's intended to allow easier customization of consistency checks and > ergonomic gc selection. > looks good except for the odd indentation of the check_gc_consistency_user() method. Should we now indent all methods by all possible? And is check_gc_consistency_ergo() performance critical so that it needs to be inlined? Thanks, Thomas From stefan.johansson at oracle.com Fri Sep 5 11:43:57 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 05 Sep 2014 13:43:57 +0200 Subject: RFR: 8057658: Enable G1 FullGC extensions Message-ID: <5409A1FD.3050304@oracle.com> Hi, Please review this change for RFE: https://bugs.openjdk.java.net/browse/JDK-8057658 Webrev: http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00/ Summary: Refactored the G1 mark sweep code to enable specialized FullGC implementations. Also prepared for doing context specific FullGC related to the work for JDK-8057536. Testing: * JPRT * Manual sanity testing Thanks, Stefan From mikael.gerdin at oracle.com Fri Sep 5 12:28:49 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 05 Sep 2014 14:28:49 +0200 Subject: RFR: 8057658: Enable G1 FullGC extensions In-Reply-To: <5409A1FD.3050304@oracle.com> References: <5409A1FD.3050304@oracle.com> Message-ID: <2314011.dSF1Z1AjhK@mgerdin03> Hi Stefan, On Friday 05 September 2014 13.43.57 Stefan Johansson wrote: > Hi, > > Please review this change for RFE: > https://bugs.openjdk.java.net/browse/JDK-8057658 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00/ space.hpp: While you're there, can you change the name of the constructor parameter from _gen to something else? The common style is to prefix member variables with an underscore so this class is in direct opposition to this. You don't need to change the names of the members of CompactPoint though. g1MarkSweep: Can you move G1PrepareCompactClosure::execute to the G1MarkSweep class? It's uncommon for other "closures" in hotspot to have static methods to invoke them like that. Something like G1MarkSweep::prepare_compaction_work(G1PrepareCompactClosure* blk) { g1h->heap_region_iterate(blk) blk->update_sets() } and have G1MarkSweep::prepare_compaction() { G1PrepareCompactClosure blk; prepare_compaction_work(&blk); } Otherwise it looks good. /Mikael > > Summary: > Refactored the G1 mark sweep code to enable specialized FullGC > implementations. Also prepared for doing context specific FullGC related > to the work for JDK-8057536. > > Testing: > * JPRT > * Manual sanity testing > > Thanks, > Stefan From bengt.rutisson at oracle.com Fri Sep 5 13:25:45 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 05 Sep 2014 15:25:45 +0200 Subject: RFR: JDK-8025564: gc/memory/UniThread/Linear1 times out during heap verification In-Reply-To: <5405BD2C.1040706@oracle.com> References: <5405BD2C.1040706@oracle.com> Message-ID: <5409B9D9.6070709@oracle.com> Hi again, StefanK looked at this and came up with two more things that can be verified. I've added those checks. Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/8025564/webrev.01/ Here's the diff compared to the previous version: http://cr.openjdk.java.net/~brutisso/8025564/webrev.00-01.diff/ Thanks, Stefan, for looking at this! Bengt On 2014-09-02 14:50, Bengt Rutisson wrote: > > Hi all, > > Can I have some reviews for this fix? > > http://cr.openjdk.java.net/~brutisso/8025564/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8025564 > > From the bug report: > > Running the gc/vector/ObjectArrayHigh test with a fastdebug build > takes 9 minutes and 21 seconds on my workstation. A little over 1 > minute is spent running the test. The rest of the time (8 minutes) is > spent vefirying the BOT. The reason the BOT verification takes such a > long time is that for each object on the heap G1 looks up the > corresponding value in the BOT and iterates forward to find the same > object again. This can get very expensive since the BOT is lazily > refined and may be in a state where you more or less have to iterate > from the start of each heap region to find the correct object. > > By replacing this expesive verification with a single pass over the > BOT that just verifies that the BOT has consistent values the > execution time is reduced significantly. With this more explicit BOT > verification the test finishes in 1 minute and 3 seconds on my > workstation. > > Note that the requirements on the BOT are very relaxed. Basically a > BOT entry can point arbitrarily far back in a HeapRegion as long as it > points to an object. From that object you can then iterate forward to > find the last object that you are interested in. This means that there > are few values that can be considered wrong in the BOT. > > Thanks, > Bengt From stefan.johansson at oracle.com Fri Sep 5 13:54:42 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 05 Sep 2014 15:54:42 +0200 Subject: RFR: 8057658: Enable G1 FullGC extensions In-Reply-To: <2314011.dSF1Z1AjhK@mgerdin03> References: <5409A1FD.3050304@oracle.com> <2314011.dSF1Z1AjhK@mgerdin03> Message-ID: <5409C0A2.8090103@oracle.com> On 2014-09-05 14:28, Mikael Gerdin wrote: > Hi Stefan, > > On Friday 05 September 2014 13.43.57 Stefan Johansson wrote: >> Hi, >> >> Please review this change for RFE: >> https://bugs.openjdk.java.net/browse/JDK-8057658 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00/ > space.hpp: > While you're there, can you change the name of the constructor parameter from > _gen to something else? The common style is to prefix member variables with an > underscore so this class is in direct opposition to this. You don't need to > change the names of the members of CompactPoint though. Change it to g, not a better name but at least not going against the style. > > g1MarkSweep: > Can you move G1PrepareCompactClosure::execute to the G1MarkSweep class? > It's uncommon for other "closures" in hotspot to have static methods to invoke > them like that. > Something like > > G1MarkSweep::prepare_compaction_work(G1PrepareCompactClosure* blk) { > g1h->heap_region_iterate(blk) > blk->update_sets() > } > > and have > G1MarkSweep::prepare_compaction() { > G1PrepareCompactClosure blk; > prepare_compaction_work(&blk); > } Fixed, see new webrev for details: http://cr.openjdk.java.net/~sjohanss/8057658/webrev.01/ http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00-01/ Thanks for reviewing, Stefan > > Otherwise it looks good. > /Mikael > >> Summary: >> Refactored the G1 mark sweep code to enable specialized FullGC >> implementations. Also prepared for doing context specific FullGC related >> to the work for JDK-8057536. >> >> Testing: >> * JPRT >> * Manual sanity testing >> >> Thanks, >> Stefan From stefan.johansson at oracle.com Fri Sep 5 16:32:05 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 05 Sep 2014 18:32:05 +0200 Subject: RFR: 8057710: Refactor G1 heap region default sizes Message-ID: <5409E585.3010501@oracle.com> Hi, Please review this small change for RFE: https://bugs.openjdk.java.net/browse/JDK-8057710 Webrev: http://cr.openjdk.java.net/~sjohanss/8057710/webrev.00/ Summary: Before this patch the min and max size for G1 heap regions were defined by defines and this patch changes this to instead use static const within a class and then have getter for the values. Testing: * Builds through JPRT * Manually verified that sizes stay the same Thanks, Stefan From John.Coomes at oracle.com Fri Sep 5 19:18:58 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 5 Sep 2014 12:18:58 -0700 Subject: review request (S): 8057623: extension class for argument handling In-Reply-To: <3490426.4srUMjLjpr@mgerdin03> References: <21513.3051.666777.695836@mykonos.us.oracle.com> <3490426.4srUMjLjpr@mgerdin03> Message-ID: <21514.3234.31425.161088@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > Hi John, > > On Thursday 04 September 2014 18.03.39 John Coomes wrote: > > Hi, > > > > Please review this change to add an extension class for argument > > handling: > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ > > > > It's intended to allow easier customization of consistency checks and > > ergonomic gc selection. > > Seems ok to me. Hi Mikael, Thanks for the review. -John From John.Coomes at oracle.com Fri Sep 5 19:33:09 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 5 Sep 2014 12:33:09 -0700 Subject: review request (S): 8057623: extension class for argument handling In-Reply-To: <1409917007.2681.22.camel@cirrus> References: <21513.3051.666777.695836@mykonos.us.oracle.com> <1409917007.2681.22.camel@cirrus> Message-ID: <21514.4085.406770.489953@mykonos.us.oracle.com> Thomas Schatzl (thomas.schatzl at oracle.com) wrote: > Hi, > > On Thu, 2014-09-04 at 18:03 -0700, John Coomes wrote: > > Hi, > > > > Please review this change to add an extension class for argument > > handling: > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057623-arguments-ext/ > > > > It's intended to allow easier customization of consistency checks and > > ergonomic gc selection. > > > > looks good except for the odd indentation of the > check_gc_consistency_user() method. > > Should we now indent all methods by all possible? And is > check_gc_consistency_ergo() performance critical so that it needs to be > inlined? Hi Thomas, Thanks for reviewing it. I just lined up the decl of check_gc_consistency_user() method with check_gc_consistency_ergo() immediately below it. But there isn't consistency :-) in the indentation, so I've changed it to just a single space. check_gc_consistency_ergo() is not performance critical, but it is so trivial inlining made sense (at least to me). -John From tprintezis at twitter.com Fri Sep 5 21:31:11 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 05 Sep 2014 17:31:11 -0400 Subject: Introduce "region type" field to G1 HeapRegions Message-ID: <540A2B9F.2000105@twitter.com> Hi all, One of the things that has always annoyed me in G1 is that working out the type of a heap region is a complete mess: - there are separate fields for "humongous type" and "young type" - to check whether a region is free we have to check is_empty() - we cannot explicitly check whether a region is old (if it's none of the other types, then it's old) If anyone wants to add new region types (as we all seem to want to do these days!!!), doing so is a bit of a pain and more error-prone than it should be. Could I ask you to consider the following patch that introduces a HeapRegionType class, which encapsulates all the region type information, and replaces the young / humongous type fields with HeapRegionType _type? http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.0/ I've again done as much testing as I could here but more would be appreciated. Let me know if this change will be of interest and I'll create a CR. Regards, Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From staffan.friberg at oracle.com Fri Sep 5 22:20:32 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 05 Sep 2014 15:20:32 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <5400FF6F.5040203@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> Message-ID: <540A3730.1060603@oracle.com> Hi, I have uploaded a new webrev here, cr.openjdk.java.net/~sfriberg/8055845/webrev.03 It contains several changes - Split event into two events (PromoteObjectInNewPLAB, PromoteObjectOutsidePLAB) - Moved events to "vm/gc/detailed/PromoteObject..." - Supporting ParNew+CMS and ParNew+SerialOld tenuring - Not sure if the way I do it with passing the ParNewTracer is the best solution, please let me know if you have an idea how to improve it - Simplified the G1 code to avoid sending age and having a single call site - Fixed so that the generated event has size information in bytes rather than words Thanks for offline comments and suggestions from Dmitry and Thomas. Cheers, Staffan On 08/29/2014 03:32 PM, Staffan Friberg wrote: > Hi Erik, > > On 08/28/2014 11:34 PM, Erik Helin wrote: >> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in >> this thread, I'm adding it back) >> >> On 2014-08-28 23:15, Staffan Friberg wrote: >>> Hi Erik, >>> >>> Thanks for the comments. >>>> - Aren't the events for promotion to the tenured generation >>>> (SerialOld) >>>> and the CMS generation missing? >>> The reason for leaving out these two, Serial completely and CMS >>> promotion, was due to that neither as far as I understand make use of >>> PLABs. >> >> I might be wrong here, but looking at the function >> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to >> me like SerialOld is using PLABs when ParNew is promoting objects >> from young to old. >> >> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in >> concurrentMarkSweepGeneration.cpp) it seems like each >> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local >> Allocation Buffer) that is a thread-local allocation buffer. See >> compactibleFreeListSpace.{hpp,cpp} for more details. >> >> Given this, I think we should add events for Serial and CMS as well. >> > > Ok I see what you mean with CMS, basically the equivalent to getting a > PLAB would be when we refill the CFLS_LAB in the alloc function. It > still does the allocation to a small memory (~ size of object) area > from the freelist, but at least we did extra work to refill the local > CFLS_LAB. Need to do some analysis to see how often we refill so the > overhead doesn't get too high. > The only issue I run into is how I can in a nice way get access to the > ParNewTracer from ParNewGeneration to call the report function. Let's > sync up next week and see how it can be solved. > > The tenured GC requires something similar to be supported, however > since ParNewGC is deprecated for usage without CMS in JDK 8 we might > want to skip that combination. > > >> >> On 2014-08-28 23:15, Staffan Friberg wrote: >>>> - Would it make sense to differentiate, either by separate events >>>> or by >>>> a field in a event, between promotions to to-space and to the old >>>> generation? >>>> - The are two events for TLAB allocations, >>>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>>> What do you think about using two events for PLAB allocations as >>>> well: >>>> - java/object_alloc_in_new_PLAB >>>> - java/object_alloc_outside_PLAB >>> I think this is a matter of taste and probably how similar we want the >>> event to be to the existing allocation event. I personally prefer a >>> single event but if the GC team and serviceability team feel it >>> would be >>> better to have two I can certainly rewrite. The reason for me >>> preferring >>> a single event is just ease of analysis, you can easily filter a >>> list of >>> events on a field, it is harder to merge two different events with >>> different fields and work with them in an straight forward fashion. >>> >>> Any general preference for having a single or multiple events? >> >> I would prefer to have two events in this case and try to follow the >> existing allocation events as much as possible (both in naming and in >> style). Keeping the tenured field (I missed it the first time I read >> the patch) is good. >> > Yes, tenured would be independent of having two events, only PLAB size > and directAllocation would be affected when having two event types. > > *Erik Gahlin*, any preference from your end? > > > >> On 2014-08-28 23:15, Staffan Friberg wrote: >>>> - In PSPromotionManager, instead of utilizing the C++ friendship with >>>> PSScavenge, should we add a getter function for the gc_tracer? >>> Created a getter function. >> >> Thanks! If you make report_promotion_sample const, then the getter >> can return a const ParallelScavengeTracer*, right? >> > Done > > //Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.friberg at oracle.com Fri Sep 5 23:31:44 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 05 Sep 2014 16:31:44 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects Message-ID: <540A47E0.2080803@oracle.com> Hi, Copying both the compiler and GC alias as the optimization involves both groups. This optimization aims to avoid generating G1 barriers for newly allocated objects where the compiler can prove that the object has not been written to earlier and there is no safepoint between the allocation and the write. The bug has some further details and microbenchmark result. The new code has fairly extensive comments about the optimization. It would be great if the GC team can help validate that the premise of the optimization is correct as well. webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8057737 I would also need a sponsor for this change if it passes review. Thanks, Staffan From bengt.rutisson at oracle.com Mon Sep 8 07:36:00 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 08 Sep 2014 09:36:00 +0200 Subject: RFR: JDK-8025564: gc/memory/UniThread/Linear1 times out during heap verification In-Reply-To: <5409B9D9.6070709@oracle.com> References: <5405BD2C.1040706@oracle.com> <5409B9D9.6070709@oracle.com> Message-ID: <540D5C60.40308@oracle.com> Hi again, Another update to the webrev. Now with an overflow check for the obj_end calculation: http://cr.openjdk.java.net/~brutisso/8025564/webrev.02/ Bengt On 2014-09-05 15:25, Bengt Rutisson wrote: > > Hi again, > > StefanK looked at this and came up with two more things that can be > verified. I've added those checks. > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8025564/webrev.01/ > > Here's the diff compared to the previous version: > http://cr.openjdk.java.net/~brutisso/8025564/webrev.00-01.diff/ > > Thanks, Stefan, for looking at this! > Bengt > > On 2014-09-02 14:50, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have some reviews for this fix? >> >> http://cr.openjdk.java.net/~brutisso/8025564/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8025564 >> >> From the bug report: >> >> Running the gc/vector/ObjectArrayHigh test with a fastdebug build >> takes 9 minutes and 21 seconds on my workstation. A little over 1 >> minute is spent running the test. The rest of the time (8 minutes) is >> spent vefirying the BOT. The reason the BOT verification takes such a >> long time is that for each object on the heap G1 looks up the >> corresponding value in the BOT and iterates forward to find the same >> object again. This can get very expensive since the BOT is lazily >> refined and may be in a state where you more or less have to iterate >> from the start of each heap region to find the correct object. >> >> By replacing this expesive verification with a single pass over the >> BOT that just verifies that the BOT has consistent values the >> execution time is reduced significantly. With this more explicit BOT >> verification the test finishes in 1 minute and 3 seconds on my >> workstation. >> >> Note that the requirements on the BOT are very relaxed. Basically a >> BOT entry can point arbitrarily far back in a HeapRegion as long as >> it points to an object. From that object you can then iterate forward >> to find the last object that you are interested in. This means that >> there are few values that can be considered wrong in the BOT. >> >> Thanks, >> Bengt > From stefan.karlsson at oracle.com Mon Sep 8 07:50:52 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 08 Sep 2014 09:50:52 +0200 Subject: RFR: JDK-8025564: gc/memory/UniThread/Linear1 times out during heap verification In-Reply-To: <540D5C60.40308@oracle.com> References: <5405BD2C.1040706@oracle.com> <5409B9D9.6070709@oracle.com> <540D5C60.40308@oracle.com> Message-ID: <540D5FDC.4030205@oracle.com> Looks good. thanks, StefanK On 2014-09-08 09:36, Bengt Rutisson wrote: > > Hi again, > > Another update to the webrev. Now with an overflow check for the > obj_end calculation: > http://cr.openjdk.java.net/~brutisso/8025564/webrev.02/ > > Bengt > > On 2014-09-05 15:25, Bengt Rutisson wrote: >> >> Hi again, >> >> StefanK looked at this and came up with two more things that can be >> verified. I've added those checks. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8025564/webrev.01/ >> >> Here's the diff compared to the previous version: >> http://cr.openjdk.java.net/~brutisso/8025564/webrev.00-01.diff/ >> >> Thanks, Stefan, for looking at this! >> Bengt >> >> On 2014-09-02 14:50, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I have some reviews for this fix? >>> >>> http://cr.openjdk.java.net/~brutisso/8025564/webrev.00/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8025564 >>> >>> From the bug report: >>> >>> Running the gc/vector/ObjectArrayHigh test with a fastdebug build >>> takes 9 minutes and 21 seconds on my workstation. A little over 1 >>> minute is spent running the test. The rest of the time (8 minutes) >>> is spent vefirying the BOT. The reason the BOT verification takes >>> such a long time is that for each object on the heap G1 looks up the >>> corresponding value in the BOT and iterates forward to find the same >>> object again. This can get very expensive since the BOT is lazily >>> refined and may be in a state where you more or less have to iterate >>> from the start of each heap region to find the correct object. >>> >>> By replacing this expesive verification with a single pass over the >>> BOT that just verifies that the BOT has consistent values the >>> execution time is reduced significantly. With this more explicit BOT >>> verification the test finishes in 1 minute and 3 seconds on my >>> workstation. >>> >>> Note that the requirements on the BOT are very relaxed. Basically a >>> BOT entry can point arbitrarily far back in a HeapRegion as long as >>> it points to an object. From that object you can then iterate >>> forward to find the last object that you are interested in. This >>> means that there are few values that can be considered wrong in the >>> BOT. >>> >>> Thanks, >>> Bengt >> > From mikael.gerdin at oracle.com Mon Sep 8 07:51:46 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Sep 2014 09:51:46 +0200 Subject: RFR: 8057710: Refactor G1 heap region default sizes In-Reply-To: <5409E585.3010501@oracle.com> References: <5409E585.3010501@oracle.com> Message-ID: <2852079.kgcGU0PGU7@mgerdin03> Hi Stefan, On Friday 05 September 2014 18.32.05 Stefan Johansson wrote: > Hi, > > Please review this small change for RFE: > https://bugs.openjdk.java.net/browse/JDK-8057710 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8057710/webrev.00/ Looks good. /Mikael > > Summary: > Before this patch the min and max size for G1 heap regions were defined > by defines and this patch changes this to instead use static const > within a class and then have getter for the values. > > Testing: > * Builds through JPRT > * Manually verified that sizes stay the same > > Thanks, > Stefan From thomas.schatzl at oracle.com Mon Sep 8 07:56:50 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 08 Sep 2014 09:56:50 +0200 Subject: RFR: 8057710: Refactor G1 heap region default sizes In-Reply-To: <5409E585.3010501@oracle.com> References: <5409E585.3010501@oracle.com> Message-ID: <1410163010.2802.0.camel@cirrus> Hi, On Fri, 2014-09-05 at 18:32 +0200, Stefan Johansson wrote: > Hi, > > Please review this small change for RFE: > https://bugs.openjdk.java.net/browse/JDK-8057710 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8057710/webrev.00/ > > Summary: > Before this patch the min and max size for G1 heap regions were defined > by defines and this patch changes this to instead use static const > within a class and then have getter for the values. > > Testing: > * Builds through JPRT > * Manually verified that sizes stay the same looks okay. Thomas From thomas.schatzl at oracle.com Mon Sep 8 08:09:04 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 08 Sep 2014 10:09:04 +0200 Subject: RFR: JDK-8025564: gc/memory/UniThread/Linear1 times out during heap verification In-Reply-To: <540D5C60.40308@oracle.com> References: <5405BD2C.1040706@oracle.com> <5409B9D9.6070709@oracle.com> <540D5C60.40308@oracle.com> Message-ID: <1410163744.2802.2.camel@cirrus> Hi, On Mon, 2014-09-08 at 09:36 +0200, Bengt Rutisson wrote: > Hi again, > > Another update to the webrev. Now with an overflow check for the obj_end > calculation: > http://cr.openjdk.java.net/~brutisso/8025564/webrev.02/ looks okay. Thanks, Thomas From stefan.johansson at oracle.com Mon Sep 8 08:13:15 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 08 Sep 2014 10:13:15 +0200 Subject: RFR: 8057710: Refactor G1 heap region default sizes In-Reply-To: <1410163010.2802.0.camel@cirrus> References: <5409E585.3010501@oracle.com> <1410163010.2802.0.camel@cirrus> Message-ID: <540D651B.7010408@oracle.com> Thanks for reviewing Thomas. Stefan On 2014-09-08 09:56, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-05 at 18:32 +0200, Stefan Johansson wrote: >> Hi, >> >> Please review this small change for RFE: >> https://bugs.openjdk.java.net/browse/JDK-8057710 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8057710/webrev.00/ >> >> Summary: >> Before this patch the min and max size for G1 heap regions were defined >> by defines and this patch changes this to instead use static const >> within a class and then have getter for the values. >> >> Testing: >> * Builds through JPRT >> * Manually verified that sizes stay the same > looks okay. > > Thomas > > From stefan.johansson at oracle.com Mon Sep 8 08:13:35 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 08 Sep 2014 10:13:35 +0200 Subject: RFR: 8057710: Refactor G1 heap region default sizes In-Reply-To: <2852079.kgcGU0PGU7@mgerdin03> References: <5409E585.3010501@oracle.com> <2852079.kgcGU0PGU7@mgerdin03> Message-ID: <540D652F.9060306@oracle.com> Thanks Mikael for the review. Stefan On 2014-09-08 09:51, Mikael Gerdin wrote: > Hi Stefan, > > On Friday 05 September 2014 18.32.05 Stefan Johansson wrote: >> Hi, >> >> Please review this small change for RFE: >> https://bugs.openjdk.java.net/browse/JDK-8057710 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8057710/webrev.00/ > Looks good. > /Mikael > >> Summary: >> Before this patch the min and max size for G1 heap regions were defined >> by defines and this patch changes this to instead use static const >> within a class and then have getter for the values. >> >> Testing: >> * Builds through JPRT >> * Manually verified that sizes stay the same >> >> Thanks, >> Stefan From bengt.rutisson at oracle.com Mon Sep 8 08:38:30 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 08 Sep 2014 10:38:30 +0200 Subject: RFR: 8057658: Enable G1 FullGC extensions In-Reply-To: <5409C0A2.8090103@oracle.com> References: <5409A1FD.3050304@oracle.com> <2314011.dSF1Z1AjhK@mgerdin03> <5409C0A2.8090103@oracle.com> Message-ID: <540D6B06.4060900@oracle.com> Hi Stefan, On 2014-09-05 15:54, Stefan Johansson wrote: > On 2014-09-05 14:28, Mikael Gerdin wrote: >> Hi Stefan, >> >> On Friday 05 September 2014 13.43.57 Stefan Johansson wrote: >>> Hi, >>> >>> Please review this change for RFE: >>> https://bugs.openjdk.java.net/browse/JDK-8057658 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00/ >> space.hpp: >> While you're there, can you change the name of the constructor >> parameter from >> _gen to something else? The common style is to prefix member >> variables with an >> underscore so this class is in direct opposition to this. You don't >> need to >> change the names of the members of CompactPoint though. > Change it to g, not a better name but at least not going against the > style. >> >> g1MarkSweep: >> Can you move G1PrepareCompactClosure::execute to the G1MarkSweep class? >> It's uncommon for other "closures" in hotspot to have static methods >> to invoke >> them like that. >> Something like >> >> G1MarkSweep::prepare_compaction_work(G1PrepareCompactClosure* blk) { >> g1h->heap_region_iterate(blk) >> blk->update_sets() >> } >> >> and have >> G1MarkSweep::prepare_compaction() { >> G1PrepareCompactClosure blk; >> prepare_compaction_work(&blk); >> } > Fixed, see new webrev for details: > http://cr.openjdk.java.net/~sjohanss/8057658/webrev.01/ > http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00-01/ Looks good. Bengt > > Thanks for reviewing, > Stefan >> >> Otherwise it looks good. >> /Mikael >> >>> Summary: >>> Refactored the G1 mark sweep code to enable specialized FullGC >>> implementations. Also prepared for doing context specific FullGC >>> related >>> to the work for JDK-8057536. >>> >>> Testing: >>> * JPRT >>> * Manual sanity testing >>> >>> Thanks, >>> Stefan > From bengt.rutisson at oracle.com Mon Sep 8 08:45:27 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 08 Sep 2014 10:45:27 +0200 Subject: RFR: JDK-8025564: gc/memory/UniThread/Linear1 times out during heap verification In-Reply-To: <1410163744.2802.2.camel@cirrus> References: <5405BD2C.1040706@oracle.com> <5409B9D9.6070709@oracle.com> <540D5C60.40308@oracle.com> <1410163744.2802.2.camel@cirrus> Message-ID: <540D6CA7.20108@oracle.com> Thanks StefanK and Thomas for the reviews! Bengt On 2014-09-08 10:09, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-09-08 at 09:36 +0200, Bengt Rutisson wrote: >> Hi again, >> >> Another update to the webrev. Now with an overflow check for the obj_end >> calculation: >> http://cr.openjdk.java.net/~brutisso/8025564/webrev.02/ > looks okay. > > Thanks, > Thomas > > From kirk at kodewerk.com Mon Sep 8 09:28:13 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 8 Sep 2014 11:28:13 +0200 Subject: rounding error in logs Message-ID: <0422A05F-8858-4C9F-9882-4793CB3E189F@kodewerk.com> Hi, I?ve got this from a 1.8.0_20 log but it?s been around for some time. [Eden: 448.0M(448.0M)->0.0B(448.0M) Survivors: 64.0M->64.0M Heap: 7740.7M(15.0G)->7334.2M(15.0G)] 15116.779: [GC cleanup 7334M->6817M(15G), 0.0181473 secs] As you can see the occupancy before collection is reported as 7334M where as the occupancy after collection in the summary record is 7334.2M. In this case the collections are less than 5ms apart which means that the .2M discrepancy would appear to be a rounding error due to the precision of how values are being reported. I briefly looked JDK code and it seems as if EXT_SIZE_FORMAT is being used in the initial summary but construction/printing the GC cleanup seems to be delegated to VMThread and it?s not using the same format. On a side note, simply reporting in bytes would be a nice step in simplifying things. Kind regards, Kirk Pepperdine -------------- 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 stefan.johansson at oracle.com Mon Sep 8 11:09:07 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 08 Sep 2014 13:09:07 +0200 Subject: RFR: 8057658: Enable G1 FullGC extensions In-Reply-To: <540D6B06.4060900@oracle.com> References: <5409A1FD.3050304@oracle.com> <2314011.dSF1Z1AjhK@mgerdin03> <5409C0A2.8090103@oracle.com> <540D6B06.4060900@oracle.com> Message-ID: <540D8E53.3040305@oracle.com> Thanks for reviewing this Bengt. Stefan On 2014-09-08 10:38, Bengt Rutisson wrote: > > Hi Stefan, > > On 2014-09-05 15:54, Stefan Johansson wrote: >> On 2014-09-05 14:28, Mikael Gerdin wrote: >>> Hi Stefan, >>> >>> On Friday 05 September 2014 13.43.57 Stefan Johansson wrote: >>>> Hi, >>>> >>>> Please review this change for RFE: >>>> https://bugs.openjdk.java.net/browse/JDK-8057658 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00/ >>> space.hpp: >>> While you're there, can you change the name of the constructor >>> parameter from >>> _gen to something else? The common style is to prefix member >>> variables with an >>> underscore so this class is in direct opposition to this. You don't >>> need to >>> change the names of the members of CompactPoint though. >> Change it to g, not a better name but at least not going against the >> style. >>> >>> g1MarkSweep: >>> Can you move G1PrepareCompactClosure::execute to the G1MarkSweep class? >>> It's uncommon for other "closures" in hotspot to have static methods >>> to invoke >>> them like that. >>> Something like >>> >>> G1MarkSweep::prepare_compaction_work(G1PrepareCompactClosure* blk) { >>> g1h->heap_region_iterate(blk) >>> blk->update_sets() >>> } >>> >>> and have >>> G1MarkSweep::prepare_compaction() { >>> G1PrepareCompactClosure blk; >>> prepare_compaction_work(&blk); >>> } >> Fixed, see new webrev for details: >> http://cr.openjdk.java.net/~sjohanss/8057658/webrev.01/ >> http://cr.openjdk.java.net/~sjohanss/8057658/webrev.00-01/ > > Looks good. > > Bengt > >> >> Thanks for reviewing, >> Stefan >>> >>> Otherwise it looks good. >>> /Mikael >>> >>>> Summary: >>>> Refactored the G1 mark sweep code to enable specialized FullGC >>>> implementations. Also prepared for doing context specific FullGC >>>> related >>>> to the work for JDK-8057536. >>>> >>>> Testing: >>>> * JPRT >>>> * Manual sanity testing >>>> >>>> Thanks, >>>> Stefan >> > From marcus.larsson at oracle.com Mon Sep 8 11:17:38 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 08 Sep 2014 13:17:38 +0200 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <53FF1D0F.8030906@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> Message-ID: <540D9052.7030608@oracle.com> Hi Stefan, On 08/28/2014 02:14 PM, Stefan Karlsson wrote: > Hi Marcus, > > On 28/08/14 13:46, Marcus Larsson wrote: >> Hi, >> >> I would like reviews for the following patch converting the >> SCAN_AND_* macros into (inline) methods. >> >> Short summary: >> The change is based on the demacroify.patch (bug attachment), using a >> proxy class to enable different functions for obj_size and similar to >> be used for different types of Spaces. Each type of space has a proxy >> defining which methods should be used in the scan_and_* functions. >> Made no changes to the actual code in the macros, except for >> replacing a multi-line debug_only(...) with #ifdef ASSERT ... #endif. > > Some background to this change. I wrote it as PoC to see if we could > get rid of these large macros. At that time there werw concerns raised > that some compilers might not be able to inline the template > functions. I checked the code generated by gcc and it was inlined as > expected, but I didn't check the code from the other compilers. > > Are the list of benchmarks below performance runs? Was it done on > different platforms? Did you measure the changed phases > (prepare_for_compation, adjust_pointers, etc.) or did you measure the > benchmark score? The measurements were performance runs, but I only measured benchmark score. I reran the benchmarks, this time to also verify/look at overall GC times and the different phase times. I could find no significant changes in these times on any of the tested platforms (Solaris, Linux, Windows). > >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8043243/ > > Looking at the patch now, I wonder if we shouldn't get rid of the > instance variables in the *SpaceProxy classes and instead pass down > 'this' from the call sites? And make these classes AllStatic. Made the proxies AllStatic (reruns described above used this new version). Also followed Mikael's suggestion and made explicit calls to the known member functions in proxies for CompactibleFreeListSpace and G1OffsetTableContigSpace. New webrev: http://cr.openjdk.java.net/~brutisso/webrev-8043243v2/ Thanks, Marcus > > thanks, > StefanK > >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8043243 >> >> Testing: >> jprt without problems >> SPECjbb2013, SPECjbb2005, SPECjvm2008 - no significant changes >> >> Thanks, >> Marcus > From stefan.karlsson at oracle.com Mon Sep 8 13:45:01 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 08 Sep 2014 15:45:01 +0200 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <540D9052.7030608@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> <540D9052.7030608@oracle.com> Message-ID: <540DB2DD.2010002@oracle.com> On 2014-09-08 13:17, Marcus Larsson wrote: > Hi Stefan, > > On 08/28/2014 02:14 PM, Stefan Karlsson wrote: >> Hi Marcus, >> >> On 28/08/14 13:46, Marcus Larsson wrote: >>> Hi, >>> >>> I would like reviews for the following patch converting the >>> SCAN_AND_* macros into (inline) methods. >>> >>> Short summary: >>> The change is based on the demacroify.patch (bug attachment), using >>> a proxy class to enable different functions for obj_size and similar >>> to be used for different types of Spaces. Each type of space has a >>> proxy defining which methods should be used in the scan_and_* >>> functions. >>> Made no changes to the actual code in the macros, except for >>> replacing a multi-line debug_only(...) with #ifdef ASSERT ... #endif. >> >> Some background to this change. I wrote it as PoC to see if we could >> get rid of these large macros. At that time there werw concerns >> raised that some compilers might not be able to inline the template >> functions. I checked the code generated by gcc and it was inlined as >> expected, but I didn't check the code from the other compilers. >> >> Are the list of benchmarks below performance runs? Was it done on >> different platforms? Did you measure the changed phases >> (prepare_for_compation, adjust_pointers, etc.) or did you measure the >> benchmark score? > > The measurements were performance runs, but I only measured benchmark > score. I reran the benchmarks, this time to also verify/look at > overall GC times and the different phase times. I could find no > significant changes in these times on any of the tested platforms > (Solaris, Linux, Windows). > >> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~brutisso/webrev-8043243/ >> >> Looking at the patch now, I wonder if we shouldn't get rid of the >> instance variables in the *SpaceProxy classes and instead pass down >> 'this' from the call sites? And make these classes AllStatic. > > Made the proxies AllStatic (reruns described above used this new > version). > Also followed Mikael's suggestion and made explicit calls to the known > member functions in proxies for CompactibleFreeListSpace and > G1OffsetTableContigSpace. > > New webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8043243v2/ Looks good. StefanK > > Thanks, > Marcus > >> >> thanks, >> StefanK >> >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8043243 >>> >>> Testing: >>> jprt without problems >>> SPECjbb2013, SPECjbb2005, SPECjvm2008 - no significant changes >>> >>> Thanks, >>> Marcus >> > From tprintezis at twitter.com Mon Sep 8 14:19:16 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Mon, 08 Sep 2014 10:19:16 -0400 Subject: null-check in G1KeepAliveClosure::do_oop() - needed? Message-ID: <540DBAE4.9050307@twitter.com> Hi all, I was a bit perplexed by the following code: class G1KeepAliveClosure: public OopClosure { ... void do_oop(oop* p) { oop obj = *p; G1CollectedHeap::in_cset_state_t cset_state = _g1->in_cset_state(obj); if (obj == NULL || cset_state == G1CollectedHeap::InNeither) { return; } Is the NULL check needed (can obj actually be NULL)? If it is, why is it done after the look-up in in_cset_state()? And is in_cset_state() actually robust wrt obj being NULL? Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From thomas.schatzl at oracle.com Mon Sep 8 14:32:26 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 08 Sep 2014 16:32:26 +0200 Subject: null-check in G1KeepAliveClosure::do_oop() - needed? In-Reply-To: <540DBAE4.9050307@twitter.com> References: <540DBAE4.9050307@twitter.com> Message-ID: <1410186746.2802.49.camel@cirrus> Hi, On Mon, 2014-09-08 at 10:19 -0400, Tony Printezis wrote: > Hi all, > > I was a bit perplexed by the following code: > > class G1KeepAliveClosure: public OopClosure { > ... > void do_oop(oop* p) { > oop obj = *p; > > G1CollectedHeap::in_cset_state_t cset_state = _g1->in_cset_state(obj); > if (obj == NULL || cset_state == G1CollectedHeap::InNeither) { > return; > } > > Is the NULL check needed (can obj actually be NULL)? No, does not seem so. The only use of G1KeepAliveClosure seems to be the use in JNIHandleBlock::weak_oops_do. That one already filters out NULL values. > If it is, why is it > done after the look-up in in_cset_state()? And is in_cset_state() > actually robust wrt obj being NULL? No. This is a bug. If you have time, please change the NULL check to an assert and remove it in the regular code. Thanks, Thomas From tprintezis at twitter.com Mon Sep 8 14:35:05 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Mon, 08 Sep 2014 10:35:05 -0400 Subject: null-check in G1KeepAliveClosure::do_oop() - needed? In-Reply-To: <1410186746.2802.49.camel@cirrus> References: <540DBAE4.9050307@twitter.com> <1410186746.2802.49.camel@cirrus> Message-ID: <540DBE99.3090009@twitter.com> Thomas, Thanks for getting back to me promptly. I'll create a CR and post a patch. Tony On 9/8/14, 10:32 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-09-08 at 10:19 -0400, Tony Printezis wrote: >> Hi all, >> >> I was a bit perplexed by the following code: >> >> class G1KeepAliveClosure: public OopClosure { >> ... >> void do_oop(oop* p) { >> oop obj = *p; >> >> G1CollectedHeap::in_cset_state_t cset_state = _g1->in_cset_state(obj); >> if (obj == NULL || cset_state == G1CollectedHeap::InNeither) { >> return; >> } >> >> Is the NULL check needed (can obj actually be NULL)? > No, does not seem so. The only use of G1KeepAliveClosure seems to be the > use in JNIHandleBlock::weak_oops_do. That one already filters out NULL > values. > >> If it is, why is it >> done after the look-up in in_cset_state()? And is in_cset_state() >> actually robust wrt obj being NULL? > No. This is a bug. If you have time, please change the NULL check to an > assert and remove it in the regular code. > > Thanks, > Thomas > > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From tprintezis at twitter.com Mon Sep 8 15:29:34 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Mon, 08 Sep 2014 11:29:34 -0400 Subject: RFR (XXS): 8057799: G1: unnecessary null check in G1KeepAliveClosure Message-ID: <540DCB5E.6010102@twitter.com> (following a quick e-mail exchange with Thomas) Here's a small change to remove an unnecessary NULL check from G1KeepAliveClosure: http://cr.openjdk.java.net/~tonyp/8057799/webrev.0/ If I could get a couple of reviews and a volunteer to sponsor this, it'd be awesome. :-) Thanks, Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From mikael.gerdin at oracle.com Mon Sep 8 16:00:09 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Sep 2014 18:00:09 +0200 Subject: RFR: 8057722 G1: Code root hashtable updated incorrectly when evacuation failed Message-ID: <4276575.L7sS1HHJ1m@mgerdin03> Hi all, When processing evacuation failures the code root hashtable is walked to determine which code roots should still be present after the failed evacuation. The condition used to determine if an entry should be removed was accidentally inverted. This caused some missing nmethod remembered set entries after evacuation failures. I also noticed a problem where the _length field was not properly updated after evacuation failures, I fixed this as well and factored out the code to remove a hashtable entry to a separate function. Buglink: https://bugs.openjdk.java.net/browse/JDK-8057722 Webrev: http://cr.openjdk.java.net/~mgerdin/8057722/webrev.0/ Testing done: Failing test (with and without "-XX:+G1EvacuationFailureALot -XX:+VerifyAfterGC -XX:+G1VerifyHeapRegionCodeRoots" which easily triggers the assert) /Mikael From John.Coomes at oracle.com Tue Sep 9 07:00:58 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Sep 2014 00:00:58 -0700 Subject: review request (S) - 8057818: collect allocation context stats Message-ID: <21518.42410.895682.408591@mykonos.us.oracle.com> Hi, Please review an interface for collecting allocation context statistics at g1 gc pauses: 8057818: collect allocation context statistics at gc pauses http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/ -John From John.Coomes at oracle.com Tue Sep 9 07:21:51 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Sep 2014 00:21:51 -0700 Subject: review request (S) - 8057824 methods to copy allocation context stats Message-ID: <21518.43663.788681.115837@mykonos.us.oracle.com> Hi, Please review this interface for copying allocation context statistics to native or java arrays. http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ -John From John.Coomes at oracle.com Tue Sep 9 07:45:04 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Sep 2014 00:45:04 -0700 Subject: review request (S/M) - 8057827: notify an obj when stats are available Message-ID: <21518.45056.901519.128115@mykonos.us.oracle.com> Please review the api for notifying an object when updated statistics are available at the end of a gc pause: 8057827: notify an obj when allocation context stats are available http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ -John From stefan.karlsson at oracle.com Tue Sep 9 09:03:56 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 11:03:56 +0200 Subject: RFR (XXS): 8057799: G1: unnecessary null check in G1KeepAliveClosure In-Reply-To: <540DCB5E.6010102@twitter.com> References: <540DCB5E.6010102@twitter.com> Message-ID: <540EC27C.10206@oracle.com> Hi Tony, On 2014-09-08 17:29, Tony Printezis wrote: > (following a quick e-mail exchange with Thomas) > > Here's a small change to remove an unnecessary NULL check from > G1KeepAliveClosure: > > http://cr.openjdk.java.net/~tonyp/8057799/webrev.0/ Looks good. I had to verify that G1StringDedup doesn't assert with this change. There's no explicit null-check in the code, but we don't set the oops to NULL G1StringDedupTable. A side-note: I think this call to JNIHandles::weak_oops_do(&is_alive, &keep_alive) is not needed, since it's already cleaned during the reference processing: void ReferenceProcessor::process_phaseJNI(BoolObjectClosure* is_alive, OopClosure* keep_alive, VoidClosure* complete_gc) { ... JNIHandles::weak_oops_do(is_alive, keep_alive); complete_gc->do_void(); } thanks, StefanK > > If I could get a couple of reviews and a volunteer to sponsor this, > it'd be awesome. :-) > > Thanks, > > Tony > From mikael.gerdin at oracle.com Tue Sep 9 09:19:20 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 11:19:20 +0200 Subject: Fix for JDK-8048556 (GCLocker issues): feedback and some testing please? In-Reply-To: <54063351.3080306@twitter.com> References: <53FE8E90.7090508@twitter.com> <540484D7.6060303@oracle.com> <54063351.3080306@twitter.com> Message-ID: <6134806.1jJxalvT0b@mgerdin03> Tony, On Tuesday 02 September 2014 17.14.57 Tony Printezis wrote: > Mikael, > > Inline. > > On 9/1/14, 10:38 AM, Mikael Gerdin wrote: > > Hi Tony, > > > > On 2014-08-28 04:06, Tony Printezis wrote: > >> Hi all, > >> > >> I have a fix for the GCLocker causing unnecessary young GCs issue > >> (JDK-8048556). Here's the webrev: > >> > >> http://cr.openjdk.java.net/~tonyp/8048556/webrev.0/ > >> > >> Any chance of a) getting some feedback on whether the fix is reasonable > >> and b) getting it through some testing (I did as much testing as I could > >> but you know how fragile the GCLocker is...)? > > > > I've started some testing on this fix (JPRT, GC test suite). > > Thanks! So far my testing looks good. It looks like G1CollectedHeap::collect(GCCause::Cause cause) also reads the total_collections count and thus may trigger a superfluous evacuation pause. Why didn't you want to pass a total_collections count to G1's variant? /Mikael > > >> I didn't really want to change the CollectedHeap API. However, I can't > >> work out another way to pass the two GC counts to the VM op without > >> changes to the CollectedHeap. I could have expanded the collect() method > >> to also accept the count arguments. However, I don't think collect() > >> should really be used for the GCLocker GC and I feel that a separate > >> method is appropriate here. > > > > I agree that it's reasonable to have a separate collect_for_gc_locker. > > Definitely less confusing in the long term... > > >> I also ended up renaming an argument to a c'tor from _cause to cause, as > >> the former should only be used for class members. Hope that's OK. > > > > Yep, that's always bothered me. > > I aim to please. :-) > > Tony > > >> Thanks, > >> > >> Tony From mikael.gerdin at oracle.com Tue Sep 9 09:26:41 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 11:26:41 +0200 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <540D9052.7030608@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> <540D9052.7030608@oracle.com> Message-ID: <3468265.T8AfEsfQME@mgerdin03> Marcus, On Monday 08 September 2014 13.17.38 Marcus Larsson wrote: > Hi Stefan, > > On 08/28/2014 02:14 PM, Stefan Karlsson wrote: > > Hi Marcus, > > > > On 28/08/14 13:46, Marcus Larsson wrote: > >> Hi, > >> > >> I would like reviews for the following patch converting the > >> SCAN_AND_* macros into (inline) methods. > >> > >> Short summary: > >> The change is based on the demacroify.patch (bug attachment), using a > >> proxy class to enable different functions for obj_size and similar to > >> be used for different types of Spaces. Each type of space has a proxy > >> defining which methods should be used in the scan_and_* functions. > >> Made no changes to the actual code in the macros, except for > >> replacing a multi-line debug_only(...) with #ifdef ASSERT ... #endif. > > > > Some background to this change. I wrote it as PoC to see if we could > > get rid of these large macros. At that time there werw concerns raised > > that some compilers might not be able to inline the template > > functions. I checked the code generated by gcc and it was inlined as > > expected, but I didn't check the code from the other compilers. > > > > Are the list of benchmarks below performance runs? Was it done on > > different platforms? Did you measure the changed phases > > (prepare_for_compation, adjust_pointers, etc.) or did you measure the > > benchmark score? > > The measurements were performance runs, but I only measured benchmark > score. I reran the benchmarks, this time to also verify/look at overall > GC times and the different phase times. I could find no significant > changes in these times on any of the tested platforms (Solaris, Linux, > Windows). > > >> Webrev: > >> http://cr.openjdk.java.net/~brutisso/webrev-8043243/ > > > > Looking at the patch now, I wonder if we shouldn't get rid of the > > instance variables in the *SpaceProxy classes and instead pass down > > 'this' from the call sites? And make these classes AllStatic. > > Made the proxies AllStatic (reruns described above used this new version). > Also followed Mikael's suggestion and made explicit calls to the known > member functions in proxies for CompactibleFreeListSpace and > G1OffsetTableContigSpace. > > New webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8043243v2/ Looks good. /Mikael > > Thanks, > Marcus > > > thanks, > > StefanK > > > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8043243 > >> > >> Testing: > >> jprt without problems > >> SPECjbb2013, SPECjbb2005, SPECjvm2008 - no significant changes > >> > >> Thanks, > >> Marcus From mikael.gerdin at oracle.com Tue Sep 9 09:43:33 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 11:43:33 +0200 Subject: review request (S) - 8057818: collect allocation context stats In-Reply-To: <21518.42410.895682.408591@mykonos.us.oracle.com> References: <21518.42410.895682.408591@mykonos.us.oracle.com> Message-ID: <2763062.r2ousVhN2g@mgerdin03> Hi John, On Tuesday 09 September 2014 00.00.58 John Coomes wrote: > Hi, > > Please review an interface for collecting allocation context > statistics at g1 gc pauses: > > 8057818: collect allocation context statistics at gc pauses > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/ Why don't you inline the AllocationContextStats inside the class declaration instead? It looks weird that the class just above uses that pattern and this class doesn't. You don't really need to declare an inline emtpy default constructor. We usually keep the "&" reference operator next to the type, just like we do with pointer types: inline AllocationContextStats& allocation_context_stats(); and inline AllocationContextStats& G1CollectedHeap::allocation_context_stats() { there's not really any point to keeping the implementation of allocation_context_stats() in the .inline.hpp file since G1CollectedHeap needs the full class declaration of AllocationContextStats to determine its size since it's embedded in the G1CollectedHeap object. /Mikael > > -John From stefan.karlsson at oracle.com Tue Sep 9 09:40:32 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 11:40:32 +0200 Subject: RFR: 8057918: Update out-dated ignore tags in GC jtreg tests Message-ID: <540ECB10.6030108@oracle.com> Hi all, Please review this patch to remove/fix a few jtreg @ignore tags. http://cr.openjdk.java.net/~stefank/8057918/webrev.00/ The following bugs were fixed/changed: Fixed: https://bugs.openjdk.java.net/browse/JDK-8027915 Env problem: https://bugs.openjdk.java.net/browse/JDK-8025645 Closed/duplicate: https://bugs.openjdk.java.net/browse/JDK-8042051 thanks, StefanK From mikael.gerdin at oracle.com Tue Sep 9 10:12:08 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 12:12:08 +0200 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <21518.43663.788681.115837@mykonos.us.oracle.com> References: <21518.43663.788681.115837@mykonos.us.oracle.com> Message-ID: <10297116.OEWtnbNIFl@mgerdin03> Hi John, On Tuesday 09 September 2014 00.21.51 John Coomes wrote: > Hi, > > Please review this interface for copying allocation context statistics > to native or java arrays. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ Why do you add the additional entry point to the CollectedHeap superclass? All the other related code seems to be specific to G1. If we ever decide to extend this sort of functionality to to the other collectors it's a simple change to do when we actually need it. /Mikael > > -John From thomas.schatzl at oracle.com Tue Sep 9 11:12:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Sep 2014 13:12:53 +0200 Subject: RFR (XXS): 8057799: G1: unnecessary null check in G1KeepAliveClosure In-Reply-To: <540EC27C.10206@oracle.com> References: <540DCB5E.6010102@twitter.com> <540EC27C.10206@oracle.com> Message-ID: <1410261173.2647.1.camel@cirrus> Hi, On Tue, 2014-09-09 at 11:03 +0200, Stefan Karlsson wrote: > Hi Tony, > > On 2014-09-08 17:29, Tony Printezis wrote: > > (following a quick e-mail exchange with Thomas) > > > > Here's a small change to remove an unnecessary NULL check from > > G1KeepAliveClosure: > > > > http://cr.openjdk.java.net/~tonyp/8057799/webrev.0/ > > Looks good. Looks good. I can sponsor this. Thanks, Thomas From bengt.rutisson at oracle.com Tue Sep 9 11:33:08 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 09 Sep 2014 13:33:08 +0200 Subject: RFR: 8057722 G1: Code root hashtable updated incorrectly when evacuation failed In-Reply-To: <4276575.L7sS1HHJ1m@mgerdin03> References: <4276575.L7sS1HHJ1m@mgerdin03> Message-ID: <540EE574.9040408@oracle.com> Hi Mikael, On 2014-09-08 18:00, Mikael Gerdin wrote: > Hi all, > > When processing evacuation failures the code root hashtable is walked to > determine which code roots should still be present after the failed > evacuation. > The condition used to determine if an entry should be removed was accidentally > inverted. This caused some missing nmethod remembered set entries after > evacuation failures. > > I also noticed a problem where the _length field was not properly updated > after evacuation failures, I fixed this as well and factored out the code to > remove a hashtable entry to a separate function. > > Buglink: https://bugs.openjdk.java.net/browse/JDK-8057722 > Webrev: http://cr.openjdk.java.net/~mgerdin/8057722/webrev.0/ Looks good. Thanks for finding and fixing this! Bengt > > Testing done: Failing test (with and without > "-XX:+G1EvacuationFailureALot > -XX:+VerifyAfterGC > -XX:+G1VerifyHeapRegionCodeRoots" > which easily triggers the assert) > > /Mikael From stefan.karlsson at oracle.com Tue Sep 9 11:35:25 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 13:35:25 +0200 Subject: RFR: 8057918: Update out-dated ignore tags in GC jtreg tests In-Reply-To: <540ECB10.6030108@oracle.com> References: <540ECB10.6030108@oracle.com> Message-ID: <540EE5FD.1010207@oracle.com> Erik told me that: https://bugs.openjdk.java.net/browse/JDK-8027915 has been replaced by: https://bugs.openjdk.java.net/browse/JDK-8049864 Here's an updated webrev: http://cr.openjdk.java.net/~stefank/8057918/webrev.01/ thanks, StefanK On 2014-09-09 11:40, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove/fix a few jtreg @ignore tags. > > http://cr.openjdk.java.net/~stefank/8057918/webrev.00/ > > The following bugs were fixed/changed: > > Fixed: > https://bugs.openjdk.java.net/browse/JDK-8027915 > > Env problem: > https://bugs.openjdk.java.net/browse/JDK-8025645 > > Closed/duplicate: > https://bugs.openjdk.java.net/browse/JDK-8042051 > > thanks, > StefanK From erik.helin at oracle.com Tue Sep 9 11:50:43 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Sep 2014 13:50:43 +0200 Subject: RFR: 8057918: Update out-dated ignore tags in GC jtreg tests In-Reply-To: <540EE5FD.1010207@oracle.com> References: <540ECB10.6030108@oracle.com> <540EE5FD.1010207@oracle.com> Message-ID: <540EE993.50304@oracle.com> Looks good, Reviewed. Thanks, Erik On 2014-09-09 13:35, Stefan Karlsson wrote: > Erik told me that: > https://bugs.openjdk.java.net/browse/JDK-8027915 > > has been replaced by: > https://bugs.openjdk.java.net/browse/JDK-8049864 > > Here's an updated webrev: > http://cr.openjdk.java.net/~stefank/8057918/webrev.01/ > > thanks, > StefanK > > On 2014-09-09 11:40, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove/fix a few jtreg @ignore tags. >> >> http://cr.openjdk.java.net/~stefank/8057918/webrev.00/ >> >> The following bugs were fixed/changed: >> >> Fixed: >> https://bugs.openjdk.java.net/browse/JDK-8027915 >> >> Env problem: >> https://bugs.openjdk.java.net/browse/JDK-8025645 >> >> Closed/duplicate: >> https://bugs.openjdk.java.net/browse/JDK-8042051 >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Tue Sep 9 11:43:31 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 13:43:31 +0200 Subject: RFR: 8057918: Update out-dated ignore tags in GC jtreg tests In-Reply-To: <540EE993.50304@oracle.com> References: <540ECB10.6030108@oracle.com> <540EE5FD.1010207@oracle.com> <540EE993.50304@oracle.com> Message-ID: <540EE7E3.4040703@oracle.com> On 2014-09-09 13:50, Erik Helin wrote: > Looks good, Reviewed. Thanks, StefanK > > Thanks, > Erik > > On 2014-09-09 13:35, Stefan Karlsson wrote: >> Erik told me that: >> https://bugs.openjdk.java.net/browse/JDK-8027915 >> >> has been replaced by: >> https://bugs.openjdk.java.net/browse/JDK-8049864 >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~stefank/8057918/webrev.01/ >> >> thanks, >> StefanK >> >> On 2014-09-09 11:40, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to remove/fix a few jtreg @ignore tags. >>> >>> http://cr.openjdk.java.net/~stefank/8057918/webrev.00/ >>> >>> The following bugs were fixed/changed: >>> >>> Fixed: >>> https://bugs.openjdk.java.net/browse/JDK-8027915 >>> >>> Env problem: >>> https://bugs.openjdk.java.net/browse/JDK-8025645 >>> >>> Closed/duplicate: >>> https://bugs.openjdk.java.net/browse/JDK-8042051 >>> >>> thanks, >>> StefanK >> From stefan.karlsson at oracle.com Tue Sep 9 11:45:31 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 13:45:31 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <5409A607.1020906@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> Message-ID: <540EE85B.9000003@oracle.com> (Adding GC) Hi, Could I get a couple of reviews for this test fix? StefanK On 2014-09-05 14:01, Stefan Karlsson wrote: > Hi all, > > Here's an updated version of the test: > http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ > http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ > > 1) The max == -1 check would unnecessarily fail the test (if it ever > would happen). > > 2) Some flags/configurations could increase the young gen size because > of alignment restrictions in the heap sizing policies. I've updated > the test to make sure that we run > a) with small G1 heap region sizes > b) without large pages > > I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the > risk that someone will add arbitrary GC command line options to the test. > > thanks, > StefanK > > On 2014-09-04 16:34, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to make these tests a bit more stable. I've >> changed the code to always allocate objects that are larger than the >> young gen size. >> >> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >> >> I've tested this by running the tests through jprt. >> >> thanks, >> StefanK > From thomas.schatzl at oracle.com Tue Sep 9 11:59:34 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Sep 2014 13:59:34 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <540A2B9F.2000105@twitter.com> References: <540A2B9F.2000105@twitter.com> Message-ID: <1410263974.2647.22.camel@cirrus> Hi Tony, the change is useful. I created JDK-8057768 for it. On Fri, 2014-09-05 at 17:31 -0400, Tony Printezis wrote: > Hi all, > > One of the things that has always annoyed me in G1 is that working out > the type of a heap region is a complete mess: > > - there are separate fields for "humongous type" and "young type" > - to check whether a region is free we have to check is_empty() > - we cannot explicitly check whether a region is old (if it's none of > the other types, then it's old) > > If anyone wants to add new region types (as we all seem to want to do > these days!!!), doing so is a bit of a pain and more error-prone than it > should be. Could I ask you to consider the following patch that > introduces a HeapRegionType class, which encapsulates all the region > type information, and replaces the young / humongous type fields with > HeapRegionType _type? > > http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.0/ Some comments: - there is a compile error on non-gcc compilers: they do not allow a final comma after the last enum value in HeapRegionType::Tag. This is only allowed in C++11. - please avoid use of the automatic coercion of ints to bools in the tests for is_young/is_humongous :). Actually some compilers complain about it. - while we are at touching this code I would appreciate if the method names for isHumongous(), startsHumongous() and continuesHumongous() in the HeapRegion class would be changed to fit the others as well. I.e. is_humongous(), is_startsHu.., is_contin...(). That could probably done in an extra CR as it adds lots of noise. - possibly rename reset_Humongous() to clear_humongous() too since we unset/clear the humongous-related fields. - in HeapRegion::hr_clear(), instead of removing the assert, its condition could be changed to !is_humongous(). - it's fine with me to add a HeapRegionType class. Others may have a different preference. However, the heapRegionType.?pp files need some cleanup: - copyright dates for new files are just the last year - I do not think we need the #if INCLUDE_ALL_GCS here or in any heapRegion* file. We can clean that up later. - the encoding table for the Tag should probably be moved to the enum. Further it would be nice to write an introductory sentence what this table is about and why. I put up a webrev with some of the suggested changes at http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ Thanks, Thomas From thomas.schatzl at oracle.com Tue Sep 9 12:02:42 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Sep 2014 14:02:42 +0200 Subject: RFR: 8057918: Update out-dated ignore tags in GC jtreg tests In-Reply-To: <540EE5FD.1010207@oracle.com> References: <540ECB10.6030108@oracle.com> <540EE5FD.1010207@oracle.com> Message-ID: <1410264162.2647.23.camel@cirrus> Hi, On Tue, 2014-09-09 at 13:35 +0200, Stefan Karlsson wrote: > Erik told me that: > https://bugs.openjdk.java.net/browse/JDK-8027915 > > has been replaced by: > https://bugs.openjdk.java.net/browse/JDK-8049864 > > Here's an updated webrev: > http://cr.openjdk.java.net/~stefank/8057918/webrev.01/ > > thanks, > StefanK looks good to me. Thomas From stefan.karlsson at oracle.com Tue Sep 9 11:53:37 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 13:53:37 +0200 Subject: RFR: 8057918: Update out-dated ignore tags in GC jtreg tests In-Reply-To: <1410264162.2647.23.camel@cirrus> References: <540ECB10.6030108@oracle.com> <540EE5FD.1010207@oracle.com> <1410264162.2647.23.camel@cirrus> Message-ID: <540EEA41.8090807@oracle.com> On 2014-09-09 14:02, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-09 at 13:35 +0200, Stefan Karlsson wrote: >> Erik told me that: >> https://bugs.openjdk.java.net/browse/JDK-8027915 >> >> has been replaced by: >> https://bugs.openjdk.java.net/browse/JDK-8049864 >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~stefank/8057918/webrev.01/ >> >> thanks, >> StefanK > looks good to me. Thanks. StefanK > > Thomas > From bengt.rutisson at oracle.com Tue Sep 9 12:13:19 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 09 Sep 2014 14:13:19 +0200 Subject: RFR (S): JDK-8057910: G1: BOT verification should not pass top Message-ID: <540EEEDF.5030404@oracle.com> Hi all, Can I have a couple of reviews for this fix? http://cr.openjdk.java.net/~brutisso/8057910/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057910 After the fix for JDK-8025564 the BOT verification may pass the end for the reserved space. The reason is this code in G1BlockOffsetArray::verify(): size_t start_card = _array->index_for(gsp()->bottom()); size_t end_card = _array->index_for(gsp()->top()); The end_card should not be based on top() but on "top() - 1" to make sure we are inside the heap region and thus inside the reserved space. Testing: - Ad hoc aurora tests simulating nightly testing. The current bug failed a lot in the nightly testing. - JPRT Thanks, Bengt From stefan.karlsson at oracle.com Tue Sep 9 12:12:27 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 14:12:27 +0200 Subject: RFR (S): JDK-8057910: G1: BOT verification should not pass top In-Reply-To: <540EEEDF.5030404@oracle.com> References: <540EEEDF.5030404@oracle.com> Message-ID: <540EEEAB.8090100@oracle.com> On 2014-09-09 14:13, Bengt Rutisson wrote: > > Hi all, > > Can I have a couple of reviews for this fix? > > http://cr.openjdk.java.net/~brutisso/8057910/webrev.00/ Looks good. thanks, StefanK > > https://bugs.openjdk.java.net/browse/JDK-8057910 > > > After the fix for JDK-8025564 the BOT verification may pass the end > for the reserved space. The reason is this code in > G1BlockOffsetArray::verify(): > > size_t start_card = _array->index_for(gsp()->bottom()); > size_t end_card = _array->index_for(gsp()->top()); > > The end_card should not be based on top() but on "top() - 1" to make > sure we are inside the heap region and thus inside the reserved space. > > Testing: > - Ad hoc aurora tests simulating nightly testing. The current bug > failed a lot in the nightly testing. > - JPRT > > Thanks, > Bengt From thomas.schatzl at oracle.com Tue Sep 9 12:32:16 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Sep 2014 14:32:16 +0200 Subject: RFR (S): JDK-8057910: G1: BOT verification should not pass top In-Reply-To: <540EEEDF.5030404@oracle.com> References: <540EEEDF.5030404@oracle.com> Message-ID: <1410265936.2647.24.camel@cirrus> Hi, On Tue, 2014-09-09 at 14:13 +0200, Bengt Rutisson wrote: > Hi all, > > Can I have a couple of reviews for this fix? > > http://cr.openjdk.java.net/~brutisso/8057910/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8057910 > > > After the fix for JDK-8025564 the BOT verification may pass the end for > the reserved space. The reason is this code in G1BlockOffsetArray::verify(): > > size_t start_card = _array->index_for(gsp()->bottom()); > size_t end_card = _array->index_for(gsp()->top()); > > The end_card should not be based on top() but on "top() - 1" to make > sure we are inside the heap region and thus inside the reserved space. > > Testing: > - Ad hoc aurora tests simulating nightly testing. The current bug failed > a lot in the nightly testing. > - JPRT looks good. Thomas From mikael.gerdin at oracle.com Tue Sep 9 12:37:24 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 14:37:24 +0200 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <21518.45056.901519.128115@mykonos.us.oracle.com> References: <21518.45056.901519.128115@mykonos.us.oracle.com> Message-ID: <12160733.yJksDZMDzN@mgerdin03> On Tuesday 09 September 2014 00.45.04 John Coomes wrote: > Please review the api for notifying an object when updated statistics > are available at the end of a gc pause: > > 8057827: notify an obj when allocation context stats are available > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ Can you maintain this object as a global JNI handle (jobject) inside AllocationContextService instead of adding a new static oop in Universe? The other static oops in Universe seem to be more system and bootstrap-related as opposed to the user-settable nature of the notification object. /Mikael > > -John From bengt.rutisson at oracle.com Tue Sep 9 12:31:59 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 09 Sep 2014 14:31:59 +0200 Subject: RFR (S): JDK-8057910: G1: BOT verification should not pass top In-Reply-To: <1410265936.2647.24.camel@cirrus> References: <540EEEDF.5030404@oracle.com> <1410265936.2647.24.camel@cirrus> Message-ID: <540EF33F.4080205@oracle.com> Thanks StefanK and Thomas for the quick reviews! I'll push this directly now to get cleaner tests this night. Thanks, Bengt On 2014-09-09 14:32, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-09 at 14:13 +0200, Bengt Rutisson wrote: >> Hi all, >> >> Can I have a couple of reviews for this fix? >> >> http://cr.openjdk.java.net/~brutisso/8057910/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8057910 >> >> >> After the fix for JDK-8025564 the BOT verification may pass the end for >> the reserved space. The reason is this code in G1BlockOffsetArray::verify(): >> >> size_t start_card = _array->index_for(gsp()->bottom()); >> size_t end_card = _array->index_for(gsp()->top()); >> >> The end_card should not be based on top() but on "top() - 1" to make >> sure we are inside the heap region and thus inside the reserved space. >> >> Testing: >> - Ad hoc aurora tests simulating nightly testing. The current bug failed >> a lot in the nightly testing. >> - JPRT > looks good. > > Thomas > > From stefan.karlsson at oracle.com Tue Sep 9 12:29:26 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 14:29:26 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540EECC1.9070102@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> Message-ID: <540EF2A6.5000805@oracle.com> Hi Jaroslav, Thanks a lot for looking at the test change. On 2014-09-09 14:04, Jaroslav Bachorik wrote: > Hi Stefan, > > * test/java/lang/management/MemoryMXBean/LowMemoryTest.java > L71 - `g1Flag` is not used anywhere; should it be removed? It should be used. I've updated the patch: http://cr.openjdk.java.net/~stefank/8057174/webrev.02 and have restarted the test runs. thanks, StefanK > > Other than that the change looks fine. > > -JB- > > On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >> (Adding GC) >> >> Hi, >> >> Could I get a couple of reviews for this test fix? >> >> StefanK >> >> On 2014-09-05 14:01, Stefan Karlsson wrote: >>> Hi all, >>> >>> Here's an updated version of the test: >>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>> >>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>> would happen). >>> >>> 2) Some flags/configurations could increase the young gen size because >>> of alignment restrictions in the heap sizing policies. I've updated >>> the test to make sure that we run >>> a) with small G1 heap region sizes >>> b) without large pages >>> >>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>> risk that someone will add arbitrary GC command line options to the >>> test. >>> >>> thanks, >>> StefanK >>> >>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to make these tests a bit more stable. I've >>>> changed the code to always allocate objects that are larger than the >>>> young gen size. >>>> >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>> >>>> I've tested this by running the tests through jprt. >>>> >>>> thanks, >>>> StefanK >>> >> > From jesper.wilhelmsson at oracle.com Tue Sep 9 12:56:44 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 09 Sep 2014 14:56:44 +0200 Subject: RFR: 8057722 G1: Code root hashtable updated incorrectly when evacuation failed In-Reply-To: <4276575.L7sS1HHJ1m@mgerdin03> References: <4276575.L7sS1HHJ1m@mgerdin03> Message-ID: <540EF90C.9020505@oracle.com> Looks good! /Jesper Mikael Gerdin skrev 8/9/14 18:00: > Hi all, > > When processing evacuation failures the code root hashtable is walked to > determine which code roots should still be present after the failed > evacuation. > The condition used to determine if an entry should be removed was accidentally > inverted. This caused some missing nmethod remembered set entries after > evacuation failures. > > I also noticed a problem where the _length field was not properly updated > after evacuation failures, I fixed this as well and factored out the code to > remove a hashtable entry to a separate function. > > Buglink: https://bugs.openjdk.java.net/browse/JDK-8057722 > Webrev: http://cr.openjdk.java.net/~mgerdin/8057722/webrev.0/ > > Testing done: Failing test (with and without > "-XX:+G1EvacuationFailureALot > -XX:+VerifyAfterGC > -XX:+G1VerifyHeapRegionCodeRoots" > which easily triggers the assert) > > /Mikael > From jesper.wilhelmsson at oracle.com Tue Sep 9 13:08:45 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 09 Sep 2014 15:08:45 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540EF2A6.5000805@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> <540EF2A6.5000805@oracle.com> Message-ID: <540EFBDD.9010409@oracle.com> Hi Stefan, g1Flag is only used in one place. In my opinion it doesn't add any value having it as a variable rather than just putting the flag directly where it is used (keeping the comment of course): RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseSerialGC"); RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseParallelGC"); RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseConcMarkSweepGC"); // Prevent G1 from selecting a large heap region size, // since that would change the young gen size. RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseG1GC", "-XX:G1HeapRegionSize=1m"); Besides that, ship it! /Jesper Stefan Karlsson skrev 9/9/14 14:29: > Hi Jaroslav, > > Thanks a lot for looking at the test change. > > On 2014-09-09 14:04, Jaroslav Bachorik wrote: >> Hi Stefan, >> >> * test/java/lang/management/MemoryMXBean/LowMemoryTest.java >> L71 - `g1Flag` is not used anywhere; should it be removed? > > It should be used. I've updated the patch: > http://cr.openjdk.java.net/~stefank/8057174/webrev.02 > > and have restarted the test runs. > > thanks, > StefanK > >> >> Other than that the change looks fine. >> >> -JB- >> >> On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >>> (Adding GC) >>> >>> Hi, >>> >>> Could I get a couple of reviews for this test fix? >>> >>> StefanK >>> >>> On 2014-09-05 14:01, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Here's an updated version of the test: >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>>> >>>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>>> would happen). >>>> >>>> 2) Some flags/configurations could increase the young gen size because >>>> of alignment restrictions in the heap sizing policies. I've updated >>>> the test to make sure that we run >>>> a) with small G1 heap region sizes >>>> b) without large pages >>>> >>>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>>> risk that someone will add arbitrary GC command line options to the test. >>>> >>>> thanks, >>>> StefanK >>>> >>>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to make these tests a bit more stable. I've >>>>> changed the code to always allocate objects that are larger than the >>>>> young gen size. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>>> >>>>> I've tested this by running the tests through jprt. >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From stefan.karlsson at oracle.com Tue Sep 9 14:06:50 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 16:06:50 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540EFBDD.9010409@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> <540EF2A6.5000805@oracle.com> <540EFBDD.9010409@oracle.com> Message-ID: <540F097A.9030202@oracle.com> Hi Jesper, On 2014-09-09 15:08, Jesper Wilhelmsson wrote: > Hi Stefan, > > g1Flag is only used in one place. In my opinion it doesn't add any > value having it as a variable rather than just putting the flag > directly where it is used (keeping the comment of course): > > RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseSerialGC"); > RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseParallelGC"); > RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, > "-XX:+UseConcMarkSweepGC"); > > // Prevent G1 from selecting a large heap region size, > // since that would change the young gen size. > RunUtil.runTestClearGcOpts(main, nmFlag, lpFlag, "-XX:+UseG1GC", > "-XX:G1HeapRegionSize=1m"); I think my version makes the documentation of that flag more explicit and makes it easier to read the list of run targets. I'll prefer to keep it as it is. > Besides that, ship it! thanks, StefanK > /Jesper > > > Stefan Karlsson skrev 9/9/14 14:29: >> Hi Jaroslav, >> >> Thanks a lot for looking at the test change. >> >> On 2014-09-09 14:04, Jaroslav Bachorik wrote: >>> Hi Stefan, >>> >>> * test/java/lang/management/MemoryMXBean/LowMemoryTest.java >>> L71 - `g1Flag` is not used anywhere; should it be removed? >> >> It should be used. I've updated the patch: >> http://cr.openjdk.java.net/~stefank/8057174/webrev.02 >> >> and have restarted the test runs. >> >> thanks, >> StefanK >> >>> >>> Other than that the change looks fine. >>> >>> -JB- >>> >>> On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >>>> (Adding GC) >>>> >>>> Hi, >>>> >>>> Could I get a couple of reviews for this test fix? >>>> >>>> StefanK >>>> >>>> On 2014-09-05 14:01, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Here's an updated version of the test: >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>>>> >>>>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>>>> would happen). >>>>> >>>>> 2) Some flags/configurations could increase the young gen size >>>>> because >>>>> of alignment restrictions in the heap sizing policies. I've updated >>>>> the test to make sure that we run >>>>> a) with small G1 heap region sizes >>>>> b) without large pages >>>>> >>>>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>>>> risk that someone will add arbitrary GC command line options to >>>>> the test. >>>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to make these tests a bit more stable. I've >>>>>> changed the code to always allocate objects that are larger than the >>>>>> young gen size. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>>>> >>>>>> I've tested this by running the tests through jprt. >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>> >>>> >>> >> From stefan.karlsson at oracle.com Tue Sep 9 14:07:15 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 16:07:15 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540EF767.3040700@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> <540EF2A6.5000805@oracle.com> <540EF767.3040700@oracle.com> Message-ID: <540F0993.60702@oracle.com> On 2014-09-09 14:49, Daniel Fuchs wrote: > Hi, > > Looks good to me - although I'm not a specialist of -XX options ;-) :) Thanks, Daniel. StefanK > > -- daniel > > On 9/9/14 2:29 PM, Stefan Karlsson wrote: >> Hi Jaroslav, >> >> Thanks a lot for looking at the test change. >> >> On 2014-09-09 14:04, Jaroslav Bachorik wrote: >>> Hi Stefan, >>> >>> * test/java/lang/management/MemoryMXBean/LowMemoryTest.java >>> L71 - `g1Flag` is not used anywhere; should it be removed? >> >> It should be used. I've updated the patch: >> http://cr.openjdk.java.net/~stefank/8057174/webrev.02 >> >> and have restarted the test runs. >> >> thanks, >> StefanK >> >>> >>> Other than that the change looks fine. >>> >>> -JB- >>> >>> On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >>>> (Adding GC) >>>> >>>> Hi, >>>> >>>> Could I get a couple of reviews for this test fix? >>>> >>>> StefanK >>>> >>>> On 2014-09-05 14:01, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Here's an updated version of the test: >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>>>> >>>>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>>>> would happen). >>>>> >>>>> 2) Some flags/configurations could increase the young gen size >>>>> because >>>>> of alignment restrictions in the heap sizing policies. I've updated >>>>> the test to make sure that we run >>>>> a) with small G1 heap region sizes >>>>> b) without large pages >>>>> >>>>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>>>> risk that someone will add arbitrary GC command line options to the >>>>> test. >>>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to make these tests a bit more stable. I've >>>>>> changed the code to always allocate objects that are larger than the >>>>>> young gen size. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>>>> >>>>>> I've tested this by running the tests through jprt. >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Tue Sep 9 14:31:11 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 16:31:11 +0200 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <540A47E0.2080803@oracle.com> References: <540A47E0.2080803@oracle.com> Message-ID: <2548885.ND5rUTNDSq@mgerdin03> Hi Staffan, On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: > Hi, > > Copying both the compiler and GC alias as the optimization involves both > groups. > > This optimization aims to avoid generating G1 barriers for newly > allocated objects where the compiler can prove that the object has not > been written to earlier and there is no safepoint between the allocation > and the write. The bug has some further details and microbenchmark > result. The new code has fairly extensive comments about the optimization. > > It would be great if the GC team can help validate that the premise of > the optimization is correct as well. > > webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ I mostly read through the comments since I can't decode what the IR transforms intend to do :) We usually stick to the terms "old generation" and "young generation" instead of "Old Space" and "Young Space". "G1 also requires to keep track of objects between different + * regions to enable evacuation of old regions" should probably be. .."to keep track of references between different regions" I leave it to the compiler team to review the actual code changes. > bug: https://bugs.openjdk.java.net/browse/JDK-8057737 > > I would also need a sponsor for this change if it passes review. I'll push this to hs-gc after review since we have more G1 test coverage on hs-gc. /Mikael > > Thanks, > Staffan From stefan.karlsson at oracle.com Tue Sep 9 14:37:49 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Sep 2014 16:37:49 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540F0C5A.20302@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> <540EF2A6.5000805@oracle.com> <540F0C5A.20302@oracle.com> Message-ID: <540F10BD.6070701@oracle.com> On 2014-09-09 16:19, Jaroslav Bachorik wrote: > Thumbs up! Thanks. StefanK > > -JB- > > On 09/09/2014 02:29 PM, Stefan Karlsson wrote: >> Hi Jaroslav, >> >> Thanks a lot for looking at the test change. >> >> On 2014-09-09 14:04, Jaroslav Bachorik wrote: >>> Hi Stefan, >>> >>> * test/java/lang/management/MemoryMXBean/LowMemoryTest.java >>> L71 - `g1Flag` is not used anywhere; should it be removed? >> >> It should be used. I've updated the patch: >> http://cr.openjdk.java.net/~stefank/8057174/webrev.02 >> >> and have restarted the test runs. >> >> thanks, >> StefanK >> >>> >>> Other than that the change looks fine. >>> >>> -JB- >>> >>> On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >>>> (Adding GC) >>>> >>>> Hi, >>>> >>>> Could I get a couple of reviews for this test fix? >>>> >>>> StefanK >>>> >>>> On 2014-09-05 14:01, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Here's an updated version of the test: >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>>>> >>>>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>>>> would happen). >>>>> >>>>> 2) Some flags/configurations could increase the young gen size >>>>> because >>>>> of alignment restrictions in the heap sizing policies. I've updated >>>>> the test to make sure that we run >>>>> a) with small G1 heap region sizes >>>>> b) without large pages >>>>> >>>>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>>>> risk that someone will add arbitrary GC command line options to the >>>>> test. >>>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to make these tests a bit more stable. I've >>>>>> changed the code to always allocate objects that are larger than the >>>>>> young gen size. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>>>> >>>>>> I've tested this by running the tests through jprt. >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>> >>>> >>> >> > From tprintezis at twitter.com Tue Sep 9 14:50:51 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 09 Sep 2014 10:50:51 -0400 Subject: Fix for JDK-8048556 (GCLocker issues): feedback and some testing please? In-Reply-To: <6134806.1jJxalvT0b@mgerdin03> References: <53FE8E90.7090508@twitter.com> <540484D7.6060303@oracle.com> <54063351.3080306@twitter.com> <6134806.1jJxalvT0b@mgerdin03> Message-ID: <540F13CB.8070005@twitter.com> Mikael, Inline. On 9/9/14, 5:19 AM, Mikael Gerdin wrote: > I've started some testing on this fix (JPRT, GC test suite). >> Thanks! > So far my testing looks good. Thanks. And thanks for the extra testing on this!!! Much appreciated. > It looks like G1CollectedHeap::collect(GCCause::Cause cause) also reads the > total_collections count and thus may trigger a superfluous evacuation pause. > Why didn't you want to pass a total_collections count to G1's variant? (I should have added a comment for this) I couldn't reproduce the issue with G1. It looks as if the issue had been discovered on G1 and Cuthbertson fixed it some time ago: https://bugs.openjdk.java.net/browse/JDK-7143858 This is why I was conservative and left the G1 path unchanged. I had a look at G1CollectedHeap::collect(cause) and it wouldn't be trivial to move that functionality to collect_for_gc_locker(), mainly because of the need to handle GCLockerInvokesConcurrent (where is that helpful anyway?!?!?!). See should_do_concurrent_full_gc(cause) which is called from collect(cause). We could decide to restructure the G1 code to make it more similar to what the other two GCs do wrt the handling of collect_for_gc_locker(). But, could we maybe do that on a separate CR? Tony > /Mikael > >>>> I didn't really want to change the CollectedHeap API. However, I can't >>>> work out another way to pass the two GC counts to the VM op without >>>> changes to the CollectedHeap. I could have expanded the collect() method >>>> to also accept the count arguments. However, I don't think collect() >>>> should really be used for the GCLocker GC and I feel that a separate >>>> method is appropriate here. >>> I agree that it's reasonable to have a separate collect_for_gc_locker. >> Definitely less confusing in the long term... >> >>>> I also ended up renaming an argument to a c'tor from _cause to cause, as >>>> the former should only be used for class members. Hope that's OK. >>> Yep, that's always bothered me. >> I aim to please. :-) >> >> Tony >> >>>> Thanks, >>>> >>>> Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From John.Coomes at oracle.com Tue Sep 9 17:08:51 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Sep 2014 10:08:51 -0700 Subject: review request (S) - 8057818: collect allocation context stats In-Reply-To: <2763062.r2ousVhN2g@mgerdin03> References: <21518.42410.895682.408591@mykonos.us.oracle.com> <2763062.r2ousVhN2g@mgerdin03> Message-ID: <21519.13347.289573.930396@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > Hi John, > > On Tuesday 09 September 2014 00.00.58 John Coomes wrote: > > Hi, > > > > Please review an interface for collecting allocation context > > statistics at g1 gc pauses: > > > > 8057818: collect allocation context statistics at gc pauses > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/ > > Why don't you inline the AllocationContextStats inside the class declaration > instead? It looks weird that the class just above uses that pattern and this > class doesn't. You don't really need to declare an inline emtpy default > constructor. Hi Mikael, Thanks for taking a look. I tend to put most/all method bodies outside the class decl to keep the decl readable. This is based at least in part on what I've seen in CollectedHeap and G1CollectedHeap, which are both huge. But these methods are completely trivial, and fit well within the decl so I'll move them. > We usually keep the "&" reference operator next to the type, just like we do > with pointer types: > inline AllocationContextStats& allocation_context_stats(); > and > inline AllocationContextStats& G1CollectedHeap::allocation_context_stats() { Sure, I'll fix that. > there's not really any point to keeping the implementation of > allocation_context_stats() in the .inline.hpp file since G1CollectedHeap needs > the full class declaration of AllocationContextStats to determine its size > since it's embedded in the G1CollectedHeap object. There is one - shrinking g1CollectedHeap.hpp and the G1CollectedHeap class decl :-). I there any harm having it in the .inline.hpp? -John From John.Coomes at oracle.com Tue Sep 9 17:53:25 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Sep 2014 10:53:25 -0700 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <10297116.OEWtnbNIFl@mgerdin03> References: <21518.43663.788681.115837@mykonos.us.oracle.com> <10297116.OEWtnbNIFl@mgerdin03> Message-ID: <21519.16021.622254.335985@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > Hi John, > > On Tuesday 09 September 2014 00.21.51 John Coomes wrote: > > Hi, > > > > Please review this interface for copying allocation context statistics > > to native or java arrays. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ > > Why do you add the additional entry point to the CollectedHeap superclass? > All the other related code seems to be specific to G1. > If we ever decide to extend this sort of functionality to to the other > collectors it's a simple change to do when we actually need it. There is another project that is likely to use this with the serial collector, so this is a bit of future-proofing. If I confirm that they intend to use it, are you okay with the change? -John From mikael.gerdin at oracle.com Tue Sep 9 18:19:12 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 20:19:12 +0200 Subject: review request (S) - 8057818: collect allocation context stats In-Reply-To: <21519.13347.289573.930396@mykonos.us.oracle.com> References: <21518.42410.895682.408591@mykonos.us.oracle.com> <2763062.r2ousVhN2g@mgerdin03> <21519.13347.289573.930396@mykonos.us.oracle.com> Message-ID: <2135977.ddmYhAryJs@vboxbuntu> Hi John, On Tuesday 09 September 2014 10.08.51 John Coomes wrote: > Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > > Hi John, > > > > On Tuesday 09 September 2014 00.00.58 John Coomes wrote: > > > Hi, > > > > > > Please review an interface for collecting allocation context > > > statistics at g1 gc pauses: > > > > > > 8057818: collect allocation context statistics at gc pauses > > > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/ > > > > Why don't you inline the AllocationContextStats inside the class > > declaration instead? It looks weird that the class just above uses that > > pattern and this class doesn't. You don't really need to declare an > > inline emtpy default constructor. > > Hi Mikael, > > Thanks for taking a look. I tend to put most/all method bodies > outside the class decl to keep the decl readable. This is based at > least in part on what I've seen in CollectedHeap and G1CollectedHeap, > which are both huge. But these methods are completely trivial, and > fit well within the decl so I'll move them. > > > We usually keep the "&" reference operator next to the type, just like we > > do> > > with pointer types: > > inline AllocationContextStats& allocation_context_stats(); > > > > and > > > > inline AllocationContextStats& > > G1CollectedHeap::allocation_context_stats() { > Sure, I'll fix that. > > > there's not really any point to keeping the implementation of > > allocation_context_stats() in the .inline.hpp file since G1CollectedHeap > > needs the full class declaration of AllocationContextStats to determine > > its size since it's embedded in the G1CollectedHeap object. > > There is one - shrinking g1CollectedHeap.hpp and the G1CollectedHeap > class decl :-). I there any harm having it in the .inline.hpp? Not really any harm, but not having a simple getter inlined in the hpp file makes me suspect that there's more to the method than just returning the field. In general I agree with keeping delcaration-inline methods short, but I think that simple getters should stay in the declaration. I'm not going to press on the issue though, if you really want to then keep it in the inline.hpp file. /Mikael > > -John From mikael.gerdin at oracle.com Tue Sep 9 18:21:58 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Sep 2014 20:21:58 +0200 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <21519.16021.622254.335985@mykonos.us.oracle.com> References: <21518.43663.788681.115837@mykonos.us.oracle.com> <10297116.OEWtnbNIFl@mgerdin03> <21519.16021.622254.335985@mykonos.us.oracle.com> Message-ID: <1695433.0NdSoX90MB@vboxbuntu> Hi John, On Tuesday 09 September 2014 10.53.25 John Coomes wrote: > Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > > Hi John, > > > > On Tuesday 09 September 2014 00.21.51 John Coomes wrote: > > > Hi, > > > > > > Please review this interface for copying allocation context statistics > > > to native or java arrays. > > > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ > > > > Why do you add the additional entry point to the CollectedHeap superclass? > > All the other related code seems to be specific to G1. > > If we ever decide to extend this sort of functionality to to the other > > collectors it's a simple change to do when we actually need it. > > There is another project that is likely to use this with the serial > collector, so this is a bit of future-proofing. If I confirm that > they intend to use it, are you okay with the change? Yes. That's fine. /Mikael > > -John From John.Coomes at oracle.com Tue Sep 9 20:09:43 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Sep 2014 13:09:43 -0700 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <12160733.yJksDZMDzN@mgerdin03> References: <21518.45056.901519.128115@mykonos.us.oracle.com> <12160733.yJksDZMDzN@mgerdin03> Message-ID: <21519.24199.996612.955@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > On Tuesday 09 September 2014 00.45.04 John Coomes wrote: > > Please review the api for notifying an object when updated statistics > > are available at the end of a gc pause: > > > > 8057827: notify an obj when allocation context stats are available > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ > > Can you maintain this object as a global JNI handle (jobject) inside > AllocationContextService instead of adding a new static oop in Universe? > > The other static oops in Universe seem to be more system and bootstrap-related > as opposed to the user-settable nature of the notification object. Thanks again for looking. FWIW, the expected usage is that it will be set soon after initialization (from libraries code), and remain in place for the remainder of the JVM's lifetime, so it's mostly static. I'll look at using a global jni handle instead, but I'd like to do that as a separate change. -John From jon.masamitsu at oracle.com Tue Sep 9 20:35:37 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 09 Sep 2014 13:35:37 -0700 Subject: review request (S) - 8057818: collect allocation context stats In-Reply-To: <21518.42410.895682.408591@mykonos.us.oracle.com> References: <21518.42410.895682.408591@mykonos.us.oracle.com> Message-ID: <540F6499.6090900@oracle.com> John, http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html For now or a later clean up. I'm used to having the accessor have a name more similar to the field. I would suggest changing _alloc_ctx_stats to _allocation_context_stats. + // Statistics for each allocation context + AllocationContextStats _alloc_ctx_stats; + + inline AllocationContextStats & allocation_context_stats(); Rest looks good modulo Mikael's comments. Reviewed. Jon On 09/09/2014 12:00 AM, John Coomes wrote: > Hi, > > Please review an interface for collecting allocation context > statistics at g1 gc pauses: > > 8057818: collect allocation context statistics at gc pauses > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/ > > -John From tprintezis at twitter.com Tue Sep 9 20:43:16 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 09 Sep 2014 16:43:16 -0400 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <1410263974.2647.22.camel@cirrus> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> Message-ID: <540F6664.1050000@twitter.com> Thomas, Thanks for looking at this. Inline. On 9/9/14, 7:59 AM, Thomas Schatzl wrote: > Hi Tony, > > the change is useful. I created JDK-8057768 for it. > > On Fri, 2014-09-05 at 17:31 -0400, Tony Printezis wrote: >> Hi all, >> >> One of the things that has always annoyed me in G1 is that working out >> the type of a heap region is a complete mess: >> >> - there are separate fields for "humongous type" and "young type" >> - to check whether a region is free we have to check is_empty() >> - we cannot explicitly check whether a region is old (if it's none of >> the other types, then it's old) >> >> If anyone wants to add new region types (as we all seem to want to do >> these days!!!), doing so is a bit of a pain and more error-prone than it >> should be. Could I ask you to consider the following patch that >> introduces a HeapRegionType class, which encapsulates all the region >> type information, and replaces the young / humongous type fields with >> HeapRegionType _type? >> >> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.0/ > Some comments: > > - there is a compile error on non-gcc compilers: they do not allow a > final comma after the last enum value in HeapRegionType::Tag. Sorry, that was a mistake. I hate the use of comma as a terminator. :-) > This is only allowed in C++11. > > - please avoid use of the automatic coercion of ints to bools in the > tests for is_young/is_humongous :). > Actually some compilers complain about it. Yeah, good point. != 0 is right here. > - while we are at touching this code I would appreciate if the method > names for isHumongous(), startsHumongous() and continuesHumongous() in > the HeapRegion class would be changed to fit the others as well. I.e. > is_humongous(), is_startsHu.., is_contin...(). > > That could probably done in an extra CR as it adds lots of noise. How about this: I never liked the lower camel case in the *Humongous() methods on HeapRegion and I'd like to rename them to is_humongous(), is_starts_humongous(), is_continues_humongous(). However, as you pointed out that'd be a big noisy change (there are 100+ instances of those methods in the G1 codebase). So, how about I leave the methods on HeapRegionType as we'd like them to be and rename the rest as a follow-up change (and I'll be happy to work on that once this goes in)? Sounds reasonable? > - possibly rename reset_Humongous() to clear_humongous() too since we > unset/clear the humongous-related fields. Good suggestion. > - in HeapRegion::hr_clear(), instead of removing the assert, its > condition could be changed to !is_humongous(). Actually, this doesn't hold any more, which is why I removed the assert. Note that clear_humongous() I doesn't change the type of the region any more, as I removed: _humongous_type = NotHumongous; The type is set to free in hr_clear() (which is called immediately after clear_humongous()) (same reason I removed the same assert from g1HotCardCache.cpp BTW). I could set the type to free in clear_humongous() too and re-add the assert but I don't think it matters. The main requirement is that these two fields should be cleared in clear_humongous(): assert(_humongous_start_region == NULL, "we should have already filtered out humongous regions"); assert(_end == _orig_end, "we should have already filtered out humongous regions"); > - it's fine with me to add a HeapRegionType class. Others may have a > different preference. I also like it too. I could also put the extra functionality in HeapRegion.* (but those files are already bloated). > However, the heapRegionType.?pp files need some cleanup: > - copyright dates for new files are just the last year Thanks for fixing this. > - I do not think we need the #if INCLUDE_ALL_GCS here or in any > heapRegion* file. We can clean that up later. OK. > - the encoding table for the Tag should probably be moved to the > enum. Further it would be nice to write an introductory sentence what > this table is about and why. OK. (And yes I'll expand the comment on the tags a bit) One more thing I should have made clear: given that I now use HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the ad-hoc code that was there, the output of both (and there's a fair amount of output that relies on the former) is going to change. Is that a problem? I could make sure the output remains the same (by adding more get_*_str() methods). I personally don't think it's worth it. > I put up a webrev with some of the suggested changes at > http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ Thanks for making the changes. I'll send an update based on your patch (and once we agree on some of the issues I mentioned above). Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From thomas.schatzl at oracle.com Tue Sep 9 21:23:01 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Sep 2014 23:23:01 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <540F6664.1050000@twitter.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> Message-ID: <1410297781.3807.21.camel@cirrus> Hi, On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: > Thomas, > > Thanks for looking at this. Inline. > > On 9/9/14, 7:59 AM, Thomas Schatzl wrote: > > - while we are at touching this code I would appreciate if the method > > names for isHumongous(), startsHumongous() and continuesHumongous() in > > the HeapRegion class would be changed to fit the others as well. I.e. > > is_humongous(), is_startsHu.., is_contin...(). > > > > That could probably done in an extra CR as it adds lots of noise. > > How about this: I never liked the lower camel case in the *Humongous() > methods on HeapRegion and I'd like to rename them to is_humongous(), > is_starts_humongous(), is_continues_humongous(). However, as you pointed > out that'd be a big noisy change (there are 100+ instances of those > methods in the G1 codebase). So, how about I leave the methods on > HeapRegionType as we'd like them to be and rename the rest as a > follow-up change (and I'll be happy to work on that once this goes in)? > Sounds reasonable? Yes, let's leave the rename out for now. I quickly thought about the naming, the state names were StartsHumongous and ContinuesHumongous, so similar to the others, I would somewhat slightly prefer to keep them together (i.e. is_) and not add underscores to break the two words of the state name. Not really against the proposed naming though (adding the underscore). What I would really like to avoid is to have different order of the words in the state name: right now the change uses is_continues_humongous() in HeapRegion but is_humongous_cont() in HeapRegionType. That seems to be unnecessary. My suggestion is to use the same name in HeapRegionType and HeapRegion. (Btw, the change should also remove the HumongousType enum in heapRegion.hpp) > > - in HeapRegion::hr_clear(), instead of removing the assert, its > > condition could be changed to !is_humongous(). > > Actually, this doesn't hold any more, which is why I removed the assert. > Note that clear_humongous() I doesn't change the type of the region any > more, as I removed: > > _humongous_type = NotHumongous; > > The type is set to free in hr_clear() (which is called immediately after > clear_humongous()) (same reason I removed the same assert from > g1HotCardCache.cpp BTW). I could set the type to free in > clear_humongous() too and re-add the assert but I don't think it > matters. The main requirement is that these two fields should be cleared > in clear_humongous(): > > assert(_humongous_start_region == NULL, > "we should have already filtered out humongous regions"); > assert(_end == _orig_end, > "we should have already filtered out humongous regions"); > Okay. > > - I do not think we need the #if INCLUDE_ALL_GCS here or in any > > heapRegion* file. We can clean that up later. > > OK. Actually I think I already fixed that in the change I gave you. > > - the encoding table for the Tag should probably be moved to the > > enum. Further it would be nice to write an introductory sentence what > > this table is about and why. > > OK. (And yes I'll expand the comment on the tags a bit) > > One more thing I should have made clear: given that I now use > HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in > G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the > ad-hoc code that was there, the output of both (and there's a fair > amount of output that relies on the former) is going to change. Is that > a problem? I could make sure the output remains the same (by adding more > get_*_str() methods). I personally don't think it's worth it. Need to look at that again, but I would somewhat prefer to keep the short names, e.g. HC/HS in that output. A get_short_str() method isn't be that hard to add. > > I put up a webrev with some of the suggested changes at > > http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ > > Thanks for making the changes. I'll send an update based on your patch > (and once we agree on some of the issues I mentioned above). Thanks, Thomas From jon.masamitsu at oracle.com Tue Sep 9 21:55:26 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 09 Sep 2014 14:55:26 -0700 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <21518.43663.788681.115837@mykonos.us.oracle.com> References: <21518.43663.788681.115837@mykonos.us.oracle.com> Message-ID: <540F774E.7000100@oracle.com> Changes look good. Reviewed. Jon On 09/09/2014 12:21 AM, John Coomes wrote: > Hi, > > Please review this interface for copying allocation context statistics > to native or java arrays. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ > > -John From jon.masamitsu at oracle.com Tue Sep 9 22:50:42 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 09 Sep 2014 15:50:42 -0700 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <21519.24199.996612.955@mykonos.us.oracle.com> References: <21518.45056.901519.128115@mykonos.us.oracle.com> <12160733.yJksDZMDzN@mgerdin03> <21519.24199.996612.955@mykonos.us.oracle.com> Message-ID: <540F8442.4050101@oracle.com> On 09/09/2014 01:09 PM, John Coomes wrote: > Mikael Gerdin (mikael.gerdin at oracle.com) wrote: >> On Tuesday 09 September 2014 00.45.04 John Coomes wrote: >>> Please review the api for notifying an object when updated statistics >>> are available at the end of a gc pause: >>> >>> 8057827: notify an obj when allocation context stats are available >>> >>> http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ >> Can you maintain this object as a global JNI handle (jobject) inside >> AllocationContextService instead of adding a new static oop in Universe? >> >> The other static oops in Universe seem to be more system and bootstrap-related >> as opposed to the user-settable nature of the notification object. > Thanks again for looking. > > FWIW, the expected usage is that it will be set soon after > initialization (from libraries code), and remain in place for the > remainder of the JVM's lifetime, so it's mostly static. > > I'll look at using a global jni handle instead, but I'd like to do > that as a separate change. > > -John John, Assuming the change to _available that Mikael suggested, rest looks good. Reviewed. Jon From tprintezis at twitter.com Wed Sep 10 00:09:19 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 09 Sep 2014 20:09:19 -0400 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <1410297781.3807.21.camel@cirrus> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> Message-ID: <540F96AF.4000505@twitter.com> Thomas, On 9/9/14, 5:23 PM, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: >> Thomas, >> >> Thanks for looking at this. Inline. >> >> On 9/9/14, 7:59 AM, Thomas Schatzl wrote: >>> - while we are at touching this code I would appreciate if the method >>> names for isHumongous(), startsHumongous() and continuesHumongous() in >>> the HeapRegion class would be changed to fit the others as well. I.e. >>> is_humongous(), is_startsHu.., is_contin...(). >>> >>> That could probably done in an extra CR as it adds lots of noise. >> How about this: I never liked the lower camel case in the *Humongous() >> methods on HeapRegion and I'd like to rename them to is_humongous(), >> is_starts_humongous(), is_continues_humongous(). However, as you pointed >> out that'd be a big noisy change (there are 100+ instances of those >> methods in the G1 codebase). So, how about I leave the methods on >> HeapRegionType as we'd like them to be and rename the rest as a >> follow-up change (and I'll be happy to work on that once this goes in)? >> Sounds reasonable? > Yes, let's leave the rename out for now. OK. > I quickly thought about the naming, the state names were StartsHumongous > and ContinuesHumongous, so similar to the others, I would somewhat > slightly prefer to keep them together (i.e. is_) and not add > underscores to break the two words of the state name. Not really against > the proposed naming though (adding the underscore). is_humongous() is_StartsHumongous() is_ContinuesHumongous() At the risk of sounding totally pedantic :-), lower case h on the first and capital on the next two bothers me a bit. I'd prefer the all-lowercase version with underscores if that's OK. > What I would really like to avoid is to have different order of the > words in the state name: right now the change uses > is_continues_humongous() in HeapRegion but is_humongous_cont() in > HeapRegionType. That seems to be unnecessary. > > My suggestion is to use the same name in HeapRegionType and HeapRegion. Yep. You're totally right. > (Btw, the change should also remove the HumongousType enum in > heapRegion.hpp) And the YoungType! :-) Done. >>> - in HeapRegion::hr_clear(), instead of removing the assert, its >>> condition could be changed to !is_humongous(). >> Actually, this doesn't hold any more, which is why I removed the assert. >> Note that clear_humongous() I doesn't change the type of the region any >> more, as I removed: >> >> _humongous_type = NotHumongous; >> >> The type is set to free in hr_clear() (which is called immediately after >> clear_humongous()) (same reason I removed the same assert from >> g1HotCardCache.cpp BTW). I could set the type to free in >> clear_humongous() too and re-add the assert but I don't think it >> matters. The main requirement is that these two fields should be cleared >> in clear_humongous(): >> >> assert(_humongous_start_region == NULL, >> "we should have already filtered out humongous regions"); >> assert(_end == _orig_end, >> "we should have already filtered out humongous regions"); >> > Okay. > >>> - I do not think we need the #if INCLUDE_ALL_GCS here or in any >>> heapRegion* file. We can clean that up later. >> OK. > Actually I think I already fixed that in the change I gave you. Yes, you did. >>> - the encoding table for the Tag should probably be moved to the >>> enum. Further it would be nice to write an introductory sentence what >>> this table is about and why. >> OK. (And yes I'll expand the comment on the tags a bit) >> >> One more thing I should have made clear: given that I now use >> HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in >> G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the >> ad-hoc code that was there, the output of both (and there's a fair >> amount of output that relies on the former) is going to change. Is that >> a problem? I could make sure the output remains the same (by adding more >> get_*_str() methods). I personally don't think it's worth it. > Need to look at that again, but I would somewhat prefer to keep the > short names, e.g. HC/HS in that output. > > A get_short_str() method isn't be that hard to add. Done. I'll post the new webrev shortly. Tony >>> I put up a webrev with some of the suggested changes at >>> http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ >> Thanks for making the changes. I'll send an update based on your patch >> (and once we agree on some of the issues I mentioned above). > Thanks, > Thomas > > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From tprintezis at twitter.com Wed Sep 10 01:03:48 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 09 Sep 2014 21:03:48 -0400 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <1410297781.3807.21.camel@cirrus> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> Message-ID: <540FA374.3040401@twitter.com> Latest webrev which I think includes all that we discussed: http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.1/ Tony On 9/9/14, 5:23 PM, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: >> Thomas, >> >> Thanks for looking at this. Inline. >> >> On 9/9/14, 7:59 AM, Thomas Schatzl wrote: >>> - while we are at touching this code I would appreciate if the method >>> names for isHumongous(), startsHumongous() and continuesHumongous() in >>> the HeapRegion class would be changed to fit the others as well. I.e. >>> is_humongous(), is_startsHu.., is_contin...(). >>> >>> That could probably done in an extra CR as it adds lots of noise. >> How about this: I never liked the lower camel case in the *Humongous() >> methods on HeapRegion and I'd like to rename them to is_humongous(), >> is_starts_humongous(), is_continues_humongous(). However, as you pointed >> out that'd be a big noisy change (there are 100+ instances of those >> methods in the G1 codebase). So, how about I leave the methods on >> HeapRegionType as we'd like them to be and rename the rest as a >> follow-up change (and I'll be happy to work on that once this goes in)? >> Sounds reasonable? > Yes, let's leave the rename out for now. > > I quickly thought about the naming, the state names were StartsHumongous > and ContinuesHumongous, so similar to the others, I would somewhat > slightly prefer to keep them together (i.e. is_) and not add > underscores to break the two words of the state name. Not really against > the proposed naming though (adding the underscore). > > What I would really like to avoid is to have different order of the > words in the state name: right now the change uses > is_continues_humongous() in HeapRegion but is_humongous_cont() in > HeapRegionType. That seems to be unnecessary. > > My suggestion is to use the same name in HeapRegionType and HeapRegion. > > (Btw, the change should also remove the HumongousType enum in > heapRegion.hpp) > >>> - in HeapRegion::hr_clear(), instead of removing the assert, its >>> condition could be changed to !is_humongous(). >> Actually, this doesn't hold any more, which is why I removed the assert. >> Note that clear_humongous() I doesn't change the type of the region any >> more, as I removed: >> >> _humongous_type = NotHumongous; >> >> The type is set to free in hr_clear() (which is called immediately after >> clear_humongous()) (same reason I removed the same assert from >> g1HotCardCache.cpp BTW). I could set the type to free in >> clear_humongous() too and re-add the assert but I don't think it >> matters. The main requirement is that these two fields should be cleared >> in clear_humongous(): >> >> assert(_humongous_start_region == NULL, >> "we should have already filtered out humongous regions"); >> assert(_end == _orig_end, >> "we should have already filtered out humongous regions"); >> > Okay. > >>> - I do not think we need the #if INCLUDE_ALL_GCS here or in any >>> heapRegion* file. We can clean that up later. >> OK. > Actually I think I already fixed that in the change I gave you. > >>> - the encoding table for the Tag should probably be moved to the >>> enum. Further it would be nice to write an introductory sentence what >>> this table is about and why. >> OK. (And yes I'll expand the comment on the tags a bit) >> >> One more thing I should have made clear: given that I now use >> HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in >> G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the >> ad-hoc code that was there, the output of both (and there's a fair >> amount of output that relies on the former) is going to change. Is that >> a problem? I could make sure the output remains the same (by adding more >> get_*_str() methods). I personally don't think it's worth it. > Need to look at that again, but I would somewhat prefer to keep the > short names, e.g. HC/HS in that output. > > A get_short_str() method isn't be that hard to add. > >>> I put up a webrev with some of the suggested changes at >>> http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ >> Thanks for making the changes. I'll send an update based on your patch >> (and once we agree on some of the issues I mentioned above). > Thanks, > Thomas > > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From tprintezis at twitter.com Wed Sep 10 03:28:44 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 09 Sep 2014 23:28:44 -0400 Subject: RFR (XXS): 8057799: G1: unnecessary null check in G1KeepAliveClosure In-Reply-To: <540EC27C.10206@oracle.com> References: <540DCB5E.6010102@twitter.com> <540EC27C.10206@oracle.com> Message-ID: <540FC56C.1080303@twitter.com> Hi Stefan, Inline. On 9/9/14, 5:03 AM, Stefan Karlsson wrote: > Hi Tony, > > On 2014-09-08 17:29, Tony Printezis wrote: >> (following a quick e-mail exchange with Thomas) >> >> Here's a small change to remove an unnecessary NULL check from >> G1KeepAliveClosure: >> >> http://cr.openjdk.java.net/~tonyp/8057799/webrev.0/ > > Looks good. Thanks. > I had to verify that G1StringDedup doesn't assert with this change. If it does, it would have asserted with the original code too, given that _g1->in_cset_state(obj) is called before the null check. > There's no explicit null-check in the code, but we don't set the oops > to NULL G1StringDedupTable. > > A side-note: I think this call to JNIHandles::weak_oops_do(&is_alive, > &keep_alive) is not needed, since it's already cleaned during the > reference processing: > void ReferenceProcessor::process_phaseJNI(BoolObjectClosure* is_alive, > OopClosure* keep_alive, > VoidClosure* complete_gc) { > ... > JNIHandles::weak_oops_do(is_alive, keep_alive); > complete_gc->do_void(); > } Yeah, I added a print statement in weak_oops_do() and I can confirm that. Tony > thanks, > StefanK > >> >> If I could get a couple of reviews and a volunteer to sponsor this, >> it'd be awesome. :-) >> >> Thanks, >> >> Tony >> > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From tprintezis at twitter.com Wed Sep 10 03:29:29 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 09 Sep 2014 23:29:29 -0400 Subject: RFR (XXS): 8057799: G1: unnecessary null check in G1KeepAliveClosure In-Reply-To: <1410261173.2647.1.camel@cirrus> References: <540DCB5E.6010102@twitter.com> <540EC27C.10206@oracle.com> <1410261173.2647.1.camel@cirrus> Message-ID: <540FC599.6010006@twitter.com> Thanks Thomas. On 9/9/14, 7:12 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-09 at 11:03 +0200, Stefan Karlsson wrote: >> Hi Tony, >> >> On 2014-09-08 17:29, Tony Printezis wrote: >>> (following a quick e-mail exchange with Thomas) >>> >>> Here's a small change to remove an unnecessary NULL check from >>> G1KeepAliveClosure: >>> >>> http://cr.openjdk.java.net/~tonyp/8057799/webrev.0/ >> Looks good. > Looks good. I can sponsor this. > > Thanks, > Thomas > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From mikael.gerdin at oracle.com Wed Sep 10 07:21:58 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 10 Sep 2014 09:21:58 +0200 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <21519.24199.996612.955@mykonos.us.oracle.com> References: <21518.45056.901519.128115@mykonos.us.oracle.com> <12160733.yJksDZMDzN@mgerdin03> <21519.24199.996612.955@mykonos.us.oracle.com> Message-ID: <2326715.oDBEvMoKZJ@mgerdin03> On Tuesday 09 September 2014 13.09.43 John Coomes wrote: > Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > > On Tuesday 09 September 2014 00.45.04 John Coomes wrote: > > > Please review the api for notifying an object when updated statistics > > > are available at the end of a gc pause: > > > > > > 8057827: notify an obj when allocation context stats are available > > > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ > > > > Can you maintain this object as a global JNI handle (jobject) inside > > AllocationContextService instead of adding a new static oop in Universe? > > > > The other static oops in Universe seem to be more system and > > bootstrap-related as opposed to the user-settable nature of the > > notification object. > Thanks again for looking. > > FWIW, the expected usage is that it will be set soon after > initialization (from libraries code), and remain in place for the > remainder of the JVM's lifetime, so it's mostly static. > > I'll look at using a global jni handle instead, but I'd like to do > that as a separate change. That's ok with me. Thanks /Mikael > > -John From thomas.schatzl at oracle.com Wed Sep 10 08:04:47 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Sep 2014 10:04:47 +0200 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <21518.43663.788681.115837@mykonos.us.oracle.com> References: <21518.43663.788681.115837@mykonos.us.oracle.com> Message-ID: <1410336287.2681.12.camel@cirrus> Hi, On Tue, 2014-09-09 at 00:21 -0700, John Coomes wrote: > Hi, > > Please review this interface for copying allocation context statistics > to native or java arrays. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ > some comments: - in the declarations of the copy_allocation_context_stats() methods please put every parameter on a single line. - please give a description of the method, it seems to be non-obvious. I assume that the passed "len" indicates the number of contexts/totals/accuracies that are passed. - spaces before the "*", which is unusual Thanks, Thomas From thomas.schatzl at oracle.com Wed Sep 10 08:09:03 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Sep 2014 10:09:03 +0200 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <21518.45056.901519.128115@mykonos.us.oracle.com> References: <21518.45056.901519.128115@mykonos.us.oracle.com> Message-ID: <1410336543.2681.13.camel@cirrus> Hi, On Tue, 2014-09-09 at 00:45 -0700, John Coomes wrote: > Please review the api for notifying an object when updated statistics > are available at the end of a gc pause: > > 8057827: notify an obj when allocation context stats are available > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ > looks okay. Thomas From John.Coomes at oracle.com Wed Sep 10 12:59:38 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 10 Sep 2014 05:59:38 -0700 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <540F8442.4050101@oracle.com> References: <21518.45056.901519.128115@mykonos.us.oracle.com> <12160733.yJksDZMDzN@mgerdin03> <21519.24199.996612.955@mykonos.us.oracle.com> <540F8442.4050101@oracle.com> Message-ID: <21520.19258.935768.232639@mykonos.us.oracle.com> Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > > On 09/09/2014 01:09 PM, John Coomes wrote: > > Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > >> On Tuesday 09 September 2014 00.45.04 John Coomes wrote: > >>> Please review the api for notifying an object when updated statistics > >>> are available at the end of a gc pause: > >>> > >>> 8057827: notify an obj when allocation context stats are available > >>> > >>> http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ > >> Can you maintain this object as a global JNI handle (jobject) inside > >> AllocationContextService instead of adding a new static oop in Universe? > >> > >> The other static oops in Universe seem to be more system and bootstrap-related > >> as opposed to the user-settable nature of the notification object. > > Thanks again for looking. > > > > FWIW, the expected usage is that it will be set soon after > > initialization (from libraries code), and remain in place for the > > remainder of the JVM's lifetime, so it's mostly static. > > > > I'll look at using a global jni handle instead, but I'd like to do > > that as a separate change. > > > > -John > > John, > > Assuming the change to _available that Mikael suggested, > rest looks good. Sure, I already adopted that suggestion. Thanks for reviewing it. -John From John.Coomes at oracle.com Wed Sep 10 13:00:09 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 10 Sep 2014 06:00:09 -0700 Subject: review request (S/M) - 8057827: notify an obj when stats are available In-Reply-To: <1410336543.2681.13.camel@cirrus> References: <21518.45056.901519.128115@mykonos.us.oracle.com> <1410336543.2681.13.camel@cirrus> Message-ID: <21520.19289.792885.554925@mykonos.us.oracle.com> Thomas Schatzl (thomas.schatzl at oracle.com) wrote: > Hi, > > On Tue, 2014-09-09 at 00:45 -0700, John Coomes wrote: > > Please review the api for notifying an object when updated statistics > > are available at the end of a gc pause: > > > > 8057827: notify an obj when allocation context stats are available > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057827-stats-notify/ > > > > looks okay. Thanks for looking at it. -John From thomas.schatzl at oracle.com Wed Sep 10 13:09:24 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Sep 2014 15:09:24 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <540F96AF.4000505@twitter.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540F96AF.4000505@twitter.com> Message-ID: <1410354564.2681.32.camel@cirrus> Hi, On Tue, 2014-09-09 at 20:09 -0400, Tony Printezis wrote: > Thomas, > > On 9/9/14, 5:23 PM, Thomas Schatzl wrote: > > Hi, > > > > On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: > >> Thomas, > >> > >> Thanks for looking at this. Inline. > >> > >> On 9/9/14, 7:59 AM, Thomas Schatzl wrote: > >>> - while we are at touching this code I would appreciate if the method > >>> names for isHumongous(), startsHumongous() and continuesHumongous() in > >>> the HeapRegion class would be changed to fit the others as well. I.e. > >>> is_humongous(), is_startsHu.., is_contin...(). > >>> > >>> That could probably done in an extra CR as it adds lots of noise. > >> How about this: I never liked the lower camel case in the *Humongous() > >> methods on HeapRegion and I'd like to rename them to is_humongous(), > >> is_starts_humongous(), is_continues_humongous(). However, as you pointed > >> out that'd be a big noisy change (there are 100+ instances of those > >> methods in the G1 codebase). So, how about I leave the methods on > >> HeapRegionType as we'd like them to be and rename the rest as a > >> follow-up change (and I'll be happy to work on that once this goes in)? > >> Sounds reasonable? > > Yes, let's leave the rename out for now. > > OK. > > > I quickly thought about the naming, the state names were StartsHumongous > > and ContinuesHumongous, so similar to the others, I would somewhat > > slightly prefer to keep them together (i.e. is_) and not add > > underscores to break the two words of the state name. Not really against > > the proposed naming though (adding the underscore). > > is_humongous() > is_StartsHumongous() > is_ContinuesHumongous() > > At the risk of sounding totally pedantic :-), lower case h on the first > and capital on the next two bothers me a bit. I'd prefer the > all-lowercase version with underscores if that's OK. Oh, I meant to suggest is_starts/continuesHumongous() with the first lower-case letters. The other states have a lower case initial letter too in combination with the is_-prefix. I do not mind about the version with the underscores though. Pushed the latest change through JPRT, looks good to me. Thanks, Thomas From John.Coomes at oracle.com Wed Sep 10 13:09:25 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 10 Sep 2014 06:09:25 -0700 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <540F774E.7000100@oracle.com> References: <21518.43663.788681.115837@mykonos.us.oracle.com> <540F774E.7000100@oracle.com> Message-ID: <21520.19845.227981.501952@mykonos.us.oracle.com> Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > Changes look good. > > Reviewed. Thank you. -John > On 09/09/2014 12:21 AM, John Coomes wrote: > > Hi, > > > > Please review this interface for copying allocation context statistics > > to native or java arrays. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ > > > > -John > From John.Coomes at oracle.com Wed Sep 10 13:34:23 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 10 Sep 2014 06:34:23 -0700 Subject: review request (S) - 8057824 methods to copy allocation context stats In-Reply-To: <1410336287.2681.12.camel@cirrus> References: <21518.43663.788681.115837@mykonos.us.oracle.com> <1410336287.2681.12.camel@cirrus> Message-ID: <21520.21343.925169.682094@mykonos.us.oracle.com> Thomas Schatzl (thomas.schatzl at oracle.com) wrote: > Hi, > > On Tue, 2014-09-09 at 00:21 -0700, John Coomes wrote: > > Hi, > > > > Please review this interface for copying allocation context statistics > > to native or java arrays. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057824-stats-copy/ > > > > some comments: > > - in the declarations of the copy_allocation_context_stats() methods > please put every parameter on a single line. Fixed. > - please give a description of the method, it seems to be non-obvious. I > assume that the passed "len" indicates the number of > contexts/totals/accuracies that are passed. I added this comment: // Copy the current allocation context statistics for the specified contexts. // For each context in contexts, set the corresponding entries in the totals // and accuracy arrays to the current values held by the statistics. Each // array should be of length len. virtual void copy_allocation_context_stats(const jint* contexts, jlong* totals, jbyte* accuracy, jint len) { } > - spaces before the "*", which is unusual Sure, fixed. Thanks for looking at it. -John From John.Coomes at oracle.com Wed Sep 10 17:15:58 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 10 Sep 2014 10:15:58 -0700 Subject: review request (S) - 8057818: collect allocation context stats In-Reply-To: <540F6499.6090900@oracle.com> References: <21518.42410.895682.408591@mykonos.us.oracle.com> <540F6499.6090900@oracle.com> Message-ID: <21520.34638.111269.552468@mykonos.us.oracle.com> Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > John, > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html > > For now or a later clean up. > > I'm used to having the accessor have a name more > similar to the field. I would suggest changing _alloc_ctx_stats > to _allocation_context_stats. > > + // Statistics for each allocation context > + AllocationContextStats _alloc_ctx_stats; > + > > + inline AllocationContextStats & allocation_context_stats(); Sure, I changed the field name. > Rest looks good modulo Mikael's comments. > > Reviewed. Thanks. -John > On 09/09/2014 12:00 AM, John Coomes wrote: > > Hi, > > > > Please review an interface for collecting allocation context > > statistics at g1 gc pauses: > > > > 8057818: collect allocation context statistics at gc pauses > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8057818-stats-collect/ > > > > -John > From andrey.x.zakharov at oracle.com Wed Sep 10 17:26:00 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Wed, 10 Sep 2014 21:26:00 +0400 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM Message-ID: <541089A8.5080604@oracle.com> Hi, team. Here is patch for existing test for G1 TestHumongousShrinkHeap.java. It just makes test respect available memory, and small code changes - renaming function. webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8056237 Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But according to https://bugs.openjdk.java.net/browse/JDK-8056043 its still fails with product bug. This fix only fixes OOMs on low boxes. Thanks. From jesper.wilhelmsson at oracle.com Wed Sep 10 18:01:31 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 10 Sep 2014 20:01:31 +0200 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM In-Reply-To: <541089A8.5080604@oracle.com> References: <541089A8.5080604@oracle.com> Message-ID: <541091FB.90506@oracle.com> Looks good. /Jesper Andrey Zakharov skrev 10/9/14 19:26: > Hi, team. > Here is patch for existing test for G1 TestHumongousShrinkHeap.java. > It just makes test respect available memory, and small code changes - renaming > function. > > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ > bug: > https://bugs.openjdk.java.net/browse/JDK-8056237 > > > Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But according to > https://bugs.openjdk.java.net/browse/JDK-8056043 its still fails with product bug. > This fix only fixes OOMs on low boxes. > > Thanks. > > From thomas.schatzl at oracle.com Wed Sep 10 18:24:40 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Sep 2014 20:24:40 +0200 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM In-Reply-To: <541089A8.5080604@oracle.com> References: <541089A8.5080604@oracle.com> Message-ID: <1410373480.4491.4.camel@cirrus> Hi, On Wed, 2014-09-10 at 21:26 +0400, Andrey Zakharov wrote: > Hi, team. > Here is patch for existing test for G1 TestHumongousShrinkHeap.java. > It just makes test respect available memory, and small code changes - > renaming function. this bug's number is missing in the @bugid line. Otherwise it looks good. > > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ > bug: > https://bugs.openjdk.java.net/browse/JDK-8056237 > > > Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But > according to https://bugs.openjdk.java.net/browse/JDK-8056043 its still > fails with product bug. > This fix only fixes OOMs on low boxes. The change has apparently not propagated outside of the hs-gc repo for the jdk 9 branch yet. I checked the change for JDK-8056043 locally again, it is good. Thanks, Thomas From jon.masamitsu at oracle.com Thu Sep 11 00:48:36 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 10 Sep 2014 17:48:36 -0700 Subject: Fix for JDK-8048556 (GCLocker issues): feedback and some testing please? In-Reply-To: <6134806.1jJxalvT0b@mgerdin03> References: <53FE8E90.7090508@twitter.com> <540484D7.6060303@oracle.com> <54063351.3080306@twitter.com> <6134806.1jJxalvT0b@mgerdin03> Message-ID: <5410F164.8020001@oracle.com> Tony, I've also run some GC locker type testing but (my bad) have not analyzed the results fully yet. Nothing looks amiss with your patch but, as I said, not done yet. Also, my apologies, but I won't be able to put more time on it for a bit. Jon On 9/9/2014 2:19 AM, Mikael Gerdin wrote: > Tony, > > On Tuesday 02 September 2014 17.14.57 Tony Printezis wrote: >> Mikael, >> >> Inline. >> >> On 9/1/14, 10:38 AM, Mikael Gerdin wrote: >>> Hi Tony, >>> >>> On 2014-08-28 04:06, Tony Printezis wrote: >>>> Hi all, >>>> >>>> I have a fix for the GCLocker causing unnecessary young GCs issue >>>> (JDK-8048556). Here's the webrev: >>>> >>>> http://cr.openjdk.java.net/~tonyp/8048556/webrev.0/ >>>> >>>> Any chance of a) getting some feedback on whether the fix is reasonable >>>> and b) getting it through some testing (I did as much testing as I could >>>> but you know how fragile the GCLocker is...)? >>> I've started some testing on this fix (JPRT, GC test suite). >> Thanks! > So far my testing looks good. > > It looks like G1CollectedHeap::collect(GCCause::Cause cause) also reads the > total_collections count and thus may trigger a superfluous evacuation pause. > Why didn't you want to pass a total_collections count to G1's variant? > > /Mikael > >>>> I didn't really want to change the CollectedHeap API. However, I can't >>>> work out another way to pass the two GC counts to the VM op without >>>> changes to the CollectedHeap. I could have expanded the collect() method >>>> to also accept the count arguments. However, I don't think collect() >>>> should really be used for the GCLocker GC and I feel that a separate >>>> method is appropriate here. >>> I agree that it's reasonable to have a separate collect_for_gc_locker. >> Definitely less confusing in the long term... >> >>>> I also ended up renaming an argument to a c'tor from _cause to cause, as >>>> the former should only be used for class members. Hope that's OK. >>> Yep, that's always bothered me. >> I aim to please. :-) >> >> Tony >> >>>> Thanks, >>>> >>>> Tony From jaroslav.bachorik at oracle.com Tue Sep 9 14:19:06 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 09 Sep 2014 16:19:06 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540EF2A6.5000805@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> <540EF2A6.5000805@oracle.com> Message-ID: <540F0C5A.20302@oracle.com> Thumbs up! -JB- On 09/09/2014 02:29 PM, Stefan Karlsson wrote: > Hi Jaroslav, > > Thanks a lot for looking at the test change. > > On 2014-09-09 14:04, Jaroslav Bachorik wrote: >> Hi Stefan, >> >> * test/java/lang/management/MemoryMXBean/LowMemoryTest.java >> L71 - `g1Flag` is not used anywhere; should it be removed? > > It should be used. I've updated the patch: > http://cr.openjdk.java.net/~stefank/8057174/webrev.02 > > and have restarted the test runs. > > thanks, > StefanK > >> >> Other than that the change looks fine. >> >> -JB- >> >> On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >>> (Adding GC) >>> >>> Hi, >>> >>> Could I get a couple of reviews for this test fix? >>> >>> StefanK >>> >>> On 2014-09-05 14:01, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Here's an updated version of the test: >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>>> >>>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>>> would happen). >>>> >>>> 2) Some flags/configurations could increase the young gen size because >>>> of alignment restrictions in the heap sizing policies. I've updated >>>> the test to make sure that we run >>>> a) with small G1 heap region sizes >>>> b) without large pages >>>> >>>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>>> risk that someone will add arbitrary GC command line options to the >>>> test. >>>> >>>> thanks, >>>> StefanK >>>> >>>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to make these tests a bit more stable. I've >>>>> changed the code to always allocate objects that are larger than the >>>>> young gen size. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>>> >>>>> I've tested this by running the tests through jprt. >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From daniel.fuchs at oracle.com Tue Sep 9 12:49:43 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 09 Sep 2014 14:49:43 +0200 Subject: RFR: 8057174: MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 In-Reply-To: <540EF2A6.5000805@oracle.com> References: <54087886.1090306@oracle.com> <5409A607.1020906@oracle.com> <540EE85B.9000003@oracle.com> <540EECC1.9070102@oracle.com> <540EF2A6.5000805@oracle.com> Message-ID: <540EF767.3040700@oracle.com> Hi, Looks good to me - although I'm not a specialist of -XX options ;-) -- daniel On 9/9/14 2:29 PM, Stefan Karlsson wrote: > Hi Jaroslav, > > Thanks a lot for looking at the test change. > > On 2014-09-09 14:04, Jaroslav Bachorik wrote: >> Hi Stefan, >> >> * test/java/lang/management/MemoryMXBean/LowMemoryTest.java >> L71 - `g1Flag` is not used anywhere; should it be removed? > > It should be used. I've updated the patch: > http://cr.openjdk.java.net/~stefank/8057174/webrev.02 > > and have restarted the test runs. > > thanks, > StefanK > >> >> Other than that the change looks fine. >> >> -JB- >> >> On 09/09/2014 01:45 PM, Stefan Karlsson wrote: >>> (Adding GC) >>> >>> Hi, >>> >>> Could I get a couple of reviews for this test fix? >>> >>> StefanK >>> >>> On 2014-09-05 14:01, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Here's an updated version of the test: >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01.delta/ >>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.01/ >>>> >>>> 1) The max == -1 check would unnecessarily fail the test (if it ever >>>> would happen). >>>> >>>> 2) Some flags/configurations could increase the young gen size because >>>> of alignment restrictions in the heap sizing policies. I've updated >>>> the test to make sure that we run >>>> a) with small G1 heap region sizes >>>> b) without large pages >>>> >>>> I had to remove the RunUtil.runTestKeepGcOpts targets to minimize the >>>> risk that someone will add arbitrary GC command line options to the >>>> test. >>>> >>>> thanks, >>>> StefanK >>>> >>>> On 2014-09-04 16:34, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to make these tests a bit more stable. I've >>>>> changed the code to always allocate objects that are larger than the >>>>> young gen size. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8057174/webrev.00/ >>>>> >>>>> I've tested this by running the tests through jprt. >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From Dmitry.Fazunenko at oracle.com Thu Sep 11 07:16:02 2014 From: Dmitry.Fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 11 Sep 2014 11:16:02 +0400 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM In-Reply-To: <541089A8.5080604@oracle.com> References: <541089A8.5080604@oracle.com> Message-ID: <54114C32.2010505@oracle.com> Hi Andrey, Looks good, some minor comments related to better var names 1) PAGE_SIZE --> REGION_SIZE (if you mean G1 heap reg size) 2) PAGES_NUM --> GROUP_NUM (you divide allocated objects in groups) 3) USED_MEMORY = Runtime.getRuntime().totalMemory() I guess you meant FREE_MEMORY = Runtime.getRuntime().freeMemory() Thanks, Dima On 10.09.2014 21:26, Andrey Zakharov wrote: > Hi, team. > Here is patch for existing test for G1 TestHumongousShrinkHeap.java. > It just makes test respect available memory, and small code changes - > renaming function. > > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ > bug: > https://bugs.openjdk.java.net/browse/JDK-8056237 > > > Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But > according to https://bugs.openjdk.java.net/browse/JDK-8056043 its > still fails with product bug. > This fix only fixes OOMs on low boxes. > > Thanks. > > From thomas.schatzl at oracle.com Thu Sep 11 09:29:15 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Sep 2014 11:29:15 +0200 Subject: RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap In-Reply-To: <54074057.10707@oracle.com> References: <5374A502.5030409@oracle.com> <53835E9B.7080102@oracle.com> <538F2FEF.30105@oracle.com> <54059844.50202@oracle.com> <1409659469.2665.43.camel@cirrus> <54074057.10707@oracle.com> Message-ID: <1410427755.2692.8.camel@cirrus> Hi, On Wed, 2014-09-03 at 20:22 +0400, Andrey Zakharov wrote: > Hi, all. > > I've reduced memory footprint for test. > Now its passed good (577908.ute.hs_jtreg.accept.full) > > webrev: > http://cr.openjdk.java.net/~jwilhelm/8041946/webrev.02/ > not sure if there is still need for a review, but it is good now. Thanks for the change. Thomas From andrey.x.zakharov at oracle.com Thu Sep 11 09:37:00 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 11 Sep 2014 13:37:00 +0400 Subject: RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap In-Reply-To: <1410427755.2692.8.camel@cirrus> References: <5374A502.5030409@oracle.com> <53835E9B.7080102@oracle.com> <538F2FEF.30105@oracle.com> <54059844.50202@oracle.com> <1409659469.2665.43.camel@cirrus> <54074057.10707@oracle.com> <1410427755.2692.8.camel@cirrus> Message-ID: <54116D3C.2050303@oracle.com> Thanks, Thomas. For sure we need reviews as much as possible. BTW, can we go now with this patch? Jesper, could you please be a sponsor for this patch? Thanks. On 11.09.2014 13:29, Thomas Schatzl wrote: > Hi, > > On Wed, 2014-09-03 at 20:22 +0400, Andrey Zakharov wrote: >> Hi, all. >> >> I've reduced memory footprint for test. >> Now its passed good (577908.ute.hs_jtreg.accept.full) >> >> webrev: >> http://cr.openjdk.java.net/~jwilhelm/8041946/webrev.02/ >> > not sure if there is still need for a review, but it is good now. > Thanks for the change. > > Thomas > > From andrey.x.zakharov at oracle.com Thu Sep 11 11:00:53 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 11 Sep 2014 15:00:53 +0400 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM In-Reply-To: <54114C32.2010505@oracle.com> References: <541089A8.5080604@oracle.com> <54114C32.2010505@oracle.com> Message-ID: <541180E5.3050006@oracle.com> Changed according comments webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.01/ Thanks. On 11.09.2014 11:16, Dmitry Fazunenko wrote: > Hi Andrey, > > Looks good, some minor comments related to better var names > > 1) PAGE_SIZE --> REGION_SIZE (if you mean G1 heap reg size) > 2) PAGES_NUM --> GROUP_NUM (you divide allocated objects in groups) > 3) > USED_MEMORY = Runtime.getRuntime().totalMemory() > I guess you meant > FREE_MEMORY = Runtime.getRuntime().freeMemory() > > Thanks, > Dima > > On 10.09.2014 21:26, Andrey Zakharov wrote: >> Hi, team. >> Here is patch for existing test for G1 TestHumongousShrinkHeap.java. >> It just makes test respect available memory, and small code changes - >> renaming function. >> >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8056237 >> >> >> Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But >> according to https://bugs.openjdk.java.net/browse/JDK-8056043 its >> still fails with product bug. >> This fix only fixes OOMs on low boxes. >> >> Thanks. >> >> > From thomas.schatzl at oracle.com Thu Sep 11 11:24:07 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Sep 2014 13:24:07 +0200 Subject: rounding error in logs In-Reply-To: <0422A05F-8858-4C9F-9882-4793CB3E189F@kodewerk.com> References: <0422A05F-8858-4C9F-9882-4793CB3E189F@kodewerk.com> Message-ID: <1410434647.2692.40.camel@cirrus> Hi Kirk, On Mon, 2014-09-08 at 11:28 +0200, Kirk Pepperdine wrote: > Hi, > > I?ve got this from a 1.8.0_20 log but it?s been around for some time. > > [Eden: 448.0M(448.0M)->0.0B(448.0M) Survivors: 64.0M->64.0M Heap: > 7740.7M(15.0G)->7334.2M(15.0G)] > 15116.779: [GC cleanup 7334M->6817M(15G), 0.0181473 secs] > > As you can see the occupancy before collection is reported as 7334M > where as the occupancy after collection in the summary record is > 7334.2M. While it reads 7740M as initial heap occupancy here, I created a CR "JDK-8058221 - Rounding in log output makes evaluation difficult" as this is something that is something that regularly poses an issue. Please comment if the CR is appropriate. Thanks, Thomas From dmitry.fazunenko at oracle.com Thu Sep 11 12:10:56 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 11 Sep 2014 16:10:56 +0400 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM In-Reply-To: <541180E5.3050006@oracle.com> References: <541089A8.5080604@oracle.com> <54114C32.2010505@oracle.com> <541180E5.3050006@oracle.com> Message-ID: <54119150.8010902@oracle.com> Looks good to me. On 11.09.2014 15:00, Andrey Zakharov wrote: > Changed according comments > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.01/ > > Thanks. > > On 11.09.2014 11:16, Dmitry Fazunenko wrote: >> Hi Andrey, >> >> Looks good, some minor comments related to better var names >> >> 1) PAGE_SIZE --> REGION_SIZE (if you mean G1 heap reg size) >> 2) PAGES_NUM --> GROUP_NUM (you divide allocated objects in groups) >> 3) >> USED_MEMORY = Runtime.getRuntime().totalMemory() >> I guess you meant >> FREE_MEMORY = Runtime.getRuntime().freeMemory() >> >> Thanks, >> Dima >> >> On 10.09.2014 21:26, Andrey Zakharov wrote: >>> Hi, team. >>> Here is patch for existing test for G1 TestHumongousShrinkHeap.java. >>> It just makes test respect available memory, and small code changes >>> - renaming function. >>> >>> webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8056237 >>> >>> >>> Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But >>> according to https://bugs.openjdk.java.net/browse/JDK-8056043 its >>> still fails with product bug. >>> This fix only fixes OOMs on low boxes. >>> >>> Thanks. >>> >>> >> > From jesper.wilhelmsson at oracle.com Thu Sep 11 12:16:31 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Sep 2014 14:16:31 +0200 Subject: RFR: JDK-8056237 [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM In-Reply-To: <54119150.8010902@oracle.com> References: <541089A8.5080604@oracle.com> <54114C32.2010505@oracle.com> <541180E5.3050006@oracle.com> <54119150.8010902@oracle.com> Message-ID: <5411929F.1000803@oracle.com> I'm fine with these changes, and I talked to Thomas and he also approves. Ship it! .. oh right, I'll ship it. ;) /Jesper Dmitry Fazunenko skrev 11/9/14 14:10: > Looks good to me. > > On 11.09.2014 15:00, Andrey Zakharov wrote: >> Changed according comments >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.01/ >> >> Thanks. >> >> On 11.09.2014 11:16, Dmitry Fazunenko wrote: >>> Hi Andrey, >>> >>> Looks good, some minor comments related to better var names >>> >>> 1) PAGE_SIZE --> REGION_SIZE (if you mean G1 heap reg size) >>> 2) PAGES_NUM --> GROUP_NUM (you divide allocated objects in groups) >>> 3) >>> USED_MEMORY = Runtime.getRuntime().totalMemory() >>> I guess you meant >>> FREE_MEMORY = Runtime.getRuntime().freeMemory() >>> >>> Thanks, >>> Dima >>> >>> On 10.09.2014 21:26, Andrey Zakharov wrote: >>>> Hi, team. >>>> Here is patch for existing test for G1 TestHumongousShrinkHeap.java. >>>> It just makes test respect available memory, and small code changes - >>>> renaming function. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8056237/webrev.00/ >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8056237 >>>> >>>> >>>> Testing in aurora started as 582911.ute.hs_jtreg.accept.full . But according >>>> to https://bugs.openjdk.java.net/browse/JDK-8056043 its still fails with >>>> product bug. >>>> This fix only fixes OOMs on low boxes. >>>> >>>> Thanks. >>>> >>>> >>> >> > From erik.helin at oracle.com Thu Sep 11 14:15:25 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 11 Sep 2014 16:15:25 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size Message-ID: <5411AE7D.10005@oracle.com> Hi all, this small patch fixes a problem with the arguments to the syscall memcntl on Solaris. When memcntl is used with MHA_MAPSIZE_VA to tell the system the preferred page size for a memory area, the mha_pagesize member of the struct memcntl_mha argument must be a valid page size (a valid page size if one of the sizes returned by the syscall getpagesizes). One variant of the function os::commit_memory has an alignment_hint parameter and the code in os::Solaris::commit_memory_impl sometimes passes this alignment_hint as the mha_pagesize to memcntl. The issue is that there is no check that this alignment_hint actually is a valid page size. This patch selects the largest page size that divides the alignment_hint (the _page_sizes array is sorted in descending order). I also added a bunch of asserts to check preconditions. Bug: https://bugs.openjdk.java.net/browse/JDK-8049536 Webrev: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00/ Testing: - JPRT - Tested with the patch for https://bugs.openjdk.java.net/browse/JDK-8027915 which immediately provokes the bug on Solaris SPARC when just running java -version. Now it works fine. Thanks, Erik From thomas.schatzl at oracle.com Thu Sep 11 15:23:41 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Sep 2014 17:23:41 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5411AE7D.10005@oracle.com> References: <5411AE7D.10005@oracle.com> Message-ID: <1410449021.6124.5.camel@cirrus> Hi, On Thu, 2014-09-11 at 16:15 +0200, Erik Helin wrote: > Hi all, > > this small patch fixes a problem with the arguments to the syscall > memcntl on Solaris. > > When memcntl is used with MHA_MAPSIZE_VA to tell the system the > preferred page size for a memory area, the mha_pagesize member of the > struct memcntl_mha argument must be a valid page size (a valid page size > if one of the sizes returned by the syscall getpagesizes). > > One variant of the function os::commit_memory has an alignment_hint > parameter and the code in os::Solaris::commit_memory_impl sometimes > passes this alignment_hint as the mha_pagesize to memcntl. The issue is > that there is no check that this alignment_hint actually is a valid page > size. > Where does this wrong alignment come from? Only from the user via -XX:LargePageAlignmentInBytes? If so, wouldn't it be better to make this adjustment during argument processing? Then the VM could inform the user about the change to some degree, either per message, or by overriding the given value (using FLAG_SET_xxx). The alignment_hint should still be checked for validity when it is used, but I think if the method gets a wrong value for the hint from anywhere other than the user, it imo should be an error. Not silently adjusted which potentially leads to hard to find performance problems. > Testing: > - JPRT > - Tested with the patch for > https://bugs.openjdk.java.net/browse/JDK-8027915 > which immediately provokes the bug on Solaris SPARC when just running > java -version. Now it works fine. Can you add a test case that checks there is no "MPSS failed" message with various LargePageAlignmentInBytes values? Thanks, Thomas From John.Coomes at oracle.com Thu Sep 11 15:39:08 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 11 Sep 2014 08:39:08 -0700 Subject: review request (XS) - 8058235: identify GCs for allocation context stats Message-ID: <21521.49692.840963.341977@mykonos.us.oracle.com> Hi all, Please review this very simple change to add a new GCCause to identify GCs initiated to update allocation context statistics. http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058235-gc-cause/ -John From mikael.gerdin at oracle.com Thu Sep 11 15:51:19 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 11 Sep 2014 17:51:19 +0200 Subject: review request (XS) - 8058235: identify GCs for allocation context stats In-Reply-To: <21521.49692.840963.341977@mykonos.us.oracle.com> References: <21521.49692.840963.341977@mykonos.us.oracle.com> Message-ID: <2334589.XHRtUtyRjj@mgerdin03> Hi John, On Thursday 11 September 2014 08.39.08 John Coomes wrote: > Hi all, > > Please review this very simple change to add a new GCCause to identify > GCs initiated to update allocation context statistics. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058235-gc-cause/ Thanks for adding this. Looks good. /Mikael > > -John From stefan.johansson at oracle.com Thu Sep 11 15:59:07 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 11 Sep 2014 17:59:07 +0200 Subject: review request (XS) - 8058235: identify GCs for allocation context stats In-Reply-To: <21521.49692.840963.341977@mykonos.us.oracle.com> References: <21521.49692.840963.341977@mykonos.us.oracle.com> Message-ID: <5411C6CB.2090402@oracle.com> Looks good. Thanks, Stefan On 2014-09-11 17:39, John Coomes wrote: > Hi all, > > Please review this very simple change to add a new GCCause to identify > GCs initiated to update allocation context statistics. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058235-gc-cause/ > > -John From erik.helin at oracle.com Thu Sep 11 16:47:04 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 11 Sep 2014 18:47:04 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <1410449021.6124.5.camel@cirrus> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> Message-ID: <5411D208.30001@oracle.com> Hi Thomas, thanks for having a look! On 2014-09-11 17:23, Thomas Schatzl wrote: > > Hi, > > On Thu, 2014-09-11 at 16:15 +0200, Erik Helin wrote: >> Hi all, >> >> this small patch fixes a problem with the arguments to the syscall >> memcntl on Solaris. >> >> When memcntl is used with MHA_MAPSIZE_VA to tell the system the >> preferred page size for a memory area, the mha_pagesize member of the >> struct memcntl_mha argument must be a valid page size (a valid page size >> if one of the sizes returned by the syscall getpagesizes). >> >> One variant of the function os::commit_memory has an alignment_hint >> parameter and the code in os::Solaris::commit_memory_impl sometimes >> passes this alignment_hint as the mha_pagesize to memcntl. The issue is >> that there is no check that this alignment_hint actually is a valid page >> size. >> > > Where does this wrong alignment come from? Only from the user via > -XX:LargePageAlignmentInBytes? No, the alignment hint comes from CollectorPolicy::generation_alignment(), which is passed to the parallel scavenge code as the generation alignment when setting up the heap. On 2014-09-11 17:23, Thomas Schatzl wrote: > If so, wouldn't it be better to make this adjustment during argument > processing? Then the VM could inform the user about the change to some > degree, either per message, or by overriding the given value > (using FLAG_SET_xxx). > > The alignment_hint should still be checked for validity when it is > used, but I think if the method gets a wrong value for the hint from > anywhere other than the user, it imo should be an error. Not silently > adjusted which potentially leads to hard to find performance problems. As we discussed on IM, it seems like the alignment_hint is meant to be used like a hint, and then the OS specific code can decide the page size that is most suitable. In os_linux.cpp for example, the alignment_hint is only used for checking if the caller might want to use large pages (not the actual page size). BSD and Windows ignores the hint. In the Solaris code today, the page size is adjusted if the alignment_hint is larger than the largest page size, otherwise the alignment_hint is treated an exact page size. I've added a comment to the code explaining that memcntl requires an exact page. Please see new webrevs: - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01/ - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00-01/ On 2014-09-11 17:23, Thomas Schatzl wrote: >> Testing: >> - JPRT >> - Tested with the patch for >> https://bugs.openjdk.java.net/browse/JDK-8027915 >> which immediately provokes the bug on Solaris SPARC when just running >> java -version. Now it works fine. > > Can you add a test case that checks there is no "MPSS failed" message with > various LargePageAlignmentInBytes values? Sure, although I no longer managed to reproduce the bug with only java -Xms32m -Xmx128m -XX:LargePageSizeInBytes=256m -version Let me see if I can come up with some flags that provokes the bug even without my fix for JDK-8027915. Thanks, Erik > Thanks, > Thomas > > From erik.helin at oracle.com Thu Sep 11 16:55:11 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 11 Sep 2014 18:55:11 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5411AE7D.10005@oracle.com> References: <5411AE7D.10005@oracle.com> Message-ID: <5411D3EF.3030906@oracle.com> All, based on feedback offline from Stefan Karlsson I've updated the patch: - The third assert in setup_large_pages can be: is_size_aligned(bytes, align) since if `start` is aligned to `align` and `bytes` is aligned to `align`, then `start` + `bytes` is also aligned to `align`. This also means the debug_only statement could be removed. - Since caddr_t is a pointer type (char* on Solaris) it can be casted to void* and then the second assert in setup_large_pages can use is_ptr_aligned. - The if statement in os::Solaris::commit_memory_impl should also guard against alignment_hint being zero, since the existing check assures this. Please see new webrevs: - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01/ - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00-01/ Thank you StefanK for the feedback! Erik On 2014-09-11 16:15, Erik Helin wrote: > Hi all, > > this small patch fixes a problem with the arguments to the syscall > memcntl on Solaris. > > When memcntl is used with MHA_MAPSIZE_VA to tell the system the > preferred page size for a memory area, the mha_pagesize member of the > struct memcntl_mha argument must be a valid page size (a valid page size > if one of the sizes returned by the syscall getpagesizes). > > One variant of the function os::commit_memory has an alignment_hint > parameter and the code in os::Solaris::commit_memory_impl sometimes > passes this alignment_hint as the mha_pagesize to memcntl. The issue is > that there is no check that this alignment_hint actually is a valid page > size. > > This patch selects the largest page size that divides the alignment_hint > (the _page_sizes array is sorted in descending order). I also added a > bunch of asserts to check preconditions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049536 > > Webrev: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00/ > > Testing: > - JPRT > - Tested with the patch for > https://bugs.openjdk.java.net/browse/JDK-8027915 > which immediately provokes the bug on Solaris SPARC when just running > java -version. Now it works fine. > > Thanks, > Erik From John.Coomes at oracle.com Thu Sep 11 18:41:53 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 11 Sep 2014 11:41:53 -0700 Subject: review request (XS) - 8058235: identify GCs for allocation context stats In-Reply-To: <2334589.XHRtUtyRjj@mgerdin03> References: <21521.49692.840963.341977@mykonos.us.oracle.com> <2334589.XHRtUtyRjj@mgerdin03> Message-ID: <21521.60657.795639.596791@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > Hi John, > > On Thursday 11 September 2014 08.39.08 John Coomes wrote: > > Hi all, > > > > Please review this very simple change to add a new GCCause to identify > > GCs initiated to update allocation context statistics. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058235-gc-cause/ > > Thanks for adding this. > Looks good. Thanks for the review! -John From John.Coomes at oracle.com Thu Sep 11 18:42:30 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 11 Sep 2014 11:42:30 -0700 Subject: review request (XS) - 8058235: identify GCs for allocation context stats In-Reply-To: <5411C6CB.2090402@oracle.com> References: <21521.49692.840963.341977@mykonos.us.oracle.com> <5411C6CB.2090402@oracle.com> Message-ID: <21521.60694.269814.671133@mykonos.us.oracle.com> Stefan Johansson (stefan.johansson at oracle.com) wrote: > Looks good. Thanks! -John > On 2014-09-11 17:39, John Coomes wrote: > > Hi all, > > > > Please review this very simple change to add a new GCCause to identify > > GCs initiated to update allocation context statistics. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058235-gc-cause/ > > > > -John > From kirk at kodewerk.com Thu Sep 11 22:12:44 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 12 Sep 2014 00:12:44 +0200 Subject: rounding error in logs In-Reply-To: <1410434647.2692.40.camel@cirrus> References: <0422A05F-8858-4C9F-9882-4793CB3E189F@kodewerk.com> <1410434647.2692.40.camel@cirrus> Message-ID: <39F6B3FC-28D9-4186-91A2-5421A7E108D5@kodewerk.com> Hi Thomas, Thanks for this. I don?t see CR JDK-8058221 showing up so it?s difficult to comment. What you?ve mentioned is ok but I think it would be nice is the logs used the same formatting string. BTW, my comment on reporting in bytes still stands.. it would eliminate the need for any formatting! Just print longs ;-) Regards, Kirk On Sep 11, 2014, at 1:24 PM, Thomas Schatzl wrote: > Hi Kirk, > > On Mon, 2014-09-08 at 11:28 +0200, Kirk Pepperdine wrote: >> Hi, >> >> I?ve got this from a 1.8.0_20 log but it?s been around for some time. >> >> [Eden: 448.0M(448.0M)->0.0B(448.0M) Survivors: 64.0M->64.0M Heap: >> 7740.7M(15.0G)->7334.2M(15.0G)] >> 15116.779: [GC cleanup 7334M->6817M(15G), 0.0181473 secs] >> >> As you can see the occupancy before collection is reported as 7334M >> where as the occupancy after collection in the summary record is >> 7334.2M. > > While it reads 7740M as initial heap occupancy here, I created a CR > "JDK-8058221 - Rounding in log output makes evaluation difficult" as > this is something that is something that regularly poses an issue. > > Please comment if the CR is appropriate. > > Thanks, > Thomas > > > -------------- 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 Fri Sep 12 07:23:59 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 12 Sep 2014 09:23:59 +0200 Subject: rounding error in logs In-Reply-To: <39F6B3FC-28D9-4186-91A2-5421A7E108D5@kodewerk.com> References: <0422A05F-8858-4C9F-9882-4793CB3E189F@kodewerk.com> <1410434647.2692.40.camel@cirrus> <39F6B3FC-28D9-4186-91A2-5421A7E108D5@kodewerk.com> Message-ID: <1410506639.3705.0.camel@cirrus> Hi, On Fri, 2014-09-12 at 00:12 +0200, Kirk Pepperdine wrote: > Hi Thomas, > > Thanks for this. I don?t see CR JDK-8058221 showing up so it?s difficult to comment. What you?ve mentioned is ok but I think it would be nice is the logs used the same formatting string. > > BTW, my comment on reporting in bytes still stands.. it would eliminate the need for any formatting! Just print longs ;-) > the bug is publicly available so I do not know why it is not accessible for you. Here's the description: "In the gc, heap sizes are typically rounded to some (rather abritrary) k/M/G values for better human consumption. This introduces subtle rounding problems when calculating values from it (like number of promoted bytes being negative for no reason) Add an option to allow the size format output to always be written in bytes. This feature may also be automatically enabled by other options like G1LogLevel=finest. " Thanks, Thomas From kirk at kodewerk.com Fri Sep 12 08:32:45 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 12 Sep 2014 10:32:45 +0200 Subject: rounding error in logs In-Reply-To: <1410506639.3705.0.camel@cirrus> References: <0422A05F-8858-4C9F-9882-4793CB3E189F@kodewerk.com> <1410434647.2692.40.camel@cirrus> <39F6B3FC-28D9-4186-91A2-5421A7E108D5@kodewerk.com> <1410506639.3705.0.camel@cirrus> Message-ID: <62E74557-B7DD-4491-A8BF-9CE0C8070E5A@kodewerk.com> Hi Thomas, Indeed? strange but I can see it this morning... but it?s not possible for me to comment on it. Ok, I agree, not a fantastically high priority item but that would be my comment if I were able to comment. The problem of the subtle rounding error is due to the fact that log records, instead of sharing common formats, define their own. So while one set of records share EXT_SIZE_FORMAT (g1CollectorPolicy.cpp:#define EXT_SIZE_FORMAT ?%.1f%s? other records use a completely separate integer definition. In my experience most people use either Censum or one of the OSS tools or a home grown tool to look at these logs which implies that human readability is less important. And if humans want values to be rounded a flag like -XX:PrintMemoryRounding=[G,M,K,B] could be introduced. I?m not a fan of G1LogLevel=finest as this turns on bags of stuff that may or may not be relevant to the problem at hand and increases the complexity of parsing the log files. This is especially true in light of the corruption that often occurs in both CMS and G1 logs that can be difficult to untangle. Format isn?t typically that much of a problem for the home grown folks as they only deal with 1 log format, theirs. If it changes when they change JVM they can simply change their parser. However this is very painful for the few of us that actually try to maintain tools that work across all versions and support a variety of flag collector and flag combinations. As you can probably imagine, that this rounding error exists means that it needs to be compensated for in the tooling for as long as these versions of the JVM are in play again. Kind regards, Kirk Pepperdine On Sep 12, 2014, at 9:23 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-12 at 00:12 +0200, Kirk Pepperdine wrote: >> Hi Thomas, >> >> Thanks for this. I don?t see CR JDK-8058221 showing up so it?s difficult to comment. What you?ve mentioned is ok but I think it would be nice is the logs used the same formatting string. >> >> BTW, my comment on reporting in bytes still stands.. it would eliminate the need for any formatting! Just print longs ;-) >> > > the bug is publicly available so I do not know why it is not accessible > for you. > > Here's the description: > > "In the gc, heap sizes are typically rounded to some (rather abritrary) > k/M/G values for better human consumption. > > This introduces subtle rounding problems when calculating values from it > (like number of promoted bytes being negative for no reason) > > Add an option to allow the size format output to always be written in > bytes. > > This feature may also be automatically enabled by other options like > G1LogLevel=finest. " > > Thanks, > Thomas > > -------------- 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 marcus.larsson at oracle.com Fri Sep 12 12:05:24 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 12 Sep 2014 14:05:24 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over Message-ID: <5412E184.70700@oracle.com> Hi, I would like reviews for the following refactorization to separate the heap region claiming from the actual heap region data structure. This allows concurrent tasks to claim heap regions independent of each other. The patch adds a HeapRegionClaimer that should be used for parallel iteration over heap regions, and will handle the claims for a certain task. The previous claim field and its associated functions in HeapRegion is removed. Webrev: http://cr.openjdk.java.net/~brutisso/webrev-8058298/ Bug: https://bugs.openjdk.java.net/browse/JDK-8058298 Testing: jprt local UTE vm.gc.testlist SPECjbb2013 Thanks, Marcus From bengt.rutisson at oracle.com Fri Sep 12 12:20:32 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 12 Sep 2014 14:20:32 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <540FA374.3040401@twitter.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540FA374.3040401@twitter.com> Message-ID: <5412E510.3020802@oracle.com> Hi Tony, Nice cleanup! I like it! On 2014-09-10 03:03, Tony Printezis wrote: > Latest webrev which I think includes all that we discussed: > > http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.1/ This webrev looks good. A few minor comments below. Thanks, Bengt heapRegionType.hpp 30 #define hrt_assert_is_valid(__tag__) \ 31 do { \ 32 assert(is_valid((__tag__)), \ 33 err_msg("invalid HR type: %u", (uint) (__tag__))); \ 34 } while (0) I don't think we normally use "__" for parameters to macros, so I would prefer "__tag__" to be called just "tag". The way the macro is being used I don't see any need for the do {} while loop. g1CollectedHeap.cpp 1243 } else if (hr->is_old()) { 1244 _hr_printer->post_compaction(hr, G1HRPrinter::ContinuesHumongous); This looks wrong. Shouldn't we be printing G1HRPrinter::Old ? In TearDownRegionSetsClosure this comment confuses me: 6702 } else if (r->is_old()) { 6703 // Add it to the old set. 6704 _old_set->remove(r); The comment says "add", but we do "remove". The old comment "// The rest should be old" wasn't great but makes a little sense. We assume at this point that all regions are old and thus should be removed from the old set since we are tearing down all old region. I would propose to remove the comment all together now that we explicitly identify old regions instead. Or possibly revert back to the old behavior with a simple else case and then assert that the region is old. > > Tony > > On 9/9/14, 5:23 PM, Thomas Schatzl wrote: >> Hi, >> >> On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: >>> Thomas, >>> >>> Thanks for looking at this. Inline. >>> >>> On 9/9/14, 7:59 AM, Thomas Schatzl wrote: >>>> - while we are at touching this code I would appreciate if the >>>> method >>>> names for isHumongous(), startsHumongous() and continuesHumongous() in >>>> the HeapRegion class would be changed to fit the others as well. I.e. >>>> is_humongous(), is_startsHu.., is_contin...(). >>>> >>>> That could probably done in an extra CR as it adds lots of noise. >>> How about this: I never liked the lower camel case in the *Humongous() >>> methods on HeapRegion and I'd like to rename them to is_humongous(), >>> is_starts_humongous(), is_continues_humongous(). However, as you >>> pointed >>> out that'd be a big noisy change (there are 100+ instances of those >>> methods in the G1 codebase). So, how about I leave the methods on >>> HeapRegionType as we'd like them to be and rename the rest as a >>> follow-up change (and I'll be happy to work on that once this goes in)? >>> Sounds reasonable? >> Yes, let's leave the rename out for now. >> >> I quickly thought about the naming, the state names were StartsHumongous >> and ContinuesHumongous, so similar to the others, I would somewhat >> slightly prefer to keep them together (i.e. is_) and not add >> underscores to break the two words of the state name. Not really against >> the proposed naming though (adding the underscore). >> >> What I would really like to avoid is to have different order of the >> words in the state name: right now the change uses >> is_continues_humongous() in HeapRegion but is_humongous_cont() in >> HeapRegionType. That seems to be unnecessary. >> >> My suggestion is to use the same name in HeapRegionType and HeapRegion. >> >> (Btw, the change should also remove the HumongousType enum in >> heapRegion.hpp) >> >>>> - in HeapRegion::hr_clear(), instead of removing the assert, its >>>> condition could be changed to !is_humongous(). >>> Actually, this doesn't hold any more, which is why I removed the >>> assert. >>> Note that clear_humongous() I doesn't change the type of the region any >>> more, as I removed: >>> >>> _humongous_type = NotHumongous; >>> >>> The type is set to free in hr_clear() (which is called immediately >>> after >>> clear_humongous()) (same reason I removed the same assert from >>> g1HotCardCache.cpp BTW). I could set the type to free in >>> clear_humongous() too and re-add the assert but I don't think it >>> matters. The main requirement is that these two fields should be >>> cleared >>> in clear_humongous(): >>> >>> assert(_humongous_start_region == NULL, >>> "we should have already filtered out humongous regions"); >>> assert(_end == _orig_end, >>> "we should have already filtered out humongous regions"); >>> >> Okay. >> >>>> - I do not think we need the #if INCLUDE_ALL_GCS here or in any >>>> heapRegion* file. We can clean that up later. >>> OK. >> Actually I think I already fixed that in the change I gave you. >> >>>> - the encoding table for the Tag should probably be moved to the >>>> enum. Further it would be nice to write an introductory sentence what >>>> this table is about and why. >>> OK. (And yes I'll expand the comment on the tags a bit) >>> >>> One more thing I should have made clear: given that I now use >>> HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in >>> G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the >>> ad-hoc code that was there, the output of both (and there's a fair >>> amount of output that relies on the former) is going to change. Is that >>> a problem? I could make sure the output remains the same (by adding >>> more >>> get_*_str() methods). I personally don't think it's worth it. >> Need to look at that again, but I would somewhat prefer to keep the >> short names, e.g. HC/HS in that output. >> >> A get_short_str() method isn't be that hard to add. >> >>>> I put up a webrev with some of the suggested changes at >>>> http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ >>> Thanks for making the changes. I'll send an update based on your patch >>> (and once we agree on some of the issues I mentioned above). >> Thanks, >> Thomas >> >> > From erik.helin at oracle.com Fri Sep 12 12:52:48 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 12 Sep 2014 14:52:48 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5411D208.30001@oracle.com> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> Message-ID: <5412ECA0.4060202@oracle.com> Hi, I've uploaded a new patch that also contains a test: - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02/ - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01-02/ The test only provokes the bug together with the patch for JDK-8027915 and without this patch. Since we don't want to break nightly testing, it is better to push this patch first and then push the patch for JDK-8027915 (even though the test isn't that meaningful in this patch). Thanks, Erik On 2014-09-11 18:47, Erik Helin wrote: > Hi Thomas, > > thanks for having a look! > > On 2014-09-11 17:23, Thomas Schatzl wrote: >> >> Hi, >> >> On Thu, 2014-09-11 at 16:15 +0200, Erik Helin wrote: >>> Hi all, >>> >>> this small patch fixes a problem with the arguments to the syscall >>> memcntl on Solaris. >>> >>> When memcntl is used with MHA_MAPSIZE_VA to tell the system the >>> preferred page size for a memory area, the mha_pagesize member of the >>> struct memcntl_mha argument must be a valid page size (a valid page size >>> if one of the sizes returned by the syscall getpagesizes). >>> >>> One variant of the function os::commit_memory has an alignment_hint >>> parameter and the code in os::Solaris::commit_memory_impl sometimes >>> passes this alignment_hint as the mha_pagesize to memcntl. The issue is >>> that there is no check that this alignment_hint actually is a valid page >>> size. >>> >> >> Where does this wrong alignment come from? Only from the user via >> -XX:LargePageAlignmentInBytes? > > No, the alignment hint comes from > CollectorPolicy::generation_alignment(), which is passed to the parallel > scavenge code as the generation alignment when setting up the heap. > > On 2014-09-11 17:23, Thomas Schatzl wrote: >> If so, wouldn't it be better to make this adjustment during argument >> processing? Then the VM could inform the user about the change to some >> degree, either per message, or by overriding the given value >> (using FLAG_SET_xxx). >> >> The alignment_hint should still be checked for validity when it is >> used, but I think if the method gets a wrong value for the hint from >> anywhere other than the user, it imo should be an error. Not silently >> adjusted which potentially leads to hard to find performance problems. > > As we discussed on IM, it seems like the alignment_hint is meant to be > used like a hint, and then the OS specific code can decide the page size > that is most suitable. In os_linux.cpp for example, the alignment_hint > is only used for checking if the caller might want to use large pages > (not the actual page size). BSD and Windows ignores the hint. > > In the Solaris code today, the page size is adjusted if the > alignment_hint is larger than the largest page size, otherwise the > alignment_hint is treated an exact page size. > > I've added a comment to the code explaining that memcntl requires an > exact page. > > Please see new webrevs: > - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01/ > - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00-01/ > > On 2014-09-11 17:23, Thomas Schatzl wrote: >>> Testing: >>> - JPRT >>> - Tested with the patch for >>> https://bugs.openjdk.java.net/browse/JDK-8027915 >>> which immediately provokes the bug on Solaris SPARC when just >>> running >>> java -version. Now it works fine. >> >> Can you add a test case that checks there is no "MPSS failed" message >> with >> various LargePageAlignmentInBytes values? > > Sure, although I no longer managed to reproduce the bug with only > java -Xms32m -Xmx128m -XX:LargePageSizeInBytes=256m -version > > Let me see if I can come up with some flags that provokes the bug even > without my fix for JDK-8027915. > > Thanks, > Erik > >> Thanks, >> Thomas >> >> From erik.helin at oracle.com Fri Sep 12 13:08:50 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 12 Sep 2014 15:08:50 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5412ECA0.4060202@oracle.com> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> <5412ECA0.4060202@oracle.com> Message-ID: <5412F062.8060004@oracle.com> All, quick feedback from StefanK: - forgot to cast vm_page_size() to size_t in one place - print caddr_t with PRT_FORMAT in error message Webrevs: - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.03/ - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02-03/ Thanks, Erik On 2014-09-12 14:52, Erik Helin wrote: > Hi, > > I've uploaded a new patch that also contains a test: > - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02/ > - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01-02/ > > The test only provokes the bug together with the patch for JDK-8027915 > and without this patch. Since we don't want to break nightly testing, it > is better to push this patch first and then push the patch for > JDK-8027915 (even though the test isn't that meaningful in this patch). > > Thanks, > Erik > > On 2014-09-11 18:47, Erik Helin wrote: >> Hi Thomas, >> >> thanks for having a look! >> >> On 2014-09-11 17:23, Thomas Schatzl wrote: >>> >>> Hi, >>> >>> On Thu, 2014-09-11 at 16:15 +0200, Erik Helin wrote: >>>> Hi all, >>>> >>>> this small patch fixes a problem with the arguments to the syscall >>>> memcntl on Solaris. >>>> >>>> When memcntl is used with MHA_MAPSIZE_VA to tell the system the >>>> preferred page size for a memory area, the mha_pagesize member of the >>>> struct memcntl_mha argument must be a valid page size (a valid page >>>> size >>>> if one of the sizes returned by the syscall getpagesizes). >>>> >>>> One variant of the function os::commit_memory has an alignment_hint >>>> parameter and the code in os::Solaris::commit_memory_impl sometimes >>>> passes this alignment_hint as the mha_pagesize to memcntl. The issue is >>>> that there is no check that this alignment_hint actually is a valid >>>> page >>>> size. >>>> >>> >>> Where does this wrong alignment come from? Only from the user via >>> -XX:LargePageAlignmentInBytes? >> >> No, the alignment hint comes from >> CollectorPolicy::generation_alignment(), which is passed to the parallel >> scavenge code as the generation alignment when setting up the heap. >> >> On 2014-09-11 17:23, Thomas Schatzl wrote: >>> If so, wouldn't it be better to make this adjustment during argument >>> processing? Then the VM could inform the user about the change to some >>> degree, either per message, or by overriding the given value >>> (using FLAG_SET_xxx). >>> >>> The alignment_hint should still be checked for validity when it is >>> used, but I think if the method gets a wrong value for the hint from >>> anywhere other than the user, it imo should be an error. Not silently >>> adjusted which potentially leads to hard to find performance problems. >> >> As we discussed on IM, it seems like the alignment_hint is meant to be >> used like a hint, and then the OS specific code can decide the page size >> that is most suitable. In os_linux.cpp for example, the alignment_hint >> is only used for checking if the caller might want to use large pages >> (not the actual page size). BSD and Windows ignores the hint. >> >> In the Solaris code today, the page size is adjusted if the >> alignment_hint is larger than the largest page size, otherwise the >> alignment_hint is treated an exact page size. >> >> I've added a comment to the code explaining that memcntl requires an >> exact page. >> >> Please see new webrevs: >> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01/ >> - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00-01/ >> >> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>> Testing: >>>> - JPRT >>>> - Tested with the patch for >>>> https://bugs.openjdk.java.net/browse/JDK-8027915 >>>> which immediately provokes the bug on Solaris SPARC when just >>>> running >>>> java -version. Now it works fine. >>> >>> Can you add a test case that checks there is no "MPSS failed" message >>> with >>> various LargePageAlignmentInBytes values? >> >> Sure, although I no longer managed to reproduce the bug with only >> java -Xms32m -Xmx128m -XX:LargePageSizeInBytes=256m -version >> >> Let me see if I can come up with some flags that provokes the bug even >> without my fix for JDK-8027915. >> >> Thanks, >> Erik >> >>> Thanks, >>> Thomas >>> >>> From stefan.karlsson at oracle.com Fri Sep 12 13:18:56 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 12 Sep 2014 15:18:56 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5412F062.8060004@oracle.com> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> <5412ECA0.4060202@oracle.com> <5412F062.8060004@oracle.com> Message-ID: <5412F2C0.6080505@oracle.com> On 2014-09-12 15:08, Erik Helin wrote: > All, > > quick feedback from StefanK: > - forgot to cast vm_page_size() to size_t in one place > - print caddr_t with PRT_FORMAT in error message > > Webrevs: > - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.03/ > incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02-03/ Looks good. thanks, StefanK > > Thanks, > Erik > > On 2014-09-12 14:52, Erik Helin wrote: >> Hi, >> >> I've uploaded a new patch that also contains a test: >> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02/ >> - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01-02/ >> >> The test only provokes the bug together with the patch for JDK-8027915 >> and without this patch. Since we don't want to break nightly testing, it >> is better to push this patch first and then push the patch for >> JDK-8027915 (even though the test isn't that meaningful in this patch). >> >> Thanks, >> Erik >> >> On 2014-09-11 18:47, Erik Helin wrote: >>> Hi Thomas, >>> >>> thanks for having a look! >>> >>> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>> >>>> Hi, >>>> >>>> On Thu, 2014-09-11 at 16:15 +0200, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this small patch fixes a problem with the arguments to the syscall >>>>> memcntl on Solaris. >>>>> >>>>> When memcntl is used with MHA_MAPSIZE_VA to tell the system the >>>>> preferred page size for a memory area, the mha_pagesize member of the >>>>> struct memcntl_mha argument must be a valid page size (a valid page >>>>> size >>>>> if one of the sizes returned by the syscall getpagesizes). >>>>> >>>>> One variant of the function os::commit_memory has an alignment_hint >>>>> parameter and the code in os::Solaris::commit_memory_impl sometimes >>>>> passes this alignment_hint as the mha_pagesize to memcntl. The >>>>> issue is >>>>> that there is no check that this alignment_hint actually is a valid >>>>> page >>>>> size. >>>>> >>>> >>>> Where does this wrong alignment come from? Only from the user via >>>> -XX:LargePageAlignmentInBytes? >>> >>> No, the alignment hint comes from >>> CollectorPolicy::generation_alignment(), which is passed to the >>> parallel >>> scavenge code as the generation alignment when setting up the heap. >>> >>> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>> If so, wouldn't it be better to make this adjustment during argument >>>> processing? Then the VM could inform the user about the change to some >>>> degree, either per message, or by overriding the given value >>>> (using FLAG_SET_xxx). >>>> >>>> The alignment_hint should still be checked for validity when it is >>>> used, but I think if the method gets a wrong value for the hint from >>>> anywhere other than the user, it imo should be an error. Not silently >>>> adjusted which potentially leads to hard to find performance problems. >>> >>> As we discussed on IM, it seems like the alignment_hint is meant to be >>> used like a hint, and then the OS specific code can decide the page >>> size >>> that is most suitable. In os_linux.cpp for example, the alignment_hint >>> is only used for checking if the caller might want to use large pages >>> (not the actual page size). BSD and Windows ignores the hint. >>> >>> In the Solaris code today, the page size is adjusted if the >>> alignment_hint is larger than the largest page size, otherwise the >>> alignment_hint is treated an exact page size. >>> >>> I've added a comment to the code explaining that memcntl requires an >>> exact page. >>> >>> Please see new webrevs: >>> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01/ >>> - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00-01/ >>> >>> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>>> Testing: >>>>> - JPRT >>>>> - Tested with the patch for >>>>> https://bugs.openjdk.java.net/browse/JDK-8027915 >>>>> which immediately provokes the bug on Solaris SPARC when just >>>>> running >>>>> java -version. Now it works fine. >>>> >>>> Can you add a test case that checks there is no "MPSS failed" message >>>> with >>>> various LargePageAlignmentInBytes values? >>> >>> Sure, although I no longer managed to reproduce the bug with only >>> java -Xms32m -Xmx128m -XX:LargePageSizeInBytes=256m -version >>> >>> Let me see if I can come up with some flags that provokes the bug even >>> without my fix for JDK-8027915. >>> >>> Thanks, >>> Erik >>> >>>> Thanks, >>>> Thomas >>>> >>>> From staffan.friberg at oracle.com Fri Sep 12 21:26:26 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 12 Sep 2014 14:26:26 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <2548885.ND5rUTNDSq@mgerdin03> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> Message-ID: <54136502.2000305@oracle.com> Hi Mikael, I updated the documentation, and uploaded a new webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 Thanks for agreeing to sponsor, and the good idea about pushing to hs-gc for extra coverage. Thanks, Staffan On 09/09/2014 07:31 AM, Mikael Gerdin wrote: > Hi Staffan, > > On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >> Hi, >> >> Copying both the compiler and GC alias as the optimization involves both >> groups. >> >> This optimization aims to avoid generating G1 barriers for newly >> allocated objects where the compiler can prove that the object has not >> been written to earlier and there is no safepoint between the allocation >> and the write. The bug has some further details and microbenchmark >> result. The new code has fairly extensive comments about the optimization. >> >> It would be great if the GC team can help validate that the premise of >> the optimization is correct as well. >> >> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ > I mostly read through the comments since I can't decode what the IR transforms > intend to do :) > > We usually stick to the terms "old generation" and "young generation" instead > of "Old Space" and "Young Space". > > "G1 also requires to keep track of objects between different > + * regions to enable evacuation of old regions" > should probably be. > .."to keep track of references between different regions" > > I leave it to the compiler team to review the actual code changes. > >> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >> >> I would also need a sponsor for this change if it passes review. > I'll push this to hs-gc after review since we have more G1 test coverage on > hs-gc. > > /Mikael > >> Thanks, >> Staffan From John.Coomes at oracle.com Fri Sep 12 23:01:08 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 12 Sep 2014 16:01:08 -0700 Subject: review request (S) - 8058347: update allocation context stats Message-ID: <21523.31540.822447.513826@mykonos.us.oracle.com> Please review a minor api addition to the AllocationContextService class to check for and process gc requests. http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058347-stats-request-highest/ -John From vladimir.kozlov at oracle.com Fri Sep 12 23:15:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Sep 2014 16:15:30 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <54136502.2000305@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> Message-ID: <54137E92.4030803@oracle.com> Fix indention in 2 checks: + if (use_ReduceInitialCardMarks() && + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { Typo 'iff' in both comments: + * Returns true iff the barrier can be removed In g1_can_remove_post_barrier() use: + // Start search from Store node + Node* ctrl = store->in(MemNode::Control); Control edge can't point to an other Store so you should not check it inside loop. As result you don't need loop. Thanks, Vladimir On 9/12/14 2:26 PM, Staffan Friberg wrote: > Hi Mikael, > > I updated the documentation, and uploaded a new webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 > > Thanks for agreeing to sponsor, and the good idea about pushing to hs-gc for extra coverage. > > Thanks, > Staffan > > On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >> Hi Staffan, >> >> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>> Hi, >>> >>> Copying both the compiler and GC alias as the optimization involves both >>> groups. >>> >>> This optimization aims to avoid generating G1 barriers for newly >>> allocated objects where the compiler can prove that the object has not >>> been written to earlier and there is no safepoint between the allocation >>> and the write. The bug has some further details and microbenchmark >>> result. The new code has fairly extensive comments about the optimization. >>> >>> It would be great if the GC team can help validate that the premise of >>> the optimization is correct as well. >>> >>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >> I mostly read through the comments since I can't decode what the IR transforms >> intend to do :) >> >> We usually stick to the terms "old generation" and "young generation" instead >> of "Old Space" and "Young Space". >> >> "G1 also requires to keep track of objects between different >> + * regions to enable evacuation of old regions" >> should probably be. >> .."to keep track of references between different regions" >> >> I leave it to the compiler team to review the actual code changes. >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>> >>> I would also need a sponsor for this change if it passes review. >> I'll push this to hs-gc after review since we have more G1 test coverage on >> hs-gc. >> >> /Mikael >> >>> Thanks, >>> Staffan > From tprintezis at twitter.com Sat Sep 13 02:45:35 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 12 Sep 2014 22:45:35 -0400 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <5412E510.3020802@oracle.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540FA374.3040401@twitter.com> <5412E510.3020802@oracle.com> Message-ID: <5413AFCF.6080503@twitter.com> Hi Bengt, Thanks for looking at it. Please see inline. On 9/12/14, 8:20 AM, Bengt Rutisson wrote: > > Hi Tony, > > Nice cleanup! I like it! > > On 2014-09-10 03:03, Tony Printezis wrote: >> Latest webrev which I think includes all that we discussed: >> >> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.1/ > > This webrev looks good. A few minor comments below. > > Thanks, > Bengt > > > heapRegionType.hpp > > > 30 #define hrt_assert_is_valid(__tag__) \ > 31 do { \ > 32 assert(is_valid((__tag__)), \ > 33 err_msg("invalid HR type: %u", (uint) (__tag__))); \ > 34 } while (0) > > I don't think we normally use "__" for parameters to macros, so I > would prefer "__tag__" to be called just "tag". The way the macro is > being used I don't see any need for the do {} while loop. I've always written macros really defensively, but that's fine, I'll change it. > g1CollectedHeap.cpp > > 1243 } else if (hr->is_old()) { > 1244 _hr_printer->post_compaction(hr, > G1HRPrinter::ContinuesHumongous); > > This looks wrong. Shouldn't we be printing G1HRPrinter::Old ? Yes, good catch. Bad copy-and-paste. > In TearDownRegionSetsClosure this comment confuses me: > > 6702 } else if (r->is_old()) { > 6703 // Add it to the old set. > 6704 _old_set->remove(r); > > The comment says "add", but we do "remove". The old comment "// The > rest should be old" wasn't great but makes a little sense. We assume > at this point that all regions are old and thus should be removed from > the old set since we are tearing down all old region. Thanks also for catching this. Yes, the comment is wrong. We definitely have to remove the old regions from the old set. > I would propose to remove the comment all together now that we > explicitly identify old regions instead. Or possibly revert back to > the old behavior with a simple else case and then assert that the > region is old. I removed the comment and I also collapsed the if-statements given that they are not needed any more because we can now check is_old(). The new webrev is here: http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2/ And these are the diffs over the previous one: http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2.diff/ Thanks again. BTW, I don't know your current policy: Is this a change you'll be interested in back-porting to JDK 8? Tony > >> >> Tony >> >> On 9/9/14, 5:23 PM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: >>>> Thomas, >>>> >>>> Thanks for looking at this. Inline. >>>> >>>> On 9/9/14, 7:59 AM, Thomas Schatzl wrote: >>>>> - while we are at touching this code I would appreciate if the >>>>> method >>>>> names for isHumongous(), startsHumongous() and >>>>> continuesHumongous() in >>>>> the HeapRegion class would be changed to fit the others as well. I.e. >>>>> is_humongous(), is_startsHu.., is_contin...(). >>>>> >>>>> That could probably done in an extra CR as it adds lots of noise. >>>> How about this: I never liked the lower camel case in the *Humongous() >>>> methods on HeapRegion and I'd like to rename them to is_humongous(), >>>> is_starts_humongous(), is_continues_humongous(). However, as you >>>> pointed >>>> out that'd be a big noisy change (there are 100+ instances of those >>>> methods in the G1 codebase). So, how about I leave the methods on >>>> HeapRegionType as we'd like them to be and rename the rest as a >>>> follow-up change (and I'll be happy to work on that once this goes >>>> in)? >>>> Sounds reasonable? >>> Yes, let's leave the rename out for now. >>> >>> I quickly thought about the naming, the state names were >>> StartsHumongous >>> and ContinuesHumongous, so similar to the others, I would somewhat >>> slightly prefer to keep them together (i.e. is_) and not >>> add >>> underscores to break the two words of the state name. Not really >>> against >>> the proposed naming though (adding the underscore). >>> >>> What I would really like to avoid is to have different order of the >>> words in the state name: right now the change uses >>> is_continues_humongous() in HeapRegion but is_humongous_cont() in >>> HeapRegionType. That seems to be unnecessary. >>> >>> My suggestion is to use the same name in HeapRegionType and HeapRegion. >>> >>> (Btw, the change should also remove the HumongousType enum in >>> heapRegion.hpp) >>> >>>>> - in HeapRegion::hr_clear(), instead of removing the assert, its >>>>> condition could be changed to !is_humongous(). >>>> Actually, this doesn't hold any more, which is why I removed the >>>> assert. >>>> Note that clear_humongous() I doesn't change the type of the region >>>> any >>>> more, as I removed: >>>> >>>> _humongous_type = NotHumongous; >>>> >>>> The type is set to free in hr_clear() (which is called immediately >>>> after >>>> clear_humongous()) (same reason I removed the same assert from >>>> g1HotCardCache.cpp BTW). I could set the type to free in >>>> clear_humongous() too and re-add the assert but I don't think it >>>> matters. The main requirement is that these two fields should be >>>> cleared >>>> in clear_humongous(): >>>> >>>> assert(_humongous_start_region == NULL, >>>> "we should have already filtered out humongous regions"); >>>> assert(_end == _orig_end, >>>> "we should have already filtered out humongous regions"); >>>> >>> Okay. >>> >>>>> - I do not think we need the #if INCLUDE_ALL_GCS here or in any >>>>> heapRegion* file. We can clean that up later. >>>> OK. >>> Actually I think I already fixed that in the change I gave you. >>> >>>>> - the encoding table for the Tag should probably be moved to >>>>> the >>>>> enum. Further it would be nice to write an introductory sentence what >>>>> this table is about and why. >>>> OK. (And yes I'll expand the comment on the tags a bit) >>>> >>>> One more thing I should have made clear: given that I now use >>>> HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in >>>> G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the >>>> ad-hoc code that was there, the output of both (and there's a fair >>>> amount of output that relies on the former) is going to change. Is >>>> that >>>> a problem? I could make sure the output remains the same (by adding >>>> more >>>> get_*_str() methods). I personally don't think it's worth it. >>> Need to look at that again, but I would somewhat prefer to keep the >>> short names, e.g. HC/HS in that output. >>> >>> A get_short_str() method isn't be that hard to add. >>> >>>>> I put up a webrev with some of the suggested changes at >>>>> http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ >>>> Thanks for making the changes. I'll send an update based on your patch >>>> (and once we agree on some of the issues I mentioned above). >>> Thanks, >>> Thomas >>> >>> >> > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From thomas.schatzl at oracle.com Mon Sep 15 08:06:32 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 10:06:32 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5412F062.8060004@oracle.com> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> <5412ECA0.4060202@oracle.com> <5412F062.8060004@oracle.com> Message-ID: <1410768392.2803.16.camel@cirrus> Hi, On Fri, 2014-09-12 at 15:08 +0200, Erik Helin wrote: > All, > > quick feedback from StefanK: > - forgot to cast vm_page_size() to size_t in one place > - print caddr_t with PRT_FORMAT in error message > > Webrevs: > - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.03/ > - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02-03/ os_solaris.cpp, line 3093: assert(is_size_aligned((size_t) start, align), ... I think it is invalid to cast an address to a size_t. At least the C99 standard does not ensure that this is a valid cast. (In practice it is the case for all by Oracle supported platforms I think) The change should use is_ptr_aligned() here and in line 3096 I think, and fix the err_msg() format parameters. > On 2014-09-12 14:52, Erik Helin wrote: > > Hi, > > > > I've uploaded a new patch that also contains a test: > > - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02/ > > - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01-02/ > > > > The test only provokes the bug together with the patch for JDK-8027915 > > and without this patch. Since we don't want to break nightly testing, it > > is better to push this patch first and then push the patch for > > JDK-8027915 (even though the test isn't that meaningful in this patch). Thanks for the test case. Thanks, Thomas From thomas.schatzl at oracle.com Mon Sep 15 08:12:55 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 10:12:55 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <1410768392.2803.16.camel@cirrus> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> <5412ECA0.4060202@oracle.com> <5412F062.8060004@oracle.com> <1410768392.2803.16.camel@cirrus> Message-ID: <1410768775.2803.18.camel@cirrus> Hi again, On Mon, 2014-09-15 at 10:06 +0200, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-12 at 15:08 +0200, Erik Helin wrote: > > All, > > > > quick feedback from StefanK: > > - forgot to cast vm_page_size() to size_t in one place > > - print caddr_t with PRT_FORMAT in error message > > > > Webrevs: > > - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.03/ > > - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02-03/ > > os_solaris.cpp, line 3093: > > assert(is_size_aligned((size_t) start, align), ... > > I think it is invalid to cast an address to a size_t. At least the C99 > standard does not ensure that this is a valid cast. > (In practice it is the case for all by Oracle supported platforms I > think) > > The change should use is_ptr_aligned() here and in line 3096 I think, > and fix the err_msg() format parameters. It's good in the HTML webrev. The udiff still contained the 02 code it seems. So, looks good. Sorry, Thomas From mikael.gerdin at oracle.com Mon Sep 15 08:14:30 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 15 Sep 2014 10:14:30 +0200 Subject: review request (S) - 8058347: update allocation context stats In-Reply-To: <21523.31540.822447.513826@mykonos.us.oracle.com> References: <21523.31540.822447.513826@mykonos.us.oracle.com> Message-ID: <1930545.0WIRF0DptI@mgerdin03> Hi John, On Friday 12 September 2014 16.01.08 John Coomes wrote: > Please review a minor api addition to the AllocationContextService > class to check for and process gc requests. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058347-stats-request-highest/ Looks ok. /Mikael > > -John From erik.helin at oracle.com Mon Sep 15 08:14:27 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Sep 2014 10:14:27 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <1410768775.2803.18.camel@cirrus> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> <5412ECA0.4060202@oracle.com> <5412F062.8060004@oracle.com> <1410768392.2803.16.camel@cirrus> <1410768775.2803.18.camel@cirrus> Message-ID: <54169FE3.4080605@oracle.com> Thanks Thomas! Erik On 2014-09-15 10:12, Thomas Schatzl wrote: > Hi again, > > On Mon, 2014-09-15 at 10:06 +0200, Thomas Schatzl wrote: >> Hi, >> >> On Fri, 2014-09-12 at 15:08 +0200, Erik Helin wrote: >>> All, >>> >>> quick feedback from StefanK: >>> - forgot to cast vm_page_size() to size_t in one place >>> - print caddr_t with PRT_FORMAT in error message >>> >>> Webrevs: >>> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.03/ >>> - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02-03/ >> >> os_solaris.cpp, line 3093: >> >> assert(is_size_aligned((size_t) start, align), ... >> >> I think it is invalid to cast an address to a size_t. At least the C99 >> standard does not ensure that this is a valid cast. >> (In practice it is the case for all by Oracle supported platforms I >> think) >> >> The change should use is_ptr_aligned() here and in line 3096 I think, >> and fix the err_msg() format parameters. > > It's good in the HTML webrev. The udiff still contained the 02 code it > seems. > > So, looks good. > > Sorry, > Thomas > > From bengt.rutisson at oracle.com Mon Sep 15 08:10:55 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Sep 2014 10:10:55 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <5413AFCF.6080503@twitter.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540FA374.3040401@twitter.com> <5412E510.3020802@oracle.com> <5413AFCF.6080503@twitter.com> Message-ID: <54169F0F.2090702@oracle.com> Hi Tony, On 2014-09-13 04:45, Tony Printezis wrote: > Hi Bengt, Thanks for looking at it. Please see inline. > > On 9/12/14, 8:20 AM, Bengt Rutisson wrote: >> >> Hi Tony, >> >> Nice cleanup! I like it! >> >> On 2014-09-10 03:03, Tony Printezis wrote: >>> Latest webrev which I think includes all that we discussed: >>> >>> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.1/ >> >> This webrev looks good. A few minor comments below. >> >> Thanks, >> Bengt >> >> >> heapRegionType.hpp >> >> >> 30 #define hrt_assert_is_valid(__tag__) \ >> 31 do { \ >> 32 assert(is_valid((__tag__)), \ >> 33 err_msg("invalid HR type: %u", (uint) (__tag__))); \ >> 34 } while (0) >> >> I don't think we normally use "__" for parameters to macros, so I >> would prefer "__tag__" to be called just "tag". The way the macro is >> being used I don't see any need for the do {} while loop. > > I've always written macros really defensively, but that's fine, I'll > change it. > >> g1CollectedHeap.cpp >> >> 1243 } else if (hr->is_old()) { >> 1244 _hr_printer->post_compaction(hr, >> G1HRPrinter::ContinuesHumongous); >> >> This looks wrong. Shouldn't we be printing G1HRPrinter::Old ? > > Yes, good catch. Bad copy-and-paste. > >> In TearDownRegionSetsClosure this comment confuses me: >> >> 6702 } else if (r->is_old()) { >> 6703 // Add it to the old set. >> 6704 _old_set->remove(r); >> >> The comment says "add", but we do "remove". The old comment "// The >> rest should be old" wasn't great but makes a little sense. We assume >> at this point that all regions are old and thus should be removed >> from the old set since we are tearing down all old region. > > Thanks also for catching this. Yes, the comment is wrong. We > definitely have to remove the old regions from the old set. > >> I would propose to remove the comment all together now that we >> explicitly identify old regions instead. Or possibly revert back to >> the old behavior with a simple else case and then assert that the >> region is old. > I removed the comment and I also collapsed the if-statements given > that they are not needed any more because we can now check is_old(). > > The new webrev is here: > > http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2/ > > And these are the diffs over the previous one: > > http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2.diff/ Looks good! Thanks for fixing this! > > Thanks again. BTW, I don't know your current policy: Is this a change > you'll be interested in back-porting to JDK 8? I think it would be good to backport this to the 8u repo to make other backports simpler. But I can't say right now when we can do the backport. As you can see from this schedule: http://openjdk.java.net/projects/jdk8u/releases/8u40.html the next 8u release is close to being feature complete so we might have to wait until the next 8u release to push this. BTW, I can sponsor this fix and make sure it gets pushed to the JDK 9 repo as soon as we have complete reviews. Thanks, Bengt > > Tony > > >> >>> >>> Tony >>> >>> On 9/9/14, 5:23 PM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Tue, 2014-09-09 at 16:43 -0400, Tony Printezis wrote: >>>>> Thomas, >>>>> >>>>> Thanks for looking at this. Inline. >>>>> >>>>> On 9/9/14, 7:59 AM, Thomas Schatzl wrote: >>>>>> - while we are at touching this code I would appreciate if >>>>>> the method >>>>>> names for isHumongous(), startsHumongous() and >>>>>> continuesHumongous() in >>>>>> the HeapRegion class would be changed to fit the others as well. >>>>>> I.e. >>>>>> is_humongous(), is_startsHu.., is_contin...(). >>>>>> >>>>>> That could probably done in an extra CR as it adds lots of noise. >>>>> How about this: I never liked the lower camel case in the >>>>> *Humongous() >>>>> methods on HeapRegion and I'd like to rename them to is_humongous(), >>>>> is_starts_humongous(), is_continues_humongous(). However, as you >>>>> pointed >>>>> out that'd be a big noisy change (there are 100+ instances of those >>>>> methods in the G1 codebase). So, how about I leave the methods on >>>>> HeapRegionType as we'd like them to be and rename the rest as a >>>>> follow-up change (and I'll be happy to work on that once this goes >>>>> in)? >>>>> Sounds reasonable? >>>> Yes, let's leave the rename out for now. >>>> >>>> I quickly thought about the naming, the state names were >>>> StartsHumongous >>>> and ContinuesHumongous, so similar to the others, I would somewhat >>>> slightly prefer to keep them together (i.e. is_) and >>>> not add >>>> underscores to break the two words of the state name. Not really >>>> against >>>> the proposed naming though (adding the underscore). >>>> >>>> What I would really like to avoid is to have different order of the >>>> words in the state name: right now the change uses >>>> is_continues_humongous() in HeapRegion but is_humongous_cont() in >>>> HeapRegionType. That seems to be unnecessary. >>>> >>>> My suggestion is to use the same name in HeapRegionType and >>>> HeapRegion. >>>> >>>> (Btw, the change should also remove the HumongousType enum in >>>> heapRegion.hpp) >>>> >>>>>> - in HeapRegion::hr_clear(), instead of removing the assert, its >>>>>> condition could be changed to !is_humongous(). >>>>> Actually, this doesn't hold any more, which is why I removed the >>>>> assert. >>>>> Note that clear_humongous() I doesn't change the type of the >>>>> region any >>>>> more, as I removed: >>>>> >>>>> _humongous_type = NotHumongous; >>>>> >>>>> The type is set to free in hr_clear() (which is called immediately >>>>> after >>>>> clear_humongous()) (same reason I removed the same assert from >>>>> g1HotCardCache.cpp BTW). I could set the type to free in >>>>> clear_humongous() too and re-add the assert but I don't think it >>>>> matters. The main requirement is that these two fields should be >>>>> cleared >>>>> in clear_humongous(): >>>>> >>>>> assert(_humongous_start_region == NULL, >>>>> "we should have already filtered out humongous regions"); >>>>> assert(_end == _orig_end, >>>>> "we should have already filtered out humongous regions"); >>>>> >>>> Okay. >>>> >>>>>> - I do not think we need the #if INCLUDE_ALL_GCS here or in >>>>>> any >>>>>> heapRegion* file. We can clean that up later. >>>>> OK. >>>> Actually I think I already fixed that in the change I gave you. >>>> >>>>>> - the encoding table for the Tag should probably be moved >>>>>> to the >>>>>> enum. Further it would be nice to write an introductory sentence >>>>>> what >>>>>> this table is about and why. >>>>> OK. (And yes I'll expand the comment on the tags a bit) >>>>> >>>>> One more thing I should have made clear: given that I now use >>>>> HeapRegion::get_type_str() in HR_FORMAT_PARAMS() and in >>>>> G1PrintRegionLivenessInfoClosure (concurrentMark.cpp), instead of the >>>>> ad-hoc code that was there, the output of both (and there's a fair >>>>> amount of output that relies on the former) is going to change. Is >>>>> that >>>>> a problem? I could make sure the output remains the same (by >>>>> adding more >>>>> get_*_str() methods). I personally don't think it's worth it. >>>> Need to look at that again, but I would somewhat prefer to keep the >>>> short names, e.g. HC/HS in that output. >>>> >>>> A get_short_str() method isn't be that hard to add. >>>> >>>>>> I put up a webrev with some of the suggested changes at >>>>>> http://cr.openjdk.java.net/~tschatzl/8057768/webrev/ >>>>> Thanks for making the changes. I'll send an update based on your >>>>> patch >>>>> (and once we agree on some of the issues I mentioned above). >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> > From erik.helin at oracle.com Mon Sep 15 08:14:41 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Sep 2014 10:14:41 +0200 Subject: RFR: 8049536: os::commit_memory on Solaris uses aligment_hint as page size In-Reply-To: <5412F2C0.6080505@oracle.com> References: <5411AE7D.10005@oracle.com> <1410449021.6124.5.camel@cirrus> <5411D208.30001@oracle.com> <5412ECA0.4060202@oracle.com> <5412F062.8060004@oracle.com> <5412F2C0.6080505@oracle.com> Message-ID: <54169FF1.8000303@oracle.com> Thanks StefanK! Erik On 2014-09-12 15:18, Stefan Karlsson wrote: > On 2014-09-12 15:08, Erik Helin wrote: >> All, >> >> quick feedback from StefanK: >> - forgot to cast vm_page_size() to size_t in one place >> - print caddr_t with PRT_FORMAT in error message >> >> Webrevs: >> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.03/ >> incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02-03/ > > Looks good. > > thanks, > StefanK > >> >> Thanks, >> Erik >> >> On 2014-09-12 14:52, Erik Helin wrote: >>> Hi, >>> >>> I've uploaded a new patch that also contains a test: >>> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.02/ >>> - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01-02/ >>> >>> The test only provokes the bug together with the patch for JDK-8027915 >>> and without this patch. Since we don't want to break nightly testing, it >>> is better to push this patch first and then push the patch for >>> JDK-8027915 (even though the test isn't that meaningful in this patch). >>> >>> Thanks, >>> Erik >>> >>> On 2014-09-11 18:47, Erik Helin wrote: >>>> Hi Thomas, >>>> >>>> thanks for having a look! >>>> >>>> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Thu, 2014-09-11 at 16:15 +0200, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this small patch fixes a problem with the arguments to the syscall >>>>>> memcntl on Solaris. >>>>>> >>>>>> When memcntl is used with MHA_MAPSIZE_VA to tell the system the >>>>>> preferred page size for a memory area, the mha_pagesize member of the >>>>>> struct memcntl_mha argument must be a valid page size (a valid page >>>>>> size >>>>>> if one of the sizes returned by the syscall getpagesizes). >>>>>> >>>>>> One variant of the function os::commit_memory has an alignment_hint >>>>>> parameter and the code in os::Solaris::commit_memory_impl sometimes >>>>>> passes this alignment_hint as the mha_pagesize to memcntl. The >>>>>> issue is >>>>>> that there is no check that this alignment_hint actually is a valid >>>>>> page >>>>>> size. >>>>>> >>>>> >>>>> Where does this wrong alignment come from? Only from the user via >>>>> -XX:LargePageAlignmentInBytes? >>>> >>>> No, the alignment hint comes from >>>> CollectorPolicy::generation_alignment(), which is passed to the >>>> parallel >>>> scavenge code as the generation alignment when setting up the heap. >>>> >>>> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>>> If so, wouldn't it be better to make this adjustment during argument >>>>> processing? Then the VM could inform the user about the change to some >>>>> degree, either per message, or by overriding the given value >>>>> (using FLAG_SET_xxx). >>>>> >>>>> The alignment_hint should still be checked for validity when it is >>>>> used, but I think if the method gets a wrong value for the hint from >>>>> anywhere other than the user, it imo should be an error. Not silently >>>>> adjusted which potentially leads to hard to find performance problems. >>>> >>>> As we discussed on IM, it seems like the alignment_hint is meant to be >>>> used like a hint, and then the OS specific code can decide the page >>>> size >>>> that is most suitable. In os_linux.cpp for example, the alignment_hint >>>> is only used for checking if the caller might want to use large pages >>>> (not the actual page size). BSD and Windows ignores the hint. >>>> >>>> In the Solaris code today, the page size is adjusted if the >>>> alignment_hint is larger than the largest page size, otherwise the >>>> alignment_hint is treated an exact page size. >>>> >>>> I've added a comment to the code explaining that memcntl requires an >>>> exact page. >>>> >>>> Please see new webrevs: >>>> - full: http://cr.openjdk.java.net/~ehelin/8049536/webrev.01/ >>>> - incremental: http://cr.openjdk.java.net/~ehelin/8049536/webrev.00-01/ >>>> >>>> On 2014-09-11 17:23, Thomas Schatzl wrote: >>>>>> Testing: >>>>>> - JPRT >>>>>> - Tested with the patch for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8027915 >>>>>> which immediately provokes the bug on Solaris SPARC when just >>>>>> running >>>>>> java -version. Now it works fine. >>>>> >>>>> Can you add a test case that checks there is no "MPSS failed" message >>>>> with >>>>> various LargePageAlignmentInBytes values? >>>> >>>> Sure, although I no longer managed to reproduce the bug with only >>>> java -Xms32m -Xmx128m -XX:LargePageSizeInBytes=256m -version >>>> >>>> Let me see if I can come up with some flags that provokes the bug even >>>> without my fix for JDK-8027915. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> > From thomas.schatzl at oracle.com Mon Sep 15 09:37:55 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 11:37:55 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <5413AFCF.6080503@twitter.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540FA374.3040401@twitter.com> <5412E510.3020802@oracle.com> <5413AFCF.6080503@twitter.com> Message-ID: <1410773875.2803.28.camel@cirrus> Hi, On Fri, 2014-09-12 at 22:45 -0400, Tony Printezis wrote: > Hi Bengt, Thanks for looking at it. Please see inline. > > On 9/12/14, 8:20 AM, Bengt Rutisson wrote: > > > > Hi Tony, > > > > Nice cleanup! I like it! > > I agree with Bengt here. [...] > The new webrev is here: > > http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2/ > > And these are the diffs over the previous one: > > http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2.diff/ > > Thanks again. BTW, I don't know your current policy: Is this a change > you'll be interested in back-porting to JDK 8? > > Tony Looks good. Two last minor things I have: - in g1HotCardCache.cpp the include to heapRegion.hpp is not required any more. I think Bengt could simply fix that before pushing. - the order of words in the humongous region types is not used consistently: the tag values are called HumStarts/Cont, but the methods set/is_continues_humongous(). I.e. the position of the type of humongous region changes within the method name which seems without reason. It's not a big issue. If needed, this may as well be fixed in the isHumongous()/continuesHumongous() method naming cleanup. Thanks, Thomas From thomas.schatzl at oracle.com Mon Sep 15 09:52:43 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 11:52:43 +0200 Subject: review request (S) - 8058347: update allocation context stats In-Reply-To: <21523.31540.822447.513826@mykonos.us.oracle.com> References: <21523.31540.822447.513826@mykonos.us.oracle.com> Message-ID: <1410774763.2803.29.camel@cirrus> Hi, On Fri, 2014-09-12 at 16:01 -0700, John Coomes wrote: > Please review a minor api addition to the AllocationContextService > class to check for and process gc requests. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058347-stats-request-highest/ > > -John looks okay. Thomas From bengt.rutisson at oracle.com Mon Sep 15 11:39:38 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Sep 2014 13:39:38 +0200 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <1410773875.2803.28.camel@cirrus> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540FA374.3040401@twitter.com> <5412E510.3020802@oracle.com> <5413AFCF.6080503@twitter.com> <1410773875.2803.28.camel@cirrus> Message-ID: <5416CFFA.7080708@oracle.com> Hi, On 2014-09-15 11:37, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-12 at 22:45 -0400, Tony Printezis wrote: >> Hi Bengt, Thanks for looking at it. Please see inline. >> >> On 9/12/14, 8:20 AM, Bengt Rutisson wrote: >>> Hi Tony, >>> >>> Nice cleanup! I like it! >>> > I agree with Bengt here. > > [...] >> The new webrev is here: >> >> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2/ >> >> And these are the diffs over the previous one: >> >> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2.diff/ >> >> Thanks again. BTW, I don't know your current policy: Is this a change >> you'll be interested in back-porting to JDK 8? >> >> Tony > Looks good. Two last minor things I have: > > - in g1HotCardCache.cpp the include to heapRegion.hpp is not required > any more. > > I think Bengt could simply fix that before pushing. Nice find. I fixed that and pushed the patch. Here's the changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 > > - the order of words in the humongous region types is not used > consistently: the tag values are called HumStarts/Cont, but the methods > set/is_continues_humongous(). > I.e. the position of the type of humongous region changes within the > method name which seems without reason. > > It's not a big issue. If needed, this may as well be fixed in the > isHumongous()/continuesHumongous() method naming cleanup. Yes, I agree that it is better to do this rename together with the isHumongous()/continuesHumongous() method naming cleanup. Especially since I now pushed the rest of the patch ;) Thanks, Bengt > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Mon Sep 15 12:06:36 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Sep 2014 14:06:36 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <540A3730.1060603@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> Message-ID: <5416D64C.9020207@oracle.com> Hi Staffan, psPromotionManager.inline.hpp I think the PSPromotionManager::copy_to_survivor_space() might send multiple events. If the allocation to the young gen fails we will fall through to do an old gen allocation. But we send the events before we realize that the allocation has failed, i.e. new_obj is NULL. I talked to Erik a bit about how to handle the gc_tracer in par_promote. He'll get back to you with some thoughts on that. Thanks, Bengt On 2014-09-06 00:20, Staffan Friberg wrote: > Hi, > > I have uploaded a new webrev here, > cr.openjdk.java.net/~sfriberg/8055845/webrev.03 > > It contains several changes > > - Split event into two events (PromoteObjectInNewPLAB, > PromoteObjectOutsidePLAB) > - Moved events to "vm/gc/detailed/PromoteObject..." > - Supporting ParNew+CMS and ParNew+SerialOld tenuring > - Not sure if the way I do it with passing the ParNewTracer > is the best solution, please let me know if you have an idea how to > improve it > - Simplified the G1 code to avoid sending age and having a single > call site > - Fixed so that the generated event has size information in bytes > rather than words > > Thanks for offline comments and suggestions from Dmitry and Thomas. > > Cheers, > Staffan > > On 08/29/2014 03:32 PM, Staffan Friberg wrote: >> Hi Erik, >> >> On 08/28/2014 11:34 PM, Erik Helin wrote: >>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in >>> this thread, I'm adding it back) >>> >>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>> Hi Erik, >>>> >>>> Thanks for the comments. >>>>> - Aren't the events for promotion to the tenured generation >>>>> (SerialOld) >>>>> and the CMS generation missing? >>>> The reason for leaving out these two, Serial completely and CMS >>>> promotion, was due to that neither as far as I understand make use of >>>> PLABs. >>> >>> I might be wrong here, but looking at the function >>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks >>> to me like SerialOld is using PLABs when ParNew is promoting objects >>> from young to old. >>> >>> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote >>> (in concurrentMarkSweepGeneration.cpp) it seems like each >>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local >>> Allocation Buffer) that is a thread-local allocation buffer. See >>> compactibleFreeListSpace.{hpp,cpp} for more details. >>> >>> Given this, I think we should add events for Serial and CMS as well. >>> >> >> Ok I see what you mean with CMS, basically the equivalent to getting >> a PLAB would be when we refill the CFLS_LAB in the alloc function. It >> still does the allocation to a small memory (~ size of object) area >> from the freelist, but at least we did extra work to refill the local >> CFLS_LAB. Need to do some analysis to see how often we refill so the >> overhead doesn't get too high. >> The only issue I run into is how I can in a nice way get access to >> the ParNewTracer from ParNewGeneration to call the report function. >> Let's sync up next week and see how it can be solved. >> >> The tenured GC requires something similar to be supported, however >> since ParNewGC is deprecated for usage without CMS in JDK 8 we might >> want to skip that combination. >> >> >>> >>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>> - Would it make sense to differentiate, either by separate events >>>>> or by >>>>> a field in a event, between promotions to to-space and to the old >>>>> generation? >>>>> - The are two events for TLAB allocations, >>>>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>>>> What do you think about using two events for PLAB allocations as >>>>> well: >>>>> - java/object_alloc_in_new_PLAB >>>>> - java/object_alloc_outside_PLAB >>>> I think this is a matter of taste and probably how similar we want the >>>> event to be to the existing allocation event. I personally prefer a >>>> single event but if the GC team and serviceability team feel it >>>> would be >>>> better to have two I can certainly rewrite. The reason for me >>>> preferring >>>> a single event is just ease of analysis, you can easily filter a >>>> list of >>>> events on a field, it is harder to merge two different events with >>>> different fields and work with them in an straight forward fashion. >>>> >>>> Any general preference for having a single or multiple events? >>> >>> I would prefer to have two events in this case and try to follow the >>> existing allocation events as much as possible (both in naming and >>> in style). Keeping the tenured field (I missed it the first time I >>> read the patch) is good. >>> >> Yes, tenured would be independent of having two events, only PLAB >> size and directAllocation would be affected when having two event types. >> >> *Erik Gahlin*, any preference from your end? >> >> >> >>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>> - In PSPromotionManager, instead of utilizing the C++ friendship with >>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>> Created a getter function. >>> >>> Thanks! If you make report_promotion_sample const, then the getter >>> can return a const ParallelScavengeTracer*, right? >>> >> Done >> >> //Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Sep 15 12:57:44 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 14:57:44 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <540A3730.1060603@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> Message-ID: <1410785864.2803.71.camel@cirrus> Hi, On Fri, 2014-09-05 at 15:20 -0700, Staffan Friberg wrote: > Hi, > > I have uploaded a new webrev here, > cr.openjdk.java.net/~sfriberg/8055845/webrev.03 > > It contains several changes > > - Split event into two events (PromoteObjectInNewPLAB, > PromoteObjectOutsidePLAB) > - Moved events to "vm/gc/detailed/PromoteObject..." > - Supporting ParNew+CMS and ParNew+SerialOld tenuring > - Not sure if the way I do it with passing the ParNewTracer > is the best solution, please let me know if you have an idea how to > improve it > - Simplified the G1 code to avoid sending age and having a single > call site > - Fixed so that the generated event has size information in bytes > rather than words > > Thanks for offline comments and suggestions from Dmitry and Thomas. - in G1CollectedHeap::par_allocate_during_gc() I still think it is required to do the !old->is_forwarded() check before retrieving the old->age(), and so that there cannot be a reload of the mark header between those. Also, if you look at oopDesc::age(), the first assert checks whether it is not forwarded. Between the atomic claim by installing the forward pointer and this reading of the age this might happen, so the assert may trigger. So the change should either read the mark oop first (using a volatile read), then do the is_forwarded() check and the retrieval of the age value on that mark oop, do the even processing after the claiming of the object (forward pointer installing) as suggested once, or (least favourable to me) pass the markOop down. The latter messes up the method signatures, and in any case (when using option one or three) this code is slightly racy as we might report too many events as another thread might have claimed the object. (Parallel Scavenge has the same issue, in addition to the possibility of sending two events as Bengt describes). Please document the possibility of the race, and the workaround in these locations. - another source of inaccuracy is that at the end of GC, G1 will make the very last PLAB available for allocation in the next GC. And it may do additional allocations to fill up the region (if there is not enough useful space at the end of the allocation region), or fill up the old gen allocation to the next card to avoid races in the next GC (see G1CollectedHeap::release_gc_alloc_regions() and the release() methods of the Survivor/OldGCAllocRegion classes. This, that JFR might get slightly too many events (or too few), should be documented somewhere, probably in JFR/event documentation. At least the sum of these allocations should not be used as the number of copied bytes. - also maybe add a comment about the purpose of the "old" parameters passed around. It is not obvious that a method that allocates a range of bytes needs the value of the old memory block. Except for CMS, where it is already used, the other non-G1 methods lack this documentation too. - please align the parameters in all calls to gc_tracer->report_promotion_event(). - there is a superfluous space at the end of the line in generation.hpp:326 Thanks, Thomas From erik.helin at oracle.com Mon Sep 15 14:09:26 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Sep 2014 16:09:26 +0200 Subject: RFR: 8049864: TestParallelHeapSizeFlags fails with unexpected heap size Message-ID: <5416F316.8020607@oracle.com> Hi all, this change was discussed and approved back in June [0], "RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected heap size on sparcv9", but had to be backed out because it exposed JDK-8049536 [1]. Now that JDK-8049536 has been fixed [2], it is time to re-apply the patch that fixes the test failure. Since the patch already has been pushed once, and each commit requires a unique bug id, the bug had to be cloned in JBS. The old bug id is JDK-8027915 [3] and the new bug id is JDK-8049864 [4]. The already approved patch applied cleanly except that the JTreg @ignore directive in the test used the new bug number, JDK-8049864. So instead of just pushing the patch again (with the new bug id), I figured it was best to give everyone a heads up first. Webrev: http://cr.openjdk.java.net/~ehelin/8049864/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8049864 Thanks, Erik [0]: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014325.html [1]: https://bugs.openjdk.java.net/browse/JDK-8049536 [2]: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/cde40424bcd4 [3]: https://bugs.openjdk.java.net/browse/JDK-8027915 [4]: https://bugs.openjdk.java.net/browse/JDK-8049864 From stefan.karlsson at oracle.com Mon Sep 15 14:05:47 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Sep 2014 16:05:47 +0200 Subject: RFR: 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr Message-ID: <5416F23B.6090307@oracle.com> Hi all, Please review this patch to make TestCMSClassUnloadingEnabledHWM more stable. Instead of trying to bootstrap the initial mark with young GCs, just wait for the concurrent cycle to start. I've lowered some CMS specific flags to make this test run faster. http://cr.openjdk.java.net/~stefank/8058475/webrev.00/ thanks, StefanK From thomas.schatzl at oracle.com Mon Sep 15 14:24:44 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 16:24:44 +0200 Subject: RFR (S): 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set Message-ID: <1410791084.2803.87.camel@cirrus> Hi all, can I have reviews for the following removal of the -XX:-G1DeferredRSUpdate functionality? Problem is that the functionality of -XX:-G1DeferredRSUpdate is broken (likely since forever): in case of evacuation failure there is the possibility that some threads add remembered set entries (the ones experiencing the to-space exhaustion) while other threads are still iterating over the same remembered set. This can cause the iterators to skip remembered set entries, which in turn causes lost objects. Since XX:-G1DeferredRSUpdate is a (rarely used) develop only flag, it is not worth (imo) to try to fix this. There is no advantage of using the current kind of remembered set in conjunction with immediate RSet updates. If in the future any different RSet implementations were added, these changes would be comparably easy to add again. Problem is that having it in the code (and testing it) occasionally causes test failures. It is easiest to simply remove the functionality. CR: https://bugs.openjdk.java.net/browse/JDK-8052172 Webrev: http://cr.openjdk.java.net/~tschatzl/8052172/webrev/ Testing: jprt Thanks, Thomas From stefan.johansson at oracle.com Mon Sep 15 14:35:23 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 15 Sep 2014 16:35:23 +0200 Subject: RFR: 8049864: TestParallelHeapSizeFlags fails with unexpected heap size In-Reply-To: <5416F316.8020607@oracle.com> References: <5416F316.8020607@oracle.com> Message-ID: <5416F92B.3050303@oracle.com> Looks good Erik, Stefan On 2014-09-15 16:09, Erik Helin wrote: > Hi all, > > this change was discussed and approved back in June [0], "RFR: > 8027915: TestParallelHeapSizeFlags fails with unexpected heap size on > sparcv9", > but had to be backed out because it exposed JDK-8049536 [1]. Now that > JDK-8049536 has been fixed [2], it is time to re-apply the patch that > fixes the test failure. > > Since the patch already has been pushed once, and each commit requires > a unique bug id, the bug had to be cloned in JBS. The old bug id is > JDK-8027915 [3] and the new bug id is JDK-8049864 [4]. > > The already approved patch applied cleanly except that the JTreg > @ignore directive in the test used the new bug number, JDK-8049864. So > instead of just pushing the patch again (with the new bug id), I > figured it was best to give everyone a heads up first. > > Webrev: http://cr.openjdk.java.net/~ehelin/8049864/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049864 > > Thanks, > Erik > > [0]: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014325.html > [1]: https://bugs.openjdk.java.net/browse/JDK-8049536 > [2]: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/cde40424bcd4 > [3]: https://bugs.openjdk.java.net/browse/JDK-8027915 > [4]: https://bugs.openjdk.java.net/browse/JDK-8049864 From mikael.gerdin at oracle.com Mon Sep 15 14:36:33 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 15 Sep 2014 16:36:33 +0200 Subject: RFR: 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr In-Reply-To: <5416F23B.6090307@oracle.com> References: <5416F23B.6090307@oracle.com> Message-ID: <3444221.FFNixxq6uJ@mgerdin03> Hi Stefan, On Monday 15 September 2014 16.05.47 Stefan Karlsson wrote: > Hi all, > > > Please review this patch to make TestCMSClassUnloadingEnabledHWM more > stable. Instead of trying to bootstrap the initial mark with young GCs, > just wait for the concurrent cycle to start. I've lowered some CMS > specific flags to make this test run faster. > > http://cr.openjdk.java.net/~stefank/8058475/webrev.00/ Can you make + "TestG1ClassUnloadingHWM$AllocateBeyondMetaspaceSize", TestG1ClassUnloadingHWM.class.getName() instead? same for CMS Otherwise it looks good. I don't need to re-review changing to .class.getName() /Mikael > > thanks, > StefanK From stefan.karlsson at oracle.com Mon Sep 15 14:29:43 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Sep 2014 16:29:43 +0200 Subject: RFR: 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr In-Reply-To: <3444221.FFNixxq6uJ@mgerdin03> References: <5416F23B.6090307@oracle.com> <3444221.FFNixxq6uJ@mgerdin03> Message-ID: <5416F7D7.4050301@oracle.com> On 2014-09-15 16:36, Mikael Gerdin wrote: > Hi Stefan, > > On Monday 15 September 2014 16.05.47 Stefan Karlsson wrote: >> Hi all, >> >> >> Please review this patch to make TestCMSClassUnloadingEnabledHWM more >> stable. Instead of trying to bootstrap the initial mark with young GCs, >> just wait for the concurrent cycle to start. I've lowered some CMS >> specific flags to make this test run faster. >> >> http://cr.openjdk.java.net/~stefank/8058475/webrev.00/ > Can you make > + "TestG1ClassUnloadingHWM$AllocateBeyondMetaspaceSize", > TestG1ClassUnloadingHWM.class.getName() instead? > same for CMS > > Otherwise it looks good. > I don't need to re-review changing to .class.getName() Sure. Thanks. StefanK > > /Mikael > > >> thanks, >> StefanK From tprintezis at twitter.com Mon Sep 15 15:06:59 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Mon, 15 Sep 2014 11:06:59 -0400 Subject: Introduce "region type" field to G1 HeapRegions In-Reply-To: <5416CFFA.7080708@oracle.com> References: <540A2B9F.2000105@twitter.com> <1410263974.2647.22.camel@cirrus> <540F6664.1050000@twitter.com> <1410297781.3807.21.camel@cirrus> <540FA374.3040401@twitter.com> <5412E510.3020802@oracle.com> <5413AFCF.6080503@twitter.com> <1410773875.2803.28.camel@cirrus> <5416CFFA.7080708@oracle.com> Message-ID: <54170093.9010508@twitter.com> Thomas and Bengt, Inline. On 9/15/14, 7:39 AM, Bengt Rutisson wrote: > > Hi, > > On 2014-09-15 11:37, Thomas Schatzl wrote: >> Hi, >> >> On Fri, 2014-09-12 at 22:45 -0400, Tony Printezis wrote: >>> Hi Bengt, Thanks for looking at it. Please see inline. >>> >>> On 9/12/14, 8:20 AM, Bengt Rutisson wrote: >>>> Hi Tony, >>>> >>>> Nice cleanup! I like it! >>>> >> I agree with Bengt here. >> >> [...] >>> The new webrev is here: >>> >>> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2/ >>> >>> And these are the diffs over the previous one: >>> >>> http://cr.openjdk.java.net/~tonyp/g1-region-type/webrev.2.diff/ >>> >>> Thanks again. BTW, I don't know your current policy: Is this a change >>> you'll be interested in back-porting to JDK 8? >>> >>> Tony >> Looks good. Two last minor things I have: >> >> - in g1HotCardCache.cpp the include to heapRegion.hpp is not required >> any more. >> >> I think Bengt could simply fix that before pushing. > > Nice find. I fixed that and pushed the patch. Here's the changeset: > > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 Thanks for fixing it and for pushing the patch! >> >> - the order of words in the humongous region types is not used >> consistently: the tag values are called HumStarts/Cont, but the methods >> set/is_continues_humongous(). >> I.e. the position of the type of humongous region changes within the >> method name which seems without reason. >> >> It's not a big issue. If needed, this may as well be fixed in the >> isHumongous()/continuesHumongous() method naming cleanup. > > Yes, I agree that it is better to do this rename together with the > isHumongous()/continuesHumongous() method naming cleanup. Especially > since I now pushed the rest of the patch ;) Sounds good. I have the renaming already ready. I'll send out a webrev shortly. Tony > Thanks, > Bengt > >> >> Thanks, >> Thomas >> >> > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From erik.gahlin at oracle.com Mon Sep 15 13:56:05 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 15 Sep 2014 15:56:05 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <540A3730.1060603@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> Message-ID: <5416EFF5.8050702@oracle.com> Metadata looks good (trace.xml). /E Staffan Friberg skrev 2014-09-06 00:20: > Hi, > > I have uploaded a new webrev here, > cr.openjdk.java.net/~sfriberg/8055845/webrev.03 > > It contains several changes > > - Split event into two events (PromoteObjectInNewPLAB, > PromoteObjectOutsidePLAB) > - Moved events to "vm/gc/detailed/PromoteObject..." > - Supporting ParNew+CMS and ParNew+SerialOld tenuring > - Not sure if the way I do it with passing the ParNewTracer > is the best solution, please let me know if you have an idea how to > improve it > - Simplified the G1 code to avoid sending age and having a single > call site > - Fixed so that the generated event has size information in bytes > rather than words > > Thanks for offline comments and suggestions from Dmitry and Thomas. > > Cheers, > Staffan > > On 08/29/2014 03:32 PM, Staffan Friberg wrote: >> Hi Erik, >> >> On 08/28/2014 11:34 PM, Erik Helin wrote: >>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in >>> this thread, I'm adding it back) >>> >>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>> Hi Erik, >>>> >>>> Thanks for the comments. >>>>> - Aren't the events for promotion to the tenured generation >>>>> (SerialOld) >>>>> and the CMS generation missing? >>>> The reason for leaving out these two, Serial completely and CMS >>>> promotion, was due to that neither as far as I understand make use of >>>> PLABs. >>> >>> I might be wrong here, but looking at the function >>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks >>> to me like SerialOld is using PLABs when ParNew is promoting objects >>> from young to old. >>> >>> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote >>> (in concurrentMarkSweepGeneration.cpp) it seems like each >>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local >>> Allocation Buffer) that is a thread-local allocation buffer. See >>> compactibleFreeListSpace.{hpp,cpp} for more details. >>> >>> Given this, I think we should add events for Serial and CMS as well. >>> >> >> Ok I see what you mean with CMS, basically the equivalent to getting >> a PLAB would be when we refill the CFLS_LAB in the alloc function. It >> still does the allocation to a small memory (~ size of object) area >> from the freelist, but at least we did extra work to refill the local >> CFLS_LAB. Need to do some analysis to see how often we refill so the >> overhead doesn't get too high. >> The only issue I run into is how I can in a nice way get access to >> the ParNewTracer from ParNewGeneration to call the report function. >> Let's sync up next week and see how it can be solved. >> >> The tenured GC requires something similar to be supported, however >> since ParNewGC is deprecated for usage without CMS in JDK 8 we might >> want to skip that combination. >> >> >>> >>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>> - Would it make sense to differentiate, either by separate events >>>>> or by >>>>> a field in a event, between promotions to to-space and to the old >>>>> generation? >>>>> - The are two events for TLAB allocations, >>>>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>>>> What do you think about using two events for PLAB allocations as >>>>> well: >>>>> - java/object_alloc_in_new_PLAB >>>>> - java/object_alloc_outside_PLAB >>>> I think this is a matter of taste and probably how similar we want the >>>> event to be to the existing allocation event. I personally prefer a >>>> single event but if the GC team and serviceability team feel it >>>> would be >>>> better to have two I can certainly rewrite. The reason for me >>>> preferring >>>> a single event is just ease of analysis, you can easily filter a >>>> list of >>>> events on a field, it is harder to merge two different events with >>>> different fields and work with them in an straight forward fashion. >>>> >>>> Any general preference for having a single or multiple events? >>> >>> I would prefer to have two events in this case and try to follow the >>> existing allocation events as much as possible (both in naming and >>> in style). Keeping the tenured field (I missed it the first time I >>> read the patch) is good. >>> >> Yes, tenured would be independent of having two events, only PLAB >> size and directAllocation would be affected when having two event types. >> >> *Erik Gahlin*, any preference from your end? >> >> >> >>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>> - In PSPromotionManager, instead of utilizing the C++ friendship with >>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>> Created a getter function. >>> >>> Thanks! If you make report_promotion_sample const, then the getter >>> can return a const ParallelScavengeTracer*, right? >>> >> Done >> >> //Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Sep 15 16:13:42 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Sep 2014 18:13:42 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <1410785864.2803.71.camel@cirrus> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <1410785864.2803.71.camel@cirrus> Message-ID: <1410797622.2803.147.camel@cirrus> Hi, one more allocation that is more serious that this change misses I think: When a PLAB does not fit the current allocation region, G1 releases that one (filling it with a dummy allocation). At the moment this might be up to half a region minus one word per allocated region. We know of applications where this is a problem, wasting a few regions per GC. What I merely suggest is to document somewhere that this can happen, is okay to happen, and possibly most importantly for end-users, that the sum of the PLAB allocation events (whether actual PLAB allocations or direct allocations) is not a reliable measure for getting total allocation information during GC in G1 (if this is actually one use of this data, which I am not sure). Maybe some additional event for PLABs and TLABs measuring fragmentation could be introduced. I expect this problem to increase if there are multiple allocation regions during GC. Thanks, Thomas On Mon, 2014-09-15 at 14:57 +0200, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-05 at 15:20 -0700, Staffan Friberg wrote: > > Hi, > > > > I have uploaded a new webrev here, > > cr.openjdk.java.net/~sfriberg/8055845/webrev.03 > > > > It contains several changes > > > > - Split event into two events (PromoteObjectInNewPLAB, > > PromoteObjectOutsidePLAB) > > - Moved events to "vm/gc/detailed/PromoteObject..." > > - Supporting ParNew+CMS and ParNew+SerialOld tenuring > > - Not sure if the way I do it with passing the ParNewTracer > > is the best solution, please let me know if you have an idea how to > > improve it > > - Simplified the G1 code to avoid sending age and having a single > > call site > > - Fixed so that the generated event has size information in bytes > > rather than words > > > > Thanks for offline comments and suggestions from Dmitry and Thomas. > > - in G1CollectedHeap::par_allocate_during_gc() I still think it is > required to do the !old->is_forwarded() check before retrieving the > old->age(), and so that there cannot be a reload of the mark header > between those. > > Also, if you look at oopDesc::age(), the first assert checks whether it > is not forwarded. Between the atomic claim by installing the forward > pointer and this reading of the age this might happen, so the assert may > trigger. > > So the change should either read the mark oop first (using a volatile > read), then do the is_forwarded() check and the retrieval of the age > value on that mark oop, do the even processing after the claiming of the > object (forward pointer installing) as suggested once, or (least > favourable to me) pass the markOop down. > > The latter messes up the method signatures, and in any case (when using > option one or three) this code is slightly racy as we might report too > many events as another thread might have claimed the object. (Parallel > Scavenge has the same issue, in addition to the possibility of sending > two events as Bengt describes). > > Please document the possibility of the race, and the workaround in these > locations. > > - another source of inaccuracy is that at the end of GC, G1 will make > the very last PLAB available for allocation in the next GC. And it may > do additional allocations to fill up the region (if there is not enough > useful space at the end of the allocation region), or fill up the old > gen allocation to the next card to avoid races in the next GC (see > G1CollectedHeap::release_gc_alloc_regions() and the release() methods of > the Survivor/OldGCAllocRegion classes. > > This, that JFR might get slightly too many events (or too few), should > be documented somewhere, probably in JFR/event documentation. At least > the sum of these allocations should not be used as the number of copied > bytes. > > - also maybe add a comment about the purpose of the "old" parameters > passed around. It is not obvious that a method that allocates a range of > bytes needs the value of the old memory block. Except for CMS, where it > is already used, the other non-G1 methods lack this documentation too. > > - please align the parameters in all calls to > gc_tracer->report_promotion_event(). > > - there is a superfluous space at the end of the line in > generation.hpp:326 > > Thanks, > Thomas > > > > From John.Coomes at oracle.com Mon Sep 15 17:43:12 2014 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 15 Sep 2014 10:43:12 -0700 Subject: review request (S) - 8058347: update allocation context stats In-Reply-To: <1930545.0WIRF0DptI@mgerdin03> References: <21523.31540.822447.513826@mykonos.us.oracle.com> <1930545.0WIRF0DptI@mgerdin03> Message-ID: <21527.9520.46440.428308@mykonos.us.oracle.com> Mikael Gerdin (mikael.gerdin at oracle.com) wrote: > Hi John, > > On Friday 12 September 2014 16.01.08 John Coomes wrote: > > Please review a minor api addition to the AllocationContextService > > class to check for and process gc requests. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058347-stats-request-highest/ > > Looks ok. Thanks. -John From John.Coomes at oracle.com Mon Sep 15 17:43:38 2014 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 15 Sep 2014 10:43:38 -0700 Subject: review request (S) - 8058347: update allocation context stats In-Reply-To: <1410774763.2803.29.camel@cirrus> References: <21523.31540.822447.513826@mykonos.us.oracle.com> <1410774763.2803.29.camel@cirrus> Message-ID: <21527.9546.72281.751894@mykonos.us.oracle.com> Thomas Schatzl (thomas.schatzl at oracle.com) wrote: > Hi, > > On Fri, 2014-09-12 at 16:01 -0700, John Coomes wrote: > > Please review a minor api addition to the AllocationContextService > > class to check for and process gc requests. > > > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058347-stats-request-highest/ > > > > -John > > looks okay. Thanks for taking a look at it. -John From tprintezis at twitter.com Mon Sep 15 17:52:50 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Mon, 15 Sep 2014 13:52:50 -0400 Subject: CRR (S): 8058495: G1: normalize names for isHumongous() and friends. Message-ID: <54172772.3090308@twitter.com> Hi all, This is a follow-up to JDK-8057768, proposed by Thomas. It normalizes some of the humongous-related method names (and enums). The changes are: HeapRegion::isHumongous() -> is_humongous() HeapRegion::startsHumongous() -> is_starts_humongous() HeapRegion::continuesHumongous() -> is_continues_humongous() HeapRegion::set_startsHumongous() -> set_starts_humongous() HeapRegion::set_continuesHumongous() -> set_continues_humongous() HeapRegionType::HumMask -> HumongousMask HeapRegionType::HumStartsTag -> StartsHumongousTag HeapRegionType::HumContTag -> ContinuesHumongousTag G1CollectedHeap::isHumongous() -> is_humongous() Webrev is here: http://cr.openjdk.java.net/~tonyp/8058495/webrev.0/ Could I get a couple of reviews please (and a sponsor!!!)? :-) Thanks, Tony -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From staffan.friberg at oracle.com Mon Sep 15 17:58:01 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 15 Sep 2014 10:58:01 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <5416D64C.9020207@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> Message-ID: <541728A9.4030103@oracle.com> Fixed, now checking the allocation result before sending event. I'm checking in all four instances, even if it is only necessary to check the direct allocation. If we get a new fresh PLAB I would expect the allocation to always succeed since we have checked the size before getting the PLAB. Thanks, Staffan On 09/15/2014 05:06 AM, Bengt Rutisson wrote: > > Hi Staffan, > > psPromotionManager.inline.hpp > > I think the PSPromotionManager::copy_to_survivor_space() might send > multiple events. If the allocation to the young gen fails we will fall > through to do an old gen allocation. But we send the events before we > realize that the allocation has failed, i.e. new_obj is NULL. > > I talked to Erik a bit about how to handle the gc_tracer in > par_promote. He'll get back to you with some thoughts on that. > > Thanks, > Bengt > > > On 2014-09-06 00:20, Staffan Friberg wrote: >> Hi, >> >> I have uploaded a new webrev here, >> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >> >> It contains several changes >> >> - Split event into two events (PromoteObjectInNewPLAB, >> PromoteObjectOutsidePLAB) >> - Moved events to "vm/gc/detailed/PromoteObject..." >> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >> - Not sure if the way I do it with passing the ParNewTracer >> is the best solution, please let me know if you have an idea how to >> improve it >> - Simplified the G1 code to avoid sending age and having a single >> call site >> - Fixed so that the generated event has size information in bytes >> rather than words >> >> Thanks for offline comments and suggestions from Dmitry and Thomas. >> >> Cheers, >> Staffan >> >> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>> Hi Erik, >>> >>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in >>>> this thread, I'm adding it back) >>>> >>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>> Hi Erik, >>>>> >>>>> Thanks for the comments. >>>>>> - Aren't the events for promotion to the tenured generation >>>>>> (SerialOld) >>>>>> and the CMS generation missing? >>>>> The reason for leaving out these two, Serial completely and CMS >>>>> promotion, was due to that neither as far as I understand make use of >>>>> PLABs. >>>> >>>> I might be wrong here, but looking at the function >>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks >>>> to me like SerialOld is using PLABs when ParNew is promoting >>>> objects from young to old. >>>> >>>> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote >>>> (in concurrentMarkSweepGeneration.cpp) it seems like each >>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local >>>> Allocation Buffer) that is a thread-local allocation buffer. See >>>> compactibleFreeListSpace.{hpp,cpp} for more details. >>>> >>>> Given this, I think we should add events for Serial and CMS as well. >>>> >>> >>> Ok I see what you mean with CMS, basically the equivalent to getting >>> a PLAB would be when we refill the CFLS_LAB in the alloc function. >>> It still does the allocation to a small memory (~ size of object) >>> area from the freelist, but at least we did extra work to refill the >>> local CFLS_LAB. Need to do some analysis to see how often we refill >>> so the overhead doesn't get too high. >>> The only issue I run into is how I can in a nice way get access to >>> the ParNewTracer from ParNewGeneration to call the report function. >>> Let's sync up next week and see how it can be solved. >>> >>> The tenured GC requires something similar to be supported, however >>> since ParNewGC is deprecated for usage without CMS in JDK 8 we might >>> want to skip that combination. >>> >>> >>>> >>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>> - Would it make sense to differentiate, either by separate events >>>>>> or by >>>>>> a field in a event, between promotions to to-space and to the old >>>>>> generation? >>>>>> - The are two events for TLAB allocations, >>>>>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>>>>> What do you think about using two events for PLAB allocations >>>>>> as well: >>>>>> - java/object_alloc_in_new_PLAB >>>>>> - java/object_alloc_outside_PLAB >>>>> I think this is a matter of taste and probably how similar we want >>>>> the >>>>> event to be to the existing allocation event. I personally prefer a >>>>> single event but if the GC team and serviceability team feel it >>>>> would be >>>>> better to have two I can certainly rewrite. The reason for me >>>>> preferring >>>>> a single event is just ease of analysis, you can easily filter a >>>>> list of >>>>> events on a field, it is harder to merge two different events with >>>>> different fields and work with them in an straight forward fashion. >>>>> >>>>> Any general preference for having a single or multiple events? >>>> >>>> I would prefer to have two events in this case and try to follow >>>> the existing allocation events as much as possible (both in naming >>>> and in style). Keeping the tenured field (I missed it the first >>>> time I read the patch) is good. >>>> >>> Yes, tenured would be independent of having two events, only PLAB >>> size and directAllocation would be affected when having two event types. >>> >>> *Erik Gahlin*, any preference from your end? >>> >>> >>> >>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>> - In PSPromotionManager, instead of utilizing the C++ friendship >>>>>> with >>>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>>> Created a getter function. >>>> >>>> Thanks! If you make report_promotion_sample const, then the getter >>>> can return a const ParallelScavengeTracer*, right? >>>> >>> Done >>> >>> //Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Mon Sep 15 19:31:32 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 15 Sep 2014 12:31:32 -0700 Subject: RFR (S): 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set In-Reply-To: <1410791084.2803.87.camel@cirrus> References: <1410791084.2803.87.camel@cirrus> Message-ID: I was lurking and noticed that you have a wrong bug number in the commit message. The fix looks good otherwise. igor On Sep 15, 2014, at 7:24 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following removal of the > -XX:-G1DeferredRSUpdate functionality? > > Problem is that the functionality of -XX:-G1DeferredRSUpdate is broken > (likely since forever): in case of evacuation failure there is the > possibility that some threads add remembered set entries (the ones > experiencing the to-space exhaustion) while other threads are still > iterating over the same remembered set. > > This can cause the iterators to skip remembered set entries, which in > turn causes lost objects. > > Since XX:-G1DeferredRSUpdate is a (rarely used) develop only flag, it is > not worth (imo) to try to fix this. There is no advantage of using the > current kind of remembered set in conjunction with immediate RSet > updates. If in the future any different RSet implementations were added, > these changes would be comparably easy to add again. > > Problem is that having it in the code (and testing it) occasionally > causes test failures. It is easiest to simply remove the functionality. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8052172 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8052172/webrev/ > Testing: > jprt > > Thanks, > Thomas > > From staffan.friberg at oracle.com Mon Sep 15 21:32:09 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 15 Sep 2014 14:32:09 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <1410797622.2803.147.camel@cirrus> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <1410785864.2803.71.camel@cirrus> <1410797622.2803.147.camel@cirrus> Message-ID: <54175AD9.1000508@oracle.com> Hi Thomas, I feel that this is outside of the scope of this event and change. It is probably a good thing to track to understand if an application wastes more memory than wanted. Perhaps open an RFE for a separate event and documentation? Similarly the TLAB/PLAB can waste memory when we get a new TLAB/PLAB for an object that didn't fit in the previous LAB. This information might make sense to include as an update to PLAB and TLAB event later. Cheers, Staffan On 09/15/2014 09:13 AM, Thomas Schatzl wrote: > Hi, > > one more allocation that is more serious that this change misses I > think: > > When a PLAB does not fit the current allocation region, G1 releases that > one (filling it with a dummy allocation). > > At the moment this might be up to half a region minus one word per > allocated region. We know of applications where this is a problem, > wasting a few regions per GC. > > What I merely suggest is to document somewhere that this can happen, is > okay to happen, and possibly most importantly for end-users, that the > sum of the PLAB allocation events (whether actual PLAB allocations or > direct allocations) is not a reliable measure for getting total > allocation information during GC in G1 (if this is actually one use of > this data, which I am not sure). > > Maybe some additional event for PLABs and TLABs measuring fragmentation > could be introduced. > > I expect this problem to increase if there are multiple allocation > regions during GC. > > Thanks, > Thomas > > On Mon, 2014-09-15 at 14:57 +0200, Thomas Schatzl wrote: >> Hi, >> >> On Fri, 2014-09-05 at 15:20 -0700, Staffan Friberg wrote: >>> Hi, >>> >>> I have uploaded a new webrev here, >>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>> >>> It contains several changes >>> >>> - Split event into two events (PromoteObjectInNewPLAB, >>> PromoteObjectOutsidePLAB) >>> - Moved events to "vm/gc/detailed/PromoteObject..." >>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>> - Not sure if the way I do it with passing the ParNewTracer >>> is the best solution, please let me know if you have an idea how to >>> improve it >>> - Simplified the G1 code to avoid sending age and having a single >>> call site >>> - Fixed so that the generated event has size information in bytes >>> rather than words >>> >>> Thanks for offline comments and suggestions from Dmitry and Thomas. >> - in G1CollectedHeap::par_allocate_during_gc() I still think it is >> required to do the !old->is_forwarded() check before retrieving the >> old->age(), and so that there cannot be a reload of the mark header >> between those. >> >> Also, if you look at oopDesc::age(), the first assert checks whether it >> is not forwarded. Between the atomic claim by installing the forward >> pointer and this reading of the age this might happen, so the assert may >> trigger. >> >> So the change should either read the mark oop first (using a volatile >> read), then do the is_forwarded() check and the retrieval of the age >> value on that mark oop, do the even processing after the claiming of the >> object (forward pointer installing) as suggested once, or (least >> favourable to me) pass the markOop down. >> >> The latter messes up the method signatures, and in any case (when using >> option one or three) this code is slightly racy as we might report too >> many events as another thread might have claimed the object. (Parallel >> Scavenge has the same issue, in addition to the possibility of sending >> two events as Bengt describes). >> >> Please document the possibility of the race, and the workaround in these >> locations. >> >> - another source of inaccuracy is that at the end of GC, G1 will make >> the very last PLAB available for allocation in the next GC. And it may >> do additional allocations to fill up the region (if there is not enough >> useful space at the end of the allocation region), or fill up the old >> gen allocation to the next card to avoid races in the next GC (see >> G1CollectedHeap::release_gc_alloc_regions() and the release() methods of >> the Survivor/OldGCAllocRegion classes. >> >> This, that JFR might get slightly too many events (or too few), should >> be documented somewhere, probably in JFR/event documentation. At least >> the sum of these allocations should not be used as the number of copied >> bytes. >> >> - also maybe add a comment about the purpose of the "old" parameters >> passed around. It is not obvious that a method that allocates a range of >> bytes needs the value of the old memory block. Except for CMS, where it >> is already used, the other non-G1 methods lack this documentation too. >> >> - please align the parameters in all calls to >> gc_tracer->report_promotion_event(). >> >> - there is a superfluous space at the end of the line in >> generation.hpp:326 >> >> Thanks, >> Thomas >> >> >> >> > From staffan.friberg at oracle.com Mon Sep 15 21:44:58 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 15 Sep 2014 14:44:58 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <1410785864.2803.71.camel@cirrus> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <1410785864.2803.71.camel@cirrus> Message-ID: <54175DDA.1050203@oracle.com> Hi, Uploaded a new webrev, with the changes from your comments here and from Bengt's email. http://cr.openjdk.java.net/~sfriberg/8055845/webrev.04 See inline for comments. On 09/15/2014 05:57 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-05 at 15:20 -0700, Staffan Friberg wrote: >> Hi, >> >> I have uploaded a new webrev here, >> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >> >> It contains several changes >> >> - Split event into two events (PromoteObjectInNewPLAB, >> PromoteObjectOutsidePLAB) >> - Moved events to "vm/gc/detailed/PromoteObject..." >> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >> - Not sure if the way I do it with passing the ParNewTracer >> is the best solution, please let me know if you have an idea how to >> improve it >> - Simplified the G1 code to avoid sending age and having a single >> call site >> - Fixed so that the generated event has size information in bytes >> rather than words >> >> Thanks for offline comments and suggestions from Dmitry and Thomas. > - in G1CollectedHeap::par_allocate_during_gc() I still think it is > required to do the !old->is_forwarded() check before retrieving the > old->age(), and so that there cannot be a reload of the mark header > between those. > > Also, if you look at oopDesc::age(), the first assert checks whether it > is not forwarded. Between the atomic claim by installing the forward > pointer and this reading of the age this might happen, so the assert may > trigger. > > So the change should either read the mark oop first (using a volatile > read), then do the is_forwarded() check and the retrieval of the age > value on that mark oop, do the even processing after the claiming of the > object (forward pointer installing) as suggested once, or (least > favourable to me) pass the markOop down. > > The latter messes up the method signatures, and in any case (when using > option one or three) this code is slightly racy as we might report too > many events as another thread might have claimed the object. (Parallel > Scavenge has the same issue, in addition to the possibility of sending > two events as Bengt describes). Good catch with the assert had missed that, will read it similar to how it is done G1ParScanThreadState::copy_to_survivor_space instead, which avoids the assert. I think the best way would be to read the age and then check is_forwarded, like now but without the assert issue. If is_forwarded is false the read age will be OK to use, if it is true it might be a valid age or overwritten by the forward, but I won't be using it so that is fine. It would still have the risk of not actually doing the copying later, but at least all the data about the object should be correct at this point. if (result != NULL && _gc_tracer_stw->should_report_promotion_event()) { markOop m = old->mark(); uint age = m->has_displaced_mark_helper() ? m->displaced_mark_helper()->age() : m->age(); // Check if object has already been promoted by another thread if (!old->is_forwarded()) { _gc_tracer_stw->report_promotion_event(old, age, !heap_region_containing_raw(result)->is_young(), word_size); } } I don't follow why you would like the age to be read after the is_forwarded. Trusting the age is my main concern here and reading it prior to the is_forward check I think would solve that. Could you expand on this further? > > Please document the possibility of the race, and the workaround in these > locations. > > - another source of inaccuracy is that at the end of GC, G1 will make > the very last PLAB available for allocation in the next GC. And it may > do additional allocations to fill up the region (if there is not enough > useful space at the end of the allocation region), or fill up the old > gen allocation to the next card to avoid races in the next GC (see > G1CollectedHeap::release_gc_alloc_regions() and the release() methods of > the Survivor/OldGCAllocRegion classes. > > This, that JFR might get slightly too many events (or too few), should > be documented somewhere, probably in JFR/event documentation. At least > the sum of these allocations should not be used as the number of copied > bytes. I think the total number of allocated PLABs should be OK as I don't think we ever return a PLAB. But as you say we might count a single object twice or more if it end up requiring a new PLAB in multiple threads. Added the following to the description of the two events "Due to promotion being done in parallel an object might be reported multiple times as the GC threads race to copy all objects." > - also maybe add a comment about the purpose of the "old" parameters > passed around. It is not obvious that a method that allocates a range of > bytes needs the value of the old memory block. Except for CMS, where it > is already used, the other non-G1 methods lack this documentation too. > > - please align the parameters in all calls to > gc_tracer->report_promotion_event(). > > - there is a superfluous space at the end of the line in > generation.hpp:326 Done Cheers, Staffan From staffan.friberg at oracle.com Mon Sep 15 22:31:29 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 15 Sep 2014 15:31:29 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <54137E92.4030803@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> Message-ID: <541768C1.20507@oracle.com> Hi Vladimir, Uploaded a new webrev with fixes to the below issues, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 Still removes expected barriers. Thanks, Staffan On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: > Fix indention in 2 checks: > > + if (use_ReduceInitialCardMarks() && > + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { > > Typo 'iff' in both comments: > > + * Returns true iff the barrier can be removed > > In g1_can_remove_post_barrier() use: > > + // Start search from Store node > + Node* ctrl = store->in(MemNode::Control); > > Control edge can't point to an other Store so you should not check it > inside loop. > As result you don't need loop. > > Thanks, > Vladimir > > On 9/12/14 2:26 PM, Staffan Friberg wrote: >> Hi Mikael, >> >> I updated the documentation, and uploaded a new webrev, >> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >> >> Thanks for agreeing to sponsor, and the good idea about pushing to >> hs-gc for extra coverage. >> >> Thanks, >> Staffan >> >> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>> Hi Staffan, >>> >>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>> Hi, >>>> >>>> Copying both the compiler and GC alias as the optimization involves >>>> both >>>> groups. >>>> >>>> This optimization aims to avoid generating G1 barriers for newly >>>> allocated objects where the compiler can prove that the object has not >>>> been written to earlier and there is no safepoint between the >>>> allocation >>>> and the write. The bug has some further details and microbenchmark >>>> result. The new code has fairly extensive comments about the >>>> optimization. >>>> >>>> It would be great if the GC team can help validate that the premise of >>>> the optimization is correct as well. >>>> >>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>> I mostly read through the comments since I can't decode what the IR >>> transforms >>> intend to do :) >>> >>> We usually stick to the terms "old generation" and "young >>> generation" instead >>> of "Old Space" and "Young Space". >>> >>> "G1 also requires to keep track of objects between different >>> + * regions to enable evacuation of old regions" >>> should probably be. >>> .."to keep track of references between different regions" >>> >>> I leave it to the compiler team to review the actual code changes. >>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>> >>>> I would also need a sponsor for this change if it passes review. >>> I'll push this to hs-gc after review since we have more G1 test >>> coverage on >>> hs-gc. >>> >>> /Mikael >>> >>>> Thanks, >>>> Staffan >> From vladimir.kozlov at oracle.com Tue Sep 16 00:55:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Sep 2014 17:55:34 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <541768C1.20507@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> Message-ID: <54178A86.4090500@oracle.com> You need only check (alloc == st_alloc) because alloc != NULL at this point: + if (st_alloc != NULL && alloc == st_alloc) { You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == NULL check). I would also reverse the last check there because you bailout from loop anyway: + if (captured_store == NULL || captured_store == st_init->zero_memory()) { + return true; + } + } + } + + // Unless there is an explicit 'continue', we must bail out here, Vladimir On 9/15/14 3:31 PM, Staffan Friberg wrote: > Hi Vladimir, > > Uploaded a new webrev with fixes to the below issues, > http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 > > Still removes expected barriers. > > Thanks, > Staffan > > On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >> Fix indention in 2 checks: >> >> + if (use_ReduceInitialCardMarks() && >> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >> >> Typo 'iff' in both comments: >> >> + * Returns true iff the barrier can be removed >> >> In g1_can_remove_post_barrier() use: >> >> + // Start search from Store node >> + Node* ctrl = store->in(MemNode::Control); >> >> Control edge can't point to an other Store so you should not check it >> inside loop. >> As result you don't need loop. >> >> Thanks, >> Vladimir >> >> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>> Hi Mikael, >>> >>> I updated the documentation, and uploaded a new webrev, >>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>> >>> Thanks for agreeing to sponsor, and the good idea about pushing to >>> hs-gc for extra coverage. >>> >>> Thanks, >>> Staffan >>> >>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>> Hi Staffan, >>>> >>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> Copying both the compiler and GC alias as the optimization involves >>>>> both >>>>> groups. >>>>> >>>>> This optimization aims to avoid generating G1 barriers for newly >>>>> allocated objects where the compiler can prove that the object has not >>>>> been written to earlier and there is no safepoint between the >>>>> allocation >>>>> and the write. The bug has some further details and microbenchmark >>>>> result. The new code has fairly extensive comments about the >>>>> optimization. >>>>> >>>>> It would be great if the GC team can help validate that the premise of >>>>> the optimization is correct as well. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>> I mostly read through the comments since I can't decode what the IR >>>> transforms >>>> intend to do :) >>>> >>>> We usually stick to the terms "old generation" and "young >>>> generation" instead >>>> of "Old Space" and "Young Space". >>>> >>>> "G1 also requires to keep track of objects between different >>>> + * regions to enable evacuation of old regions" >>>> should probably be. >>>> .."to keep track of references between different regions" >>>> >>>> I leave it to the compiler team to review the actual code changes. >>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>> >>>>> I would also need a sponsor for this change if it passes review. >>>> I'll push this to hs-gc after review since we have more G1 test >>>> coverage on >>>> hs-gc. >>>> >>>> /Mikael >>>> >>>>> Thanks, >>>>> Staffan >>> > From thomas.schatzl at oracle.com Tue Sep 16 07:36:10 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 09:36:10 +0200 Subject: RFR (S): 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set In-Reply-To: References: <1410791084.2803.87.camel@cirrus> Message-ID: <1410852970.2755.0.camel@cirrus> Hi Igor, On Mon, 2014-09-15 at 12:31 -0700, Igor Veresov wrote: > I was lurking and noticed that you have a wrong bug number in the commit message. > The fix looks good otherwise. > thanks for the review. I updated the existing webrev with the fixed commit message. Thanks, Thomas From bengt.rutisson at oracle.com Tue Sep 16 07:42:40 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Sep 2014 09:42:40 +0200 Subject: RFR (S): 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set In-Reply-To: <1410852970.2755.0.camel@cirrus> References: <1410791084.2803.87.camel@cirrus> <1410852970.2755.0.camel@cirrus> Message-ID: <5417E9F0.4000100@oracle.com> Hi Thomas, Looks good. Thanks for fixing this! Bengt On 2014-09-16 09:36, Thomas Schatzl wrote: > Hi Igor, > > On Mon, 2014-09-15 at 12:31 -0700, Igor Veresov wrote: >> I was lurking and noticed that you have a wrong bug number in the commit message. >> The fix looks good otherwise. >> > thanks for the review. > > I updated the existing webrev with the fixed commit message. > > Thanks, > Thomas > > > From thomas.schatzl at oracle.com Tue Sep 16 07:54:07 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 09:54:07 +0200 Subject: RFR: 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr In-Reply-To: <5416F23B.6090307@oracle.com> References: <5416F23B.6090307@oracle.com> Message-ID: <1410854047.2755.1.camel@cirrus> Hi, On Mon, 2014-09-15 at 16:05 +0200, Stefan Karlsson wrote: > Hi all, > > > Please review this patch to make TestCMSClassUnloadingEnabledHWM more > stable. Instead of trying to bootstrap the initial mark with young GCs, > just wait for the concurrent cycle to start. I've lowered some CMS > specific flags to make this test run faster. > > http://cr.openjdk.java.net/~stefank/8058475/webrev.00/ > looks good. Agree with Mikael about the class.getName(). No need for re-review too. Thanks, Thomas From thomas.schatzl at oracle.com Tue Sep 16 07:57:43 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 09:57:43 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <54175AD9.1000508@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <1410785864.2803.71.camel@cirrus> <1410797622.2803.147.camel@cirrus> <54175AD9.1000508@oracle.com> Message-ID: <1410854263.2755.4.camel@cirrus> Hi, On Mon, 2014-09-15 at 14:32 -0700, Staffan Friberg wrote: > Hi Thomas, > > I feel that this is outside of the scope of this event and change. It is > probably a good thing to track to understand if an application wastes > more memory than wanted. > Perhaps open an RFE for a separate event and documentation? > > Similarly the TLAB/PLAB can waste memory when we get a new TLAB/PLAB for > an object that didn't fit in the previous LAB. This information might > make sense to include as an update to PLAB and TLAB event later. New RFEs are fine for me. Thanks, Thomas From bengt.rutisson at oracle.com Tue Sep 16 07:52:03 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Sep 2014 09:52:03 +0200 Subject: RFR: 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr In-Reply-To: <1410854047.2755.1.camel@cirrus> References: <5416F23B.6090307@oracle.com> <1410854047.2755.1.camel@cirrus> Message-ID: <5417EC23.6070007@oracle.com> On 2014-09-16 09:54, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-09-15 at 16:05 +0200, Stefan Karlsson wrote: >> Hi all, >> >> >> Please review this patch to make TestCMSClassUnloadingEnabledHWM more >> stable. Instead of trying to bootstrap the initial mark with young GCs, >> just wait for the concurrent cycle to start. I've lowered some CMS >> specific flags to make this test run faster. >> >> http://cr.openjdk.java.net/~stefank/8058475/webrev.00/ >> > looks good. Agree with Mikael about the class.getName(). No need for > re-review too. +1 Looks good. Bengt > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Tue Sep 16 08:13:12 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 16 Sep 2014 10:13:12 +0200 Subject: RFR (S): 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set In-Reply-To: <5417E9F0.4000100@oracle.com> References: <1410791084.2803.87.camel@cirrus> <1410852970.2755.0.camel@cirrus> <5417E9F0.4000100@oracle.com> Message-ID: <2522650.6O3r4y3FEt@mgerdin03> On Tuesday 16 September 2014 09.42.40 Bengt Rutisson wrote: > Hi Thomas, > > Looks good. > > Thanks for fixing this! +1 /Mikael > > Bengt > > On 2014-09-16 09:36, Thomas Schatzl wrote: > > Hi Igor, > > > > On Mon, 2014-09-15 at 12:31 -0700, Igor Veresov wrote: > >> I was lurking and noticed that you have a wrong bug number in the commit > >> message. The fix looks good otherwise. > >> > > thanks for the review. > > > > I updated the existing webrev with the fixed commit message. > > > > Thanks, > > > > Thomas From thomas.schatzl at oracle.com Tue Sep 16 08:15:40 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 10:15:40 +0200 Subject: RFR (S): 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set In-Reply-To: <2522650.6O3r4y3FEt@mgerdin03> References: <1410791084.2803.87.camel@cirrus> <1410852970.2755.0.camel@cirrus> <5417E9F0.4000100@oracle.com> <2522650.6O3r4y3FEt@mgerdin03> Message-ID: <1410855340.2755.6.camel@cirrus> Hi, On Tue, 2014-09-16 at 10:13 +0200, Mikael Gerdin wrote: > On Tuesday 16 September 2014 09.42.40 Bengt Rutisson wrote: > > Hi Thomas, > > > > Looks good. > > > > Thanks for fixing this! > > +1 > > /Mikael Thanks Bengt, Mikael for the reviews. Thanks, Thomas From thomas.schatzl at oracle.com Tue Sep 16 08:47:01 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 10:47:01 +0200 Subject: CRR (S): 8058495: G1: normalize names for isHumongous() and friends. In-Reply-To: <54172772.3090308@twitter.com> References: <54172772.3090308@twitter.com> Message-ID: <1410857221.2755.9.camel@cirrus> Hi, On Mon, 2014-09-15 at 13:52 -0400, Tony Printezis wrote: > Hi all, > > This is a follow-up to JDK-8057768, proposed by Thomas. It normalizes > some of the humongous-related method names (and enums). The changes are: > > HeapRegion::isHumongous() -> is_humongous() > HeapRegion::startsHumongous() -> is_starts_humongous() > HeapRegion::continuesHumongous() -> is_continues_humongous() > > HeapRegion::set_startsHumongous() -> set_starts_humongous() > HeapRegion::set_continuesHumongous() -> set_continues_humongous() > > HeapRegionType::HumMask -> HumongousMask > HeapRegionType::HumStartsTag -> StartsHumongousTag > HeapRegionType::HumContTag -> ContinuesHumongousTag > > G1CollectedHeap::isHumongous() -> is_humongous() > > Webrev is here: > > http://cr.openjdk.java.net/~tonyp/8058495/webrev.0/ > > Could I get a couple of reviews please (and a sponsor!!!)? :-) looks good. Thanks, Thomas From stefan.karlsson at oracle.com Tue Sep 16 08:51:35 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 16 Sep 2014 10:51:35 +0200 Subject: RFR: 8058481: Test gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java was removed, but TEST.groups still refers to it Message-ID: <5417FA17.1090806@oracle.com> Hi all, Please review this small 8u40 patch to update the test name in TEST.groups. http://cr.openjdk.java.net/~stefank/8058481/webrev.00/ thanks, StefanK From thomas.schatzl at oracle.com Tue Sep 16 09:05:05 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 11:05:05 +0200 Subject: RFR: 8058481: Test gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java was removed, but TEST.groups still refers to it In-Reply-To: <5417FA17.1090806@oracle.com> References: <5417FA17.1090806@oracle.com> Message-ID: <1410858305.2755.12.camel@cirrus> Hi, On Tue, 2014-09-16 at 10:51 +0200, Stefan Karlsson wrote: > Hi all, > > Please review this small 8u40 patch to update the test name in TEST.groups. > > http://cr.openjdk.java.net/~stefank/8058481/webrev.00/ > looks good. Thomas From filipp.zhinkin at oracle.com Tue Sep 16 09:05:24 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 16 Sep 2014 13:05:24 +0400 Subject: RFR: 8058481: Test gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java was removed, but TEST.groups still refers to it In-Reply-To: <5417FA17.1090806@oracle.com> References: <5417FA17.1090806@oracle.com> Message-ID: <5417FD54.9010603@oracle.com> Hi Stefan, the change looks good, thank you for fixing it! Regards, Filipp. On 09/16/2014 12:51 PM, Stefan Karlsson wrote: > Hi all, > > Please review this small 8u40 patch to update the test name in TEST.groups. > > http://cr.openjdk.java.net/~stefank/8058481/webrev.00/ > > thanks, > StefanK > From stefan.karlsson at oracle.com Tue Sep 16 09:02:13 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 16 Sep 2014 11:02:13 +0200 Subject: RFR: 8058481: Test gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java was removed, but TEST.groups still refers to it In-Reply-To: <5417FA17.1090806@oracle.com> References: <5417FA17.1090806@oracle.com> Message-ID: <5417FC95.5000104@oracle.com> Thanks for the review Thomas and Filipp. thanks, StefanK On 2014-09-16 10:51, Stefan Karlsson wrote: > Hi all, > > Please review this small 8u40 patch to update the test name in > TEST.groups. > > http://cr.openjdk.java.net/~stefank/8058481/webrev.00/ > > thanks, > StefanK > From stefan.karlsson at oracle.com Tue Sep 16 09:06:02 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 16 Sep 2014 11:06:02 +0200 Subject: RFR: 8058475: TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr In-Reply-To: <5416F23B.6090307@oracle.com> References: <5416F23B.6090307@oracle.com> Message-ID: <5417FD7A.8030709@oracle.com> Thanks for the reviews, Mikael, Bengt, and Thomas. StefanK On 2014-09-15 16:05, Stefan Karlsson wrote: > Hi all, > > > Please review this patch to make TestCMSClassUnloadingEnabledHWM more > stable. Instead of trying to bootstrap the initial mark with young > GCs, just wait for the concurrent cycle to start. I've lowered some > CMS specific flags to make this test run faster. > > http://cr.openjdk.java.net/~stefank/8058475/webrev.00/ > > thanks, > StefanK From mikael.gerdin at oracle.com Tue Sep 16 09:17:04 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 16 Sep 2014 11:17:04 +0200 Subject: RFR: 8058481: Test gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java was removed, but TEST.groups still refers to it In-Reply-To: <1410858305.2755.12.camel@cirrus> References: <5417FA17.1090806@oracle.com> <1410858305.2755.12.camel@cirrus> Message-ID: <16408603.hitlIaSHNq@mgerdin03> On Tuesday 16 September 2014 11.05.05 Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-16 at 10:51 +0200, Stefan Karlsson wrote: > > Hi all, > > > > Please review this small 8u40 patch to update the test name in > > TEST.groups. > > > > http://cr.openjdk.java.net/~stefank/8058481/webrev.00/ Looks good. /Mikael > > looks good. > > Thomas From bengt.rutisson at oracle.com Tue Sep 16 12:01:57 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Sep 2014 14:01:57 +0200 Subject: RFR: [backport] 8057768: Make heap region region type in G1 HeapRegion explicit Message-ID: <541826B5.2070501@oracle.com> Hi all, I'd like to backport this change: JDK-8057768: Make heap region region type in G1 HeapRegion explicit There were some minor merge conflicts, so I need reviews before I push. Here is the complete webrev for the 8u repo: http://cr.openjdk.java.net/~brutisso/8057768/webrev.00/ Here is the patch that was pushed to the JDK 9 repo: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 Here is the diff with the merge conflicts that I had to resolve: http://cr.openjdk.java.net/~brutisso/8057768/webrev.00.diff/ Thanks, Bengt From thomas.schatzl at oracle.com Tue Sep 16 12:21:08 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 14:21:08 +0200 Subject: RFR: [backport] 8057768: Make heap region region type in G1 HeapRegion explicit In-Reply-To: <541826B5.2070501@oracle.com> References: <541826B5.2070501@oracle.com> Message-ID: <1410870068.2755.24.camel@cirrus> Hi, On Tue, 2014-09-16 at 14:01 +0200, Bengt Rutisson wrote: > Hi all, > > I'd like to backport this change: > > JDK-8057768: Make heap region region type in G1 HeapRegion explicit > > There were some minor merge conflicts, so I need reviews before I push. > > Here is the complete webrev for the 8u repo: > http://cr.openjdk.java.net/~brutisso/8057768/webrev.00/ > > Here is the patch that was pushed to the JDK 9 repo: > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 > > Here is the diff with the merge conflicts that I had to resolve: > http://cr.openjdk.java.net/~brutisso/8057768/webrev.00.diff/ still looks good. Thanks, Thomas From bengt.rutisson at oracle.com Tue Sep 16 12:26:00 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Sep 2014 14:26:00 +0200 Subject: CRR (S): 8058495: G1: normalize names for isHumongous() and friends. In-Reply-To: <54172772.3090308@twitter.com> References: <54172772.3090308@twitter.com> Message-ID: <54182C58.7020708@oracle.com> Hi Tony, On 2014-09-15 19:52, Tony Printezis wrote: > Hi all, > > This is a follow-up to JDK-8057768, proposed by Thomas. It normalizes > some of the humongous-related method names (and enums). The changes are: > > HeapRegion::isHumongous() -> is_humongous() > HeapRegion::startsHumongous() -> is_starts_humongous() > HeapRegion::continuesHumongous() -> is_continues_humongous() > > HeapRegion::set_startsHumongous() -> set_starts_humongous() > HeapRegion::set_continuesHumongous() -> set_continues_humongous() > > HeapRegionType::HumMask -> HumongousMask > HeapRegionType::HumStartsTag -> StartsHumongousTag > HeapRegionType::HumContTag -> ContinuesHumongousTag > > G1CollectedHeap::isHumongous() -> is_humongous() > > Webrev is here: > > http://cr.openjdk.java.net/~tonyp/8058495/webrev.0/ Looks good. > > Could I get a couple of reviews please (and a sponsor!!!)? :-) I can sponsor this. In order to avoid some merge conflicts I may wait a couple of days before I push. But I'll handle it soon. Thanks, Bengt > > Thanks, > > Tony > From bengt.rutisson at oracle.com Tue Sep 16 12:29:34 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Sep 2014 14:29:34 +0200 Subject: RFR: [backport] 8057768: Make heap region region type in G1 HeapRegion explicit In-Reply-To: <1410870068.2755.24.camel@cirrus> References: <541826B5.2070501@oracle.com> <1410870068.2755.24.camel@cirrus> Message-ID: <54182D2E.9030405@oracle.com> Hi Thomas, On 2014-09-16 14:21, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-09-16 at 14:01 +0200, Bengt Rutisson wrote: >> Hi all, >> >> I'd like to backport this change: >> >> JDK-8057768: Make heap region region type in G1 HeapRegion explicit >> >> There were some minor merge conflicts, so I need reviews before I push. >> >> Here is the complete webrev for the 8u repo: >> http://cr.openjdk.java.net/~brutisso/8057768/webrev.00/ >> >> Here is the patch that was pushed to the JDK 9 repo: >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 >> >> Here is the diff with the merge conflicts that I had to resolve: >> http://cr.openjdk.java.net/~brutisso/8057768/webrev.00.diff/ > still looks good. Thanks! Bengt > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Sep 16 13:06:36 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 15:06:36 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over In-Reply-To: <5412E184.70700@oracle.com> References: <5412E184.70700@oracle.com> Message-ID: <1410872796.2755.45.camel@cirrus> Hi Marcus, On Fri, 2014-09-12 at 14:05 +0200, Marcus Larsson wrote: > Hi, > > I would like reviews for the following refactorization to separate the > heap region claiming from the actual heap region data structure. This > allows concurrent tasks to claim heap regions independent of each other. > > The patch adds a HeapRegionClaimer that should be used for parallel > iteration over heap regions, and will handle the claims for a certain > task. The previous claim field and its associated functions in > HeapRegion is removed. > > Webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8058298/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8058298 > > Testing: > jprt > local UTE vm.gc.testlist > SPECjbb2013 a few notes: - there is no Atomic::cmpxchg() for uint, only jint (iirc!). Please change the type for HeapRegionClaimer::_claims accordingly. - HeapRegionClaimer should inherit from StackObj - I think you everything but is_region_claimed() and claim_region() could be moved to the cpp file without problems. I think even moving those two too would not matter given that a HeapRegion is a relatively coarse unit of work. Actually I was not able to compile a patched VM without moving at least HeapRegionClaimer::initialize() to a cpp file when using USE_PRECOMPILED_HEADER=0. - in HeapRegionClaimer::HeapRegionClaimer(uint), the method body is indented two spaces too many. - I would see the HeapRegionClaimer as part of the parallel iteration, so better located with the HeapRegionManager class. Also, the need for the number of regions (_allocated_heapregions_length) indicates that. It does not reference HeapRegion at all too. - maybe in a future RFE we could make the HeapRegionClaimer a real iterator. I already like that this change removes a lot of code though. Looks good otherwise. Thanks, Thomas From tprintezis at twitter.com Tue Sep 16 13:17:31 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 16 Sep 2014 09:17:31 -0400 Subject: CRR (S): 8058495: G1: normalize names for isHumongous() and friends. In-Reply-To: <54182C58.7020708@oracle.com> References: <54172772.3090308@twitter.com> <54182C58.7020708@oracle.com> Message-ID: <5418386B.3050007@twitter.com> Thomas and Bengt, Thanks! Bengt, I'll also be happy to bring the patch up-to-date after a few specific changesets go in. Feel free to ping me when it's appropriate. Tony On 9/16/14, 8:26 AM, Bengt Rutisson wrote: > > Hi Tony, > > On 2014-09-15 19:52, Tony Printezis wrote: >> Hi all, >> >> This is a follow-up to JDK-8057768, proposed by Thomas. It normalizes >> some of the humongous-related method names (and enums). The changes are: >> >> HeapRegion::isHumongous() -> is_humongous() >> HeapRegion::startsHumongous() -> is_starts_humongous() >> HeapRegion::continuesHumongous() -> is_continues_humongous() >> >> HeapRegion::set_startsHumongous() -> set_starts_humongous() >> HeapRegion::set_continuesHumongous() -> set_continues_humongous() >> >> HeapRegionType::HumMask -> HumongousMask >> HeapRegionType::HumStartsTag -> StartsHumongousTag >> HeapRegionType::HumContTag -> ContinuesHumongousTag >> >> G1CollectedHeap::isHumongous() -> is_humongous() >> >> Webrev is here: >> >> http://cr.openjdk.java.net/~tonyp/8058495/webrev.0/ > > Looks good. > >> >> Could I get a couple of reviews please (and a sponsor!!!)? :-) > > I can sponsor this. In order to avoid some merge conflicts I may wait > a couple of days before I push. But I'll handle it soon. > > Thanks, > Bengt > > >> >> Thanks, >> >> Tony >> > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From tprintezis at twitter.com Tue Sep 16 13:24:58 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 16 Sep 2014 09:24:58 -0400 Subject: RFR: [backport] 8057768: Make heap region region type in G1 HeapRegion explicit In-Reply-To: <541826B5.2070501@oracle.com> References: <541826B5.2070501@oracle.com> Message-ID: <54183A2A.9050204@twitter.com> Ship it. Tony On 9/16/14, 8:01 AM, Bengt Rutisson wrote: > > Hi all, > > I'd like to backport this change: > > JDK-8057768: Make heap region region type in G1 HeapRegion explicit > > There were some minor merge conflicts, so I need reviews before I push. > > Here is the complete webrev for the 8u repo: > http://cr.openjdk.java.net/~brutisso/8057768/webrev.00/ > > Here is the patch that was pushed to the JDK 9 repo: > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 > > Here is the diff with the merge conflicts that I had to resolve: > http://cr.openjdk.java.net/~brutisso/8057768/webrev.00.diff/ > > Thanks, > Bengt -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From thomas.schatzl at oracle.com Tue Sep 16 13:41:30 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 15:41:30 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <54175DDA.1050203@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <1410785864.2803.71.camel@cirrus> <54175DDA.1050203@oracle.com> Message-ID: <1410874890.2755.66.camel@cirrus> Hi, On Mon, 2014-09-15 at 14:44 -0700, Staffan Friberg wrote: > Hi, > > The latter messes up the method signatures, and in any case (when using > > option one or three) this code is slightly racy as we might report too > > many events as another thread might have claimed the object. (Parallel > > Scavenge has the same issue, in addition to the possibility of sending > > two events as Bengt describes). > Good catch with the assert had missed that, will read it similar to how > it is done G1ParScanThreadState::copy_to_survivor_space instead, which > avoids the assert. > Maybe the change could introduce a method without the assert and use it instead of repeating this all the time? Reading the age from a mark oop without caring about the assert seems to be done in a few places now. > I think the best way would be to read the age and then check > is_forwarded, like now but without the assert issue. If is_forwarded is > false the read age will be OK to use, if it is true it might be a valid > age or overwritten by the forward, but I won't be using it so that is > fine. It would still have the risk of not actually doing the copying > later, but at least all the data about the object should be correct at > this point. > > > if (result != NULL && _gc_tracer_stw->should_report_promotion_event()) { > markOop m = old->mark(); > uint age = m->has_displaced_mark_helper() ? > m->displaced_mark_helper()->age() > : m->age(); > // Check if object has already been promoted by another thread > if (!old->is_forwarded()) { > _gc_tracer_stw->report_promotion_event(old, age, > !heap_region_containing_raw(result)->is_young(), word_size); > } > } > > > I don't follow why you would like the age to be read after the > is_forwarded. Trusting the age is my main concern here and reading it > prior to the is_forward check I think would solve that. Could you expand > on this further? Instead of first getting the markOop like the code does in this latest version, this would have avoided the assertion failure too. The latest change looks okay now if the tradeoffs are acceptable. Thanks, Thomas From thomas.schatzl at oracle.com Tue Sep 16 14:07:52 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Sep 2014 16:07:52 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over In-Reply-To: <1410872796.2755.45.camel@cirrus> References: <5412E184.70700@oracle.com> <1410872796.2755.45.camel@cirrus> Message-ID: <1410876472.2755.67.camel@cirrus> Hi again, On Tue, 2014-09-16 at 15:06 +0200, Thomas Schatzl wrote: > Hi Marcus, > > On Fri, 2014-09-12 at 14:05 +0200, Marcus Larsson wrote: > > Hi, > > > > I would like reviews for the following refactorization to separate the > > heap region claiming from the actual heap region data structure. This > > allows concurrent tasks to claim heap regions independent of each other. [...] > > Testing: > > jprt > > local UTE vm.gc.testlist > > SPECjbb2013 > > a few notes: > > - there is no Atomic::cmpxchg() for uint, only jint (iirc!). Please > change the type for HeapRegionClaimer::_claims accordingly. There is actually an Atomic::cmpxchg() for uint, so skip this. Thomas From bengt.rutisson at oracle.com Tue Sep 16 14:56:57 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Sep 2014 16:56:57 +0200 Subject: RFR: [backport] 8057768: Make heap region region type in G1 HeapRegion explicit In-Reply-To: <54183A2A.9050204@twitter.com> References: <541826B5.2070501@oracle.com> <54183A2A.9050204@twitter.com> Message-ID: <54184FB9.1060302@oracle.com> Thanks for the reviews Thomas and Tony. The change is now in the 8u repo: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/bdd2310490aa Bengt On 2014-09-16 15:24, Tony Printezis wrote: > Ship it. > > Tony > > On 9/16/14, 8:01 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> I'd like to backport this change: >> >> JDK-8057768: Make heap region region type in G1 HeapRegion explicit >> >> There were some minor merge conflicts, so I need reviews before I push. >> >> Here is the complete webrev for the 8u repo: >> http://cr.openjdk.java.net/~brutisso/8057768/webrev.00/ >> >> Here is the patch that was pushed to the JDK 9 repo: >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/13c5569c0fc4 >> >> Here is the diff with the merge conflicts that I had to resolve: >> http://cr.openjdk.java.net/~brutisso/8057768/webrev.00.diff/ >> >> Thanks, >> Bengt > From staffan.friberg at oracle.com Tue Sep 16 21:41:25 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 16 Sep 2014 14:41:25 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <54178A86.4090500@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> <54178A86.4090500@oracle.com> Message-ID: <5418AE85.1070309@oracle.com> Thanks Vladimir, Updated with your suggestions. Added a small comment in g1_can_remove_pre_barrier method since the alloc == NULL check is quite a bit earlier. New webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.03 Cheers, Staffan On 09/15/2014 05:55 PM, Vladimir Kozlov wrote: > You need only check (alloc == st_alloc) because alloc != NULL at this > point: > > + if (st_alloc != NULL && alloc == st_alloc) { > > > You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == > NULL check). > > I would also reverse the last check there because you bailout from > loop anyway: > > + if (captured_store == NULL || captured_store == > st_init->zero_memory()) { > + return true; > + } > + } > + } > + > + // Unless there is an explicit 'continue', we must bail out here, > > > Vladimir > > On 9/15/14 3:31 PM, Staffan Friberg wrote: >> Hi Vladimir, >> >> Uploaded a new webrev with fixes to the below issues, >> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 >> >> Still removes expected barriers. >> >> Thanks, >> Staffan >> >> On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >>> Fix indention in 2 checks: >>> >>> + if (use_ReduceInitialCardMarks() && >>> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >>> >>> Typo 'iff' in both comments: >>> >>> + * Returns true iff the barrier can be removed >>> >>> In g1_can_remove_post_barrier() use: >>> >>> + // Start search from Store node >>> + Node* ctrl = store->in(MemNode::Control); >>> >>> Control edge can't point to an other Store so you should not check it >>> inside loop. >>> As result you don't need loop. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>>> Hi Mikael, >>>> >>>> I updated the documentation, and uploaded a new webrev, >>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>>> >>>> Thanks for agreeing to sponsor, and the good idea about pushing to >>>> hs-gc for extra coverage. >>>> >>>> Thanks, >>>> Staffan >>>> >>>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>>> Hi Staffan, >>>>> >>>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>>> Hi, >>>>>> >>>>>> Copying both the compiler and GC alias as the optimization involves >>>>>> both >>>>>> groups. >>>>>> >>>>>> This optimization aims to avoid generating G1 barriers for newly >>>>>> allocated objects where the compiler can prove that the object >>>>>> has not >>>>>> been written to earlier and there is no safepoint between the >>>>>> allocation >>>>>> and the write. The bug has some further details and microbenchmark >>>>>> result. The new code has fairly extensive comments about the >>>>>> optimization. >>>>>> >>>>>> It would be great if the GC team can help validate that the >>>>>> premise of >>>>>> the optimization is correct as well. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>>> I mostly read through the comments since I can't decode what the IR >>>>> transforms >>>>> intend to do :) >>>>> >>>>> We usually stick to the terms "old generation" and "young >>>>> generation" instead >>>>> of "Old Space" and "Young Space". >>>>> >>>>> "G1 also requires to keep track of objects between different >>>>> + * regions to enable evacuation of old regions" >>>>> should probably be. >>>>> .."to keep track of references between different regions" >>>>> >>>>> I leave it to the compiler team to review the actual code changes. >>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>>> >>>>>> I would also need a sponsor for this change if it passes review. >>>>> I'll push this to hs-gc after review since we have more G1 test >>>>> coverage on >>>>> hs-gc. >>>>> >>>>> /Mikael >>>>> >>>>>> Thanks, >>>>>> Staffan >>>> >> From John.Coomes at oracle.com Tue Sep 16 22:00:33 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 16 Sep 2014 15:00:33 -0700 Subject: review request (S) - 8058347: update allocation context stats In-Reply-To: <21523.31540.822447.513826@mykonos.us.oracle.com> References: <21523.31540.822447.513826@mykonos.us.oracle.com> Message-ID: <21528.45825.275537.977140@mykonos.us.oracle.com> John Coomes (John.Coomes at oracle.com) wrote: > Please review a minor api addition to the AllocationContextService > class to check for and process gc requests. > > http://cr.openjdk.java.net/~jcoomes/8u/8u40/8058347-stats-request-highest/ I'm withdrawing this review request; the problem can be solved in a different way without these changes. -John From vladimir.kozlov at oracle.com Tue Sep 16 22:16:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Sep 2014 15:16:05 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <5418AE85.1070309@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> <54178A86.4090500@oracle.com> <5418AE85.1070309@oracle.com> Message-ID: <5418B6A5.8070609@oracle.com> Looks fine but you need to add '.' at the end of statements in the comment you modified. No need for re-review. Thanks, Vladimir On 9/16/14 2:41 PM, Staffan Friberg wrote: > Thanks Vladimir, > > Updated with your suggestions. Added a small comment in > g1_can_remove_pre_barrier method since the alloc == NULL check is quite > a bit earlier. > > New webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.03 > > Cheers, > Staffan > > > On 09/15/2014 05:55 PM, Vladimir Kozlov wrote: >> You need only check (alloc == st_alloc) because alloc != NULL at this >> point: >> >> + if (st_alloc != NULL && alloc == st_alloc) { >> >> >> You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == >> NULL check). >> >> I would also reverse the last check there because you bailout from >> loop anyway: >> >> + if (captured_store == NULL || captured_store == >> st_init->zero_memory()) { >> + return true; >> + } >> + } >> + } >> + >> + // Unless there is an explicit 'continue', we must bail out here, >> >> >> Vladimir >> >> On 9/15/14 3:31 PM, Staffan Friberg wrote: >>> Hi Vladimir, >>> >>> Uploaded a new webrev with fixes to the below issues, >>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 >>> >>> Still removes expected barriers. >>> >>> Thanks, >>> Staffan >>> >>> On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >>>> Fix indention in 2 checks: >>>> >>>> + if (use_ReduceInitialCardMarks() && >>>> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >>>> >>>> Typo 'iff' in both comments: >>>> >>>> + * Returns true iff the barrier can be removed >>>> >>>> In g1_can_remove_post_barrier() use: >>>> >>>> + // Start search from Store node >>>> + Node* ctrl = store->in(MemNode::Control); >>>> >>>> Control edge can't point to an other Store so you should not check it >>>> inside loop. >>>> As result you don't need loop. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>>>> Hi Mikael, >>>>> >>>>> I updated the documentation, and uploaded a new webrev, >>>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>>>> >>>>> Thanks for agreeing to sponsor, and the good idea about pushing to >>>>> hs-gc for extra coverage. >>>>> >>>>> Thanks, >>>>> Staffan >>>>> >>>>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Copying both the compiler and GC alias as the optimization involves >>>>>>> both >>>>>>> groups. >>>>>>> >>>>>>> This optimization aims to avoid generating G1 barriers for newly >>>>>>> allocated objects where the compiler can prove that the object >>>>>>> has not >>>>>>> been written to earlier and there is no safepoint between the >>>>>>> allocation >>>>>>> and the write. The bug has some further details and microbenchmark >>>>>>> result. The new code has fairly extensive comments about the >>>>>>> optimization. >>>>>>> >>>>>>> It would be great if the GC team can help validate that the >>>>>>> premise of >>>>>>> the optimization is correct as well. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>>>> I mostly read through the comments since I can't decode what the IR >>>>>> transforms >>>>>> intend to do :) >>>>>> >>>>>> We usually stick to the terms "old generation" and "young >>>>>> generation" instead >>>>>> of "Old Space" and "Young Space". >>>>>> >>>>>> "G1 also requires to keep track of objects between different >>>>>> + * regions to enable evacuation of old regions" >>>>>> should probably be. >>>>>> .."to keep track of references between different regions" >>>>>> >>>>>> I leave it to the compiler team to review the actual code changes. >>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>>>> >>>>>>> I would also need a sponsor for this change if it passes review. >>>>>> I'll push this to hs-gc after review since we have more G1 test >>>>>> coverage on >>>>>> hs-gc. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> Thanks, >>>>>>> Staffan >>>>> >>> > From mikael.gerdin at oracle.com Wed Sep 17 07:07:44 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 17 Sep 2014 09:07:44 +0200 Subject: RFR [8u40] 8048268, 8057722 Code root migration Message-ID: <1764736.3hHflHvShp@mgerdin03> Hi all, I'd like to backport 8048268 and the related bugfix 8057722 to 8u40 to reduce the performance impact of code root migration. The original patch for 8048268 did not apply cleanly due to some spelling and style changes. These changes depend on 8056084 which is out for review on hotspot-dev. I plan to push these changes together once they're through review. Review threads: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010582.html http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-September/010709.html Bugs: https://bugs.openjdk.java.net/browse/JDK-8048268 https://bugs.openjdk.java.net/browse/JDK-8057722 Webrevs: http://cr.openjdk.java.net/~mgerdin/8048268/8u/webrev/ http://cr.openjdk.java.net/~mgerdin/8057722/8u/webrev/ /Mikael From thomas.schatzl at oracle.com Thu Sep 18 10:03:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 18 Sep 2014 12:03:53 +0200 Subject: RFR [8u40] 8048268, 8057722 Code root migration In-Reply-To: <1764736.3hHflHvShp@mgerdin03> References: <1764736.3hHflHvShp@mgerdin03> Message-ID: <1411034633.2709.54.camel@cirrus> Hi, On Wed, 2014-09-17 at 09:07 +0200, Mikael Gerdin wrote: > Hi all, > > I'd like to backport 8048268 and the related bugfix 8057722 to 8u40 to reduce > the performance impact of code root migration. > > The original patch for 8048268 did not apply cleanly due to some spelling and > style changes. > > These changes depend on 8056084 which is out for review on hotspot-dev. > I plan to push these changes together once they're through review. > > Review threads: >[...] > both backports look okay. Thomas From kim.barrett at oracle.com Thu Sep 18 18:56:33 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Sep 2014 14:56:33 -0400 Subject: RFR: 8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <5408FB9D.4000302@oracle.com> References: <5408FB9D.4000302@oracle.com> Message-ID: <97D3A467-ADEF-494D-94E1-F13DFAE6191C@oracle.com> On Sep 4, 2014, at 7:54 PM, Jesper Wilhelmsson wrote: > > This is the next part of the generation array removal. I have split this change into several parts to ease the review. These webrevs build on top of each other. Quoting from https://bugs.openjdk.java.net/browse/JDK-8055702 Today GenCollectedHeap contains an array with room for ten generations, and there is plenty of code that is written in a very generic way to allow for this many generations. However, there is also plenty of code that assumes we only use two generations and any attempt to use more would fail with the current code. In practice we only use two generations and there are no reason to maintain the illusion that we could use more. Has there been any discussion of whether removing support for many generations is indeed desirable, vs fixing the places where that possibility isn't properly supported? It was a long time ago, and I haven't even looked for references yet, but I vaguely recall seeing measurements showing some applications could benefit significantly from such. I think it had to do with applications that undergo major phase changes, where substantial data structures lasted for much of the duration of a phase but then were dropped on those phase transitions - moving such data to some intermediate generation that was processed more often than "old" but less often than "young" was thought to be beneficial. [It's also entirely possible that I'm completely misremembering, as this would have been from back in the early 1990s.] Maybe the answer to such an application now is G1? From joseph.provino at oracle.com Thu Sep 18 20:32:58 2014 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 18 Sep 2014 16:32:58 -0400 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end Message-ID: <541B417A.90901@oracle.com> Hi all, Can I have reviews for the following small change that removes the _orig_end member from the HeapRegion class. The information this member stores can be easily recalculated on the fly, so it is just a waste of a few bytes. CR:https://bugs.openjdk.java.net/browse/JDK-8058534 Webrev:http://cr.openjdk.java.net/~jprovino/8058534/webrev.00/ Testing: jprt I also need a sponsor to commit the changes. Thomas Schatzl has agreed to do that. Thanks. joe From kim.barrett at oracle.com Thu Sep 18 22:24:10 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Sep 2014 18:24:10 -0400 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <541B417A.90901@oracle.com> References: <541B417A.90901@oracle.com> Message-ID: <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> On Sep 18, 2014, at 4:32 PM, Joseph Provino wrote: > > Can I have reviews for the following small change that removes the > _orig_end member from the HeapRegion class. The information this member > stores can be easily recalculated on the fly, so it is just a waste of a > few bytes. > > CR:https://bugs.openjdk.java.net/browse/JDK-8058534 > > Webrev:http://cr.openjdk.java.net/~jprovino/8058534/webrev.00/ > > Testing: jprt In the original code, the _orig_end member that is being removed had a descriptive comment. That description no longer exists in the changed code. Maybe that comment should be moved to the orig_end() accessor? Otherwise looks good. From joseph.provino at oracle.com Thu Sep 18 22:43:12 2014 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 18 Sep 2014 18:43:12 -0400 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> References: <541B417A.90901@oracle.com> <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> Message-ID: <541B6000.2050801@oracle.com> Kim, thanks. I made that change you suggested. Webrev: http://cr.openjdk.java.net/~jprovino/8058534/webrev.01/ joe On 9/18/2014 6:24 PM, Kim Barrett wrote: > On Sep 18, 2014, at 4:32 PM, Joseph Provino wrote: >> Can I have reviews for the following small change that removes the >> _orig_end member from the HeapRegion class. The information this member >> stores can be easily recalculated on the fly, so it is just a waste of a >> few bytes. >> >> CR:https://bugs.openjdk.java.net/browse/JDK-8058534 >> >> Webrev:http://cr.openjdk.java.net/~jprovino/8058534/webrev.00/ >> >> Testing: jprt > In the original code, the _orig_end member that is being removed had a descriptive > comment. That description no longer exists in the changed code. Maybe that > comment should be moved to the orig_end() accessor? > > Otherwise looks good. > From tprintezis at twitter.com Thu Sep 18 23:18:26 2014 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 18 Sep 2014 19:18:26 -0400 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> References: <541B417A.90901@oracle.com> <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> Message-ID: <541B6842.8080107@twitter.com> Joe, Looks good, and +1 to Kim's suggestion below re: moving the comment for _orig_end to orig_end(). Tony On 9/18/14, 6:24 PM, Kim Barrett wrote: > On Sep 18, 2014, at 4:32 PM, Joseph Provino wrote: >> Can I have reviews for the following small change that removes the >> _orig_end member from the HeapRegion class. The information this member >> stores can be easily recalculated on the fly, so it is just a waste of a >> few bytes. >> >> CR:https://bugs.openjdk.java.net/browse/JDK-8058534 >> >> Webrev:http://cr.openjdk.java.net/~jprovino/8058534/webrev.00/ >> >> Testing: jprt > In the original code, the _orig_end member that is being removed had a descriptive > comment. That description no longer exists in the changed code. Maybe that > comment should be moved to the orig_end() accessor? > > Otherwise looks good. > -- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com From kim.barrett at oracle.com Thu Sep 18 23:25:03 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Sep 2014 19:25:03 -0400 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <541B6000.2050801@oracle.com> References: <541B417A.90901@oracle.com> <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> <541B6000.2050801@oracle.com> Message-ID: <3B651F95-F88C-4404-8F77-E1D6E8CE7E1C@oracle.com> On Sep 18, 2014, at 6:43 PM, Joseph Provino wrote: > > Kim, thanks. I made that change you suggested. > > Webrev: http://cr.openjdk.java.net/~jprovino/8058534/webrev.01/ Sorry, I missed some problems with the assert message added in HeapRegion::initialize() gc_implementation/g1/heapRegion.cpp, lines 356-9. There?s a pair of strings to break a source line: " should match exactly? "bottom plus ?? missing a space at the end of the first or beginning of second, else output contains ?? exactlybottom ??. String literals immediately followed by identifiers, with no intervening spaces, will run afoul of C++11 user-defined literals. Although gcc and clang provide CLAs to control C++11 features, my understanding is that MS compiler is mostly rolling C++11 features in as implemented in new versions, generally without such controls. As a result, I would expect such usage to fail to compile on some (possibly still in the future) versions. Suggest putting spaces between string literals and macro identifiers. From bengt.rutisson at oracle.com Fri Sep 19 07:20:33 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Sep 2014 09:20:33 +0200 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <3B651F95-F88C-4404-8F77-E1D6E8CE7E1C@oracle.com> References: <541B417A.90901@oracle.com> <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> <541B6000.2050801@oracle.com> <3B651F95-F88C-4404-8F77-E1D6E8CE7E1C@oracle.com> Message-ID: <541BD941.6020103@oracle.com> Hi Joe, Latest webrev looks good to me. I can sponsor this and push it through JPRT. I'll fix Kim's comment about the missing space before I push. Nice catch, Kim! Bengt On 9/19/14 1:25 AM, Kim Barrett wrote: > On Sep 18, 2014, at 6:43 PM, Joseph Provino wrote: >> Kim, thanks. I made that change you suggested. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8058534/webrev.01/ > Sorry, I missed some problems with the assert message added in HeapRegion::initialize() > gc_implementation/g1/heapRegion.cpp, lines 356-9. > > There?s a pair of strings to break a source line: > " should match exactly? > "bottom plus ?? > missing a space at the end of the first or beginning of second, else output contains ?? exactlybottom ??. > > String literals immediately followed by identifiers, with no intervening spaces, will run afoul of C++11 user-defined literals. Although gcc and clang provide CLAs to control C++11 features, my understanding is that MS compiler is mostly rolling C++11 features in as implemented in new versions, generally without such controls. As a result, I would expect such usage to fail to compile on some (possibly still in the future) versions. Suggest putting spaces between string literals and macro identifiers. > > From thomas.schatzl at oracle.com Fri Sep 19 07:28:03 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 19 Sep 2014 09:28:03 +0200 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <541BD941.6020103@oracle.com> References: <541B417A.90901@oracle.com> <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> <541B6000.2050801@oracle.com> <3B651F95-F88C-4404-8F77-E1D6E8CE7E1C@oracle.com> <541BD941.6020103@oracle.com> Message-ID: <1411111683.2876.3.camel@cirrus> Hi, On Fri, 2014-09-19 at 09:20 +0200, Bengt Rutisson wrote: > Hi Joe, > > Latest webrev looks good to me. > > I can sponsor this and push it through JPRT. I'll fix Kim's comment > about the missing space before I push. Nice catch, Kim! can you fix the indentation of the error message too before pushing? I.e. align the arguments to the opening bracket? Thanks, Thomas > > Bengt > > On 9/19/14 1:25 AM, Kim Barrett wrote: > > On Sep 18, 2014, at 6:43 PM, Joseph Provino wrote: > >> Kim, thanks. I made that change you suggested. > >> > >> Webrev: http://cr.openjdk.java.net/~jprovino/8058534/webrev.01/ > > Sorry, I missed some problems with the assert message added in HeapRegion::initialize() > > gc_implementation/g1/heapRegion.cpp, lines 356-9. > > > > There?s a pair of strings to break a source line: > > " should match exactly? > > "bottom plus ?? > > missing a space at the end of the first or beginning of second, else output contains ?? exactlybottom ??. > > > > String literals immediately followed by identifiers, with no intervening spaces, will run afoul of C++11 user-defined literals. Although gcc and clang provide CLAs to control C++11 features, my understanding is that MS compiler is mostly rolling C++11 features in as implemented in new versions, generally without such controls. As a result, I would expect such usage to fail to compile on some (possibly still in the future) versions. Suggest putting spaces between string literals and macro identifiers. > > > > > From bengt.rutisson at oracle.com Fri Sep 19 08:41:51 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Sep 2014 10:41:51 +0200 Subject: RFR (XS): JDK-8058534: Remove HeapRegion::_orig_end In-Reply-To: <1411111683.2876.3.camel@cirrus> References: <541B417A.90901@oracle.com> <7ED879D9-CDB9-4561-91B3-EA529A4A0A1E@oracle.com> <541B6000.2050801@oracle.com> <3B651F95-F88C-4404-8F77-E1D6E8CE7E1C@oracle.com> <541BD941.6020103@oracle.com> <1411111683.2876.3.camel@cirrus> Message-ID: <541BEC4F.90601@oracle.com> Hi, On 9/19/14 9:28 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-19 at 09:20 +0200, Bengt Rutisson wrote: >> Hi Joe, >> >> Latest webrev looks good to me. >> >> I can sponsor this and push it through JPRT. I'll fix Kim's comment >> about the missing space before I push. Nice catch, Kim! > can you fix the indentation of the error message too before pushing? > I.e. align the arguments to the opening bracket? Yes, thanks for finding that. Fixed the alignemnt too. Here's what got pushed: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/c919a19a9d9c Thanks, Bengt > > Thanks, > Thomas > >> Bengt >> >> On 9/19/14 1:25 AM, Kim Barrett wrote: >>> On Sep 18, 2014, at 6:43 PM, Joseph Provino wrote: >>>> Kim, thanks. I made that change you suggested. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/8058534/webrev.01/ >>> Sorry, I missed some problems with the assert message added in HeapRegion::initialize() >>> gc_implementation/g1/heapRegion.cpp, lines 356-9. >>> >>> There?s a pair of strings to break a source line: >>> " should match exactly? >>> "bottom plus ?? >>> missing a space at the end of the first or beginning of second, else output contains ?? exactlybottom ??. >>> >>> String literals immediately followed by identifiers, with no intervening spaces, will run afoul of C++11 user-defined literals. Although gcc and clang provide CLAs to control C++11 features, my understanding is that MS compiler is mostly rolling C++11 features in as implemented in new versions, generally without such controls. As a result, I would expect such usage to fail to compile on some (possibly still in the future) versions. Suggest putting spaces between string literals and macro identifiers. >>> >>> > From marcus.larsson at oracle.com Fri Sep 19 11:13:49 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 19 Sep 2014 13:13:49 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over In-Reply-To: <1410872796.2755.45.camel@cirrus> References: <5412E184.70700@oracle.com> <1410872796.2755.45.camel@cirrus> Message-ID: <541C0FED.90200@oracle.com> Hi Thomas, thanks for reviewing! On 09/16/2014 03:06 PM, Thomas Schatzl wrote: > Hi Marcus, > > On Fri, 2014-09-12 at 14:05 +0200, Marcus Larsson wrote: >> Hi, >> >> I would like reviews for the following refactorization to separate the >> heap region claiming from the actual heap region data structure. This >> allows concurrent tasks to claim heap regions independent of each other. >> >> The patch adds a HeapRegionClaimer that should be used for parallel >> iteration over heap regions, and will handle the claims for a certain >> task. The previous claim field and its associated functions in >> HeapRegion is removed. >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8058298/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8058298 >> >> Testing: >> jprt >> local UTE vm.gc.testlist >> SPECjbb2013 > a few notes: > > - there is no Atomic::cmpxchg() for uint, only jint (iirc!). Please > change the type for HeapRegionClaimer::_claims accordingly. > > - HeapRegionClaimer should inherit from StackObj Fixed. > - I think you everything but is_region_claimed() and claim_region() > could be moved to the cpp file without problems. I think even moving > those two too would not matter given that a HeapRegion is a relatively > coarse unit of work. > > Actually I was not able to compile a patched VM without moving at least > HeapRegionClaimer::initialize() to a cpp file when using > USE_PRECOMPILED_HEADER=0. Moved them all to the cpp. Also verified that it compiles without precompiled header. > - in HeapRegionClaimer::HeapRegionClaimer(uint), the method body is > indented two spaces too many. Fixed. > - I would see the HeapRegionClaimer as part of the parallel iteration, > so better located with the HeapRegionManager class. Also, the need for > the number of regions (_allocated_heapregions_length) indicates that. > It does not reference HeapRegion at all too. Moved to HeapRegionManager.hpp/cpp > - maybe in a future RFE we could make the HeapRegionClaimer a real > iterator. I already like that this change removes a lot of code though. > > Looks good otherwise. > > Thanks, > Thomas > > New webrev: http://cr.openjdk.java.net/~brutisso/webrev-8058298v2/ Changes from previous webrev: http://cr.openjdk.java.net/~brutisso/webrev-8058298v1-v2/ Regards, Marcus From bengt.rutisson at oracle.com Fri Sep 19 12:40:58 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Sep 2014 14:40:58 +0200 Subject: RFR: 8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <97D3A467-ADEF-494D-94E1-F13DFAE6191C@oracle.com> References: <5408FB9D.4000302@oracle.com> <97D3A467-ADEF-494D-94E1-F13DFAE6191C@oracle.com> Message-ID: <541C245A.6070609@oracle.com> Hi Kim, On 9/18/14 8:56 PM, Kim Barrett wrote: > On Sep 4, 2014, at 7:54 PM, Jesper Wilhelmsson wrote: >> This is the next part of the generation array removal. I have split this change into several parts to ease the review. These webrevs build on top of each other. > Quoting from https://bugs.openjdk.java.net/browse/JDK-8055702 > > Today GenCollectedHeap contains an array with room for ten > generations, and there is plenty of code that is written in a very > generic way to allow for this many generations. However, there is > also plenty of code that assumes we only use two generations and any > attempt to use more would fail with the current code. In practice we > only use two generations and there are no reason to maintain the > illusion that we could use more. > > Has there been any discussion of whether removing support for many > generations is indeed desirable, vs fixing the places where that > possibility isn't properly supported? It was a long time ago, and I > haven't even looked for references yet, but I vaguely recall seeing > measurements showing some applications could benefit significantly > from such. I think it had to do with applications that undergo major > phase changes, where substantial data structures lasted for much of > the duration of a phase but then were dropped on those phase > transitions - moving such data to some intermediate generation that > was processed more often than "old" but less often than "young" was > thought to be beneficial. [It's also entirely possible that I'm > completely misremembering, as this would have been from back in the > early 1990s.] > > Maybe the answer to such an application now is G1? Yes, we did discuss this and I think Jesper's work is the right thing to do (even though I haven't looked at his latest webrev). Some background. The generations abstraction was introduced to support the train collector, where multiple generations was a central concept. When the train collector was removed the code was never cleaned up properly. Thus, I consider the work that Jesper does now cleanups that reduce our technical debt. When the train collector was removed we were left with only collectors that support two generations. Note that only two of our GC (CMS and SerialGC) actually use the generations abstraction. That means that the code is unnecessarily complex and as Jepser points out it has probably deteriorated in a way that it will not be easy to just add a generation. Having said all that, I do agree that an intermediate generation may be useful in some cases. But I think if we would add that we would most likely add it to G1. In G1 it is actually fairly straight forward to do that, but it will not make use of the current generation abstraction. So, Jesper's change does not limit our future plans in any way for G1 (or for ParallelGC for that matter). Keeping the generations abstraction around would however limit our flexibility since it makes any changes to CMS and SerialGC more difficult and error prone than they have to be. Thanks, Bengt > From thomas.schatzl at oracle.com Fri Sep 19 13:18:43 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 19 Sep 2014 15:18:43 +0200 Subject: RFR: 8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <97D3A467-ADEF-494D-94E1-F13DFAE6191C@oracle.com> References: <5408FB9D.4000302@oracle.com> <97D3A467-ADEF-494D-94E1-F13DFAE6191C@oracle.com> Message-ID: <1411132723.2876.95.camel@cirrus> Hi Kim, On Thu, 2014-09-18 at 14:56 -0400, Kim Barrett wrote: > On Sep 4, 2014, at 7:54 PM, Jesper Wilhelmsson wrote: > > > > This is the next part of the generation array removal. I have split this change into several parts to ease the review. These webrevs build on top of each other. > > Quoting from https://bugs.openjdk.java.net/browse/JDK-8055702 > > Today GenCollectedHeap contains an array with room for ten > generations, and there is plenty of code that is written in a very > generic way to allow for this many generations. However, there is > also plenty of code that assumes we only use two generations and any > attempt to use more would fail with the current code. In practice we > only use two generations and there are no reason to maintain the > illusion that we could use more. > > Has there been any discussion of whether removing support for many > generations is indeed desirable, vs fixing the places where that > possibility isn't properly supported? It was a long time ago, and I Only CMS and Serial GC use this abstraction, and only support two generations. I do not know the exact background for why this is still here. > haven't even looked for references yet, but I vaguely recall seeing > measurements showing some applications could benefit significantly > from such. I think it had to do with applications that undergo major > phase changes, where substantial data structures lasted for much of > the duration of a phase but then were dropped on those phase > transitions - moving such data to some intermediate generation that > was processed more often than "old" but less often than "young" was > thought to be beneficial. [It's also entirely possible that I'm > completely misremembering, as this would have been from back in the > early 1990s.] You are correct that there is research about this. More than the three generations (young, old, and until jdk8 perm) do not seem to be practical. The current framework only supports static sizing, which is already hard for many people to get right with only the two/three generations. See the bug tracker for requests to either automatize that or remove the need for that. It would be even harder with more generations, particularly as you correctly point out that it would require the VM to detect program phases, and dynamically size the generations on the fly to be efficient. Both of which is not implemented. Moving the generation boundaries is rather slow too (need to move data), probably eating up a lot of the gains. The young/old split works pretty well. Actually relatively long lived data often accumulates in the "stable prefix" of the old gen, which means it is skipped during compaction anyway. This code only is like technical debt that regularly takes time either when changing these collectors, or even only by requiring us to look at false positives from static analysis tools. > Maybe the answer to such an application now is G1? It's pretty easy to define a set of regions as logically belonging to a "generation". Implementing most of the gains (remembered sets etc) is not very hard too. I am sure there are implementations that do that for specialized purposes out there. Thanks, Thomas From andrey.x.zakharov at oracle.com Fri Sep 19 14:54:36 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Fri, 19 Sep 2014 18:54:36 +0400 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures Message-ID: <541C43AC.8070607@oracle.com> Hello, team Could you please review bunch of tests for feature https://bugs.openjdk.java.net/browse/JDK-8038423: G1: Decommit memory within the heap the inner scenario is allocate array of objects, link this objects to each other, mutate some of this objects to fill RSet in G1 and deallocate objects. inner test expected at least not growing commit memory size of heap and non-heap. It's hard to separate featured non-heap usages from overall non-heap usages of internal structures, so we can expect that non-heap commit memory size can even grows up. outer test rotate *G1ConcRSLogCacheSize* and *ObjectAlignmentInBytes* (for 64bits) options values and runs inner test. *G1ConcRSLogCacheSize* is iterated from 0, 2^0 to 2^31, but test calculates maximum available memory and use according pow of 2. ObjectAlignmentInBytes is iterated from 2^3 to 2^8 As outer tests spawns an inner tests 6 times it needs a longer timeout = 120 seconds * 6 = 720 seconds. Also, I've separate 1 large test to several tests for different G1ConcRSLogCacheSize options to avoid even longer timeout. webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.00/ bug for test: https://bugs.openjdk.java.net/browse/JDK-8043766 feature bug: https://bugs.openjdk.java.net/browse/JDK-8038423 Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.provino at oracle.com Fri Sep 19 15:25:01 2014 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 19 Sep 2014 11:25:01 -0400 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark Message-ID: <541C4ACD.1010709@oracle.com> Hi all, Can I have reviews for the following small change that logs more G1 Concurrent Mark Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() because it's used in places other than remark. CR: https://bugs.openjdk.java.net/browse/JDK-8027450 Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ Testing: jprt I also need a sponsor to commit the changes. Thanks. joe From kim.barrett at oracle.com Fri Sep 19 16:26:35 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Sep 2014 12:26:35 -0400 Subject: RFR: 8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <541C245A.6070609@oracle.com> References: <5408FB9D.4000302@oracle.com> <97D3A467-ADEF-494D-94E1-F13DFAE6191C@oracle.com> <541C245A.6070609@oracle.com> Message-ID: On Sep 19, 2014, at 8:40 AM, Bengt Rutisson wrote: > >> Has there been any discussion of whether removing support for many >> generations is indeed desirable, vs fixing the places where that >> possibility isn't properly supported? > > Yes, we did discuss this and I think Jesper's work is the right thing to do (even though I haven't looked at his latest webrev). > > Some background. [?] Good answers from Bengt and Thomas. I?m convinced. From kim.barrett at oracle.com Fri Sep 19 18:52:32 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Sep 2014 14:52:32 -0400 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <540D9052.7030608@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> <540D9052.7030608@oracle.com> Message-ID: <250318A9-D40B-4DF8-A9F2-30BF9A5828B7@oracle.com> On Sep 8, 2014, at 7:17 AM, Marcus Larsson wrote: > > New webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8043243v2/ Sorry for the late review; I was on vacation and only now catching up on this. This change replaces some macros with function templates. These function templates take a "space" argument and require that it support a specific protocol. Actually, there seem to be two protocols, one a subset of the other: // base protocol HeapWord* scan_limit(space*) bool block_is_obj(space*, const HeapWord*) size_t block_size(space*, const HeapWord*) // addtional protocol size_t adjust_obj_size(space*, size_t) size_t obj_size(space*, const HeapWord*) [Not sure why space arguments are not const in most or all cases.] The "usual" way to do that is with virtual functions declared in the base class and implemented in the derived classes. I'm going to ignore that approach, as I suspect it was (probably correctly) deemed too expensive in performace for these operations that look to be fairly light weight and probably performance critical. I also put "usual" in quotes, since in some communities or contexts that would not at all be the preferred approach. A point of nomenclature: the proposed code uses the term "proxy", where I think the more usual terminology (per Gang-of-Four) would be "adaptor" (or "adapter" - the C++ community seems to prefer the -or spelling, GoF uses -er). One thing that is missing is any definition of the "concepts" required by these function templates. Presently that's only implicitly encoded in the calls made by those functions, and by the definitions of the new "proxy" classes. There really should be at least documentation associated with the functions describing their requirements. Code to check the arguments satisfy those requirements would be better, but I don't think hotspot has any infrastructure to help with that. The function templates are declared as ordinary member functions rather than static member functions, with the requirement that they will be called with "this" as the first (space) argument, e.g. "this == space" is a requirement for these functions. That should be asserted, or these functions should be static member functions. I don't know if the latter will work without further changes; there might be uses of the implicit this in the current implementations of these functions, which may argue that the presently implicit "concept" definitions are incomplete. The proposed adaptation mechanism is to provide an auxiliary class providing static functions on the space value that forward to related functions in that object. Alternatives that come to mind that I like better include: - Add the needed functions to the associated classes, rather than providing auxiliary forwarding classes. Note that this doesn't involve virtual functions; I'm suggesting static polymorphism here, not runtime polymorphism. These should be ordinary member functions invoked as space->fn(). [They could instead be static member functions taking space as an argument, but then they would need to be called as SpaceType::fn(space), which doesn't seem like an improvement.] This is, of course, an intrusive approach, but the scan function templates are in the API of a base class, so providing support directly in the derived classes is reasonable. - Add free functions with overloads for the relevant classes. Lack of namespace usage in hotspot might make this less attractive. Also, there aren't good primary / default definitions available for most or all of these operations. Assuming the auxiliary class approach is retained, the current implementation has the adaptor (called proxy) type as a template parameter that the caller must explicitly supply. A better approach would be to compute the adaptor type from the space type in the body of the function templates. The adaptor type could be added directly to the relevant space types as a public typedef, e.g. in each class add typedef ADAPTOR_TYPE ScanAdaptor; A non-intrusive approach would be to provide a metafunction for mapping from space type to adaptor type, e.g. - Add to CompactibleSpace class template struct ScanAdaptor; - For each space class that requires scan adaptation, define template<> struct CompactibleSpace::ScanAdaptor { typedef ADAPTOR_TYPE type; }; Then, in each of the scan templates, eliminate the SpaceProxy template parameter and add one of the following typedefs to the body, as appropriate for the computation approach: typedef typename SpaceType::ScanAdaptor SpaceProxy; or typedef typename CompactibleSpace::ScanAdaptor::type SpaceProxy; [possibly renaming SpaceProxy] This eliminates the need for callers to explicitly specify the adaptor type in calls to the scan functions. There are other approaches to this whole problem, such as using CRTP (the Curiously Recurring Template Pattern) but that would be substantially further from the presently proposed changes, and I think not necessarily better in this case, so I'm not going to discuss that further. That's a lot of commentary, with several possible options, so I'll be specific about what I currently think should be done. - Document the requirements of the new function templates on their space argument, e.g. what operations must SpaceType provide. [Some documentation about what these functions do might be nice too.] - Change the new function templates to be static member functions rather than ordinary member functions, or if that is too onerous then at least assert this == space. - Add the needed operations directly to the relevant classes, as ordinary member functions, and eliminate the auxiliary classes. Alternatively, if the auxiliary class approach is preferred by others, then compute that class from the space class by one of the methods suggested above. From kim.barrett at oracle.com Mon Sep 22 01:46:44 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 21 Sep 2014 21:46:44 -0400 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <250318A9-D40B-4DF8-A9F2-30BF9A5828B7@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> <540D9052.7030608@oracle.com> <250318A9-D40B-4DF8-A9F2-30BF9A5828B7@oracle.com> Message-ID: On Sep 19, 2014, at 2:52 PM, Kim Barrett wrote: > > On Sep 8, 2014, at 7:17 AM, Marcus Larsson wrote: >> >> New webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8043243v2/ > > [?] Actually, there seem to be two protocols, one a > subset of the other: > > // base protocol > HeapWord* scan_limit(space*) > bool block_is_obj(space*, const HeapWord*) > size_t block_size(space*, const HeapWord*) > > // addtional protocol > size_t adjust_obj_size(space*, size_t) > size_t obj_size(space*, const HeapWord*) > > [Not sure why space arguments are not const in most or all cases.] Another point that I forgot to mention in earlier email: The proposed changes introduce two adapter classes, one for each of the classes derived from the CompactibleSpace base class that is providing the new function templates. That means some of those new function templates are only applicable to one of the derived classes, and not the other. It might be beneficial to push such down to the corresponding derived class and de-templatize. From stefan.karlsson at oracle.com Mon Sep 22 08:01:28 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 22 Sep 2014 10:01:28 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <541C4ACD.1010709@oracle.com> References: <541C4ACD.1010709@oracle.com> Message-ID: <541FD758.5000202@oracle.com> Looks good. I can sponsor this change. StefanK On 2014-09-19 17:25, Joseph Provino wrote: > Hi all, > > Can I have reviews for the following small change that logs more G1 > Concurrent Mark > Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() > because it's > used in places other than remark. > > CR: https://bugs.openjdk.java.net/browse/JDK-8027450 > > Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ > > Testing: jprt > > I also need a sponsor to commit the changes. > Thanks. > > joe From bengt.rutisson at oracle.com Mon Sep 22 08:52:43 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 22 Sep 2014 10:52:43 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <541C4ACD.1010709@oracle.com> References: <541C4ACD.1010709@oracle.com> Message-ID: <541FE35B.8070008@oracle.com> Hi Joe, Looks good to me. Bengt On 2014-09-19 17:25, Joseph Provino wrote: > Hi all, > > Can I have reviews for the following small change that logs more G1 > Concurrent Mark > Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() > because it's > used in places other than remark. > > CR: https://bugs.openjdk.java.net/browse/JDK-8027450 > > Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ > > Testing: jprt > > I also need a sponsor to commit the changes. > Thanks. > > joe From thomas.schatzl at oracle.com Mon Sep 22 09:06:09 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Sep 2014 11:06:09 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <541C4ACD.1010709@oracle.com> References: <541C4ACD.1010709@oracle.com> Message-ID: <1411376769.2742.2.camel@cirrus> Hi, On Fri, 2014-09-19 at 11:25 -0400, Joseph Provino wrote: > Hi all, > > Can I have reviews for the following small change that logs more G1 > Concurrent Mark > Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() > because it's > used in places other than remark. > > CR: https://bugs.openjdk.java.net/browse/JDK-8027450 > > Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ > > Testing: jprt > > I also need a sponsor to commit the changes. Looks good. Maybe the strings could be changed to fit the existing though, e.g. "GC ref-proc" -> "Reference processing", and "GC aggregate-data" -> "Aggregate data". Thanks, Thomas From bengt.rutisson at oracle.com Mon Sep 22 10:56:29 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 22 Sep 2014 12:56:29 +0200 Subject: RFR [8u40] 8048268, 8057722 Code root migration In-Reply-To: <1764736.3hHflHvShp@mgerdin03> References: <1764736.3hHflHvShp@mgerdin03> Message-ID: <5420005D.4020003@oracle.com> Hi Mikael, On 2014-09-17 09:07, Mikael Gerdin wrote: > Hi all, > > I'd like to backport 8048268 and the related bugfix 8057722 to 8u40 to reduce > the performance impact of code root migration. > > The original patch for 8048268 did not apply cleanly due to some spelling and > style changes. > > These changes depend on 8056084 which is out for review on hotspot-dev. > I plan to push these changes together once they're through review. > > Review threads: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010582.html > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-September/010709.html > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8048268 I didn't look through all the changes for 8048268. When I tried the backport myself the only conflict I got was the spelling fix of "successfully" in g1CollectedHeap.hpp. If that was the only conflict you got then your backport looks good. > https://bugs.openjdk.java.net/browse/JDK-8057722 Looks good. Bengt > > Webrevs: > http://cr.openjdk.java.net/~mgerdin/8048268/8u/webrev/ > http://cr.openjdk.java.net/~mgerdin/8057722/8u/webrev/ > > /Mikael From stefan.karlsson at oracle.com Mon Sep 22 13:31:41 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 22 Sep 2014 15:31:41 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <1411376769.2742.2.camel@cirrus> References: <541C4ACD.1010709@oracle.com> <1411376769.2742.2.camel@cirrus> Message-ID: <542024BD.9070304@oracle.com> On 2014-09-22 11:06, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-19 at 11:25 -0400, Joseph Provino wrote: >> Hi all, >> >> Can I have reviews for the following small change that logs more G1 >> Concurrent Mark >> Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() >> because it's >> used in places other than remark. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8027450 >> >> Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ >> >> Testing: jprt >> >> I also need a sponsor to commit the changes. > Looks good. Maybe the strings could be changed to fit the existing > though, e.g. "GC ref-proc" -> "Reference processing", and "GC > aggregate-data" -> "Aggregate data". That might be worth doing, but not as a part of this cleanup. Changing the log output is usually a much greater undertaking than this small cleanup. StefanK > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Sep 22 13:53:38 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Sep 2014 15:53:38 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <542024BD.9070304@oracle.com> References: <541C4ACD.1010709@oracle.com> <1411376769.2742.2.camel@cirrus> <542024BD.9070304@oracle.com> Message-ID: <1411394018.2742.61.camel@cirrus> Hi, On Mon, 2014-09-22 at 15:31 +0200, Stefan Karlsson wrote: > On 2014-09-22 11:06, Thomas Schatzl wrote: > > Hi, > > > > On Fri, 2014-09-19 at 11:25 -0400, Joseph Provino wrote: > >> Hi all, > >> > >> Can I have reviews for the following small change that logs more G1 > >> Concurrent Mark > >> Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() > >> because it's > >> used in places other than remark. > >> > >> CR: https://bugs.openjdk.java.net/browse/JDK-8027450 > >> > >> Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ > >> > >> Testing: jprt > >> > >> I also need a sponsor to commit the changes. > > Looks good. Maybe the strings could be changed to fit the existing > > though, e.g. "GC ref-proc" -> "Reference processing", and "GC > > aggregate-data" -> "Aggregate data". > > That might be worth doing, but not as a part of this cleanup. Changing > the log output is usually a much greater undertaking than this small > cleanup. > Fine with me. Thanks, Thomas From joseph.provino at oracle.com Mon Sep 22 14:03:49 2014 From: joseph.provino at oracle.com (joe provino) Date: Mon, 22 Sep 2014 10:03:49 -0400 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <1411394018.2742.61.camel@cirrus> References: <541C4ACD.1010709@oracle.com> <1411376769.2742.2.camel@cirrus> <542024BD.9070304@oracle.com> <1411394018.2742.61.camel@cirrus> Message-ID: <54202C45.4090008@oracle.com> On 09/22/2014 09:53 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-09-22 at 15:31 +0200, Stefan Karlsson wrote: >> On 2014-09-22 11:06, Thomas Schatzl wrote: >>> Hi, >>> >>> On Fri, 2014-09-19 at 11:25 -0400, Joseph Provino wrote: >>>> Hi all, >>>> >>>> Can I have reviews for the following small change that logs more G1 >>>> Concurrent Mark >>>> Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() >>>> because it's >>>> used in places other than remark. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8027450 >>>> >>>> Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ >>>> >>>> Testing: jprt >>>> >>>> I also need a sponsor to commit the changes. >>> Looks good. Maybe the strings could be changed to fit the existing >>> though, e.g. "GC ref-proc" -> "Reference processing", and "GC >>> aggregate-data" -> "Aggregate data". >> That might be worth doing, but not as a part of this cleanup. Changing >> the log output is usually a much greater undertaking than this small >> cleanup. >> > Fine with me. Should I leave it the way it is for now or change the strings? joe > Thanks, > Thomas > > From stefan.karlsson at oracle.com Mon Sep 22 13:53:19 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 22 Sep 2014 15:53:19 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <1411394018.2742.61.camel@cirrus> References: <541C4ACD.1010709@oracle.com> <1411376769.2742.2.camel@cirrus> <542024BD.9070304@oracle.com> <1411394018.2742.61.camel@cirrus> Message-ID: <542029CF.8080804@oracle.com> On 2014-09-22 15:53, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-09-22 at 15:31 +0200, Stefan Karlsson wrote: >> On 2014-09-22 11:06, Thomas Schatzl wrote: >>> Hi, >>> >>> On Fri, 2014-09-19 at 11:25 -0400, Joseph Provino wrote: >>>> Hi all, >>>> >>>> Can I have reviews for the following small change that logs more G1 >>>> Concurrent Mark >>>> Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() >>>> because it's >>>> used in places other than remark. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8027450 >>>> >>>> Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ >>>> >>>> Testing: jprt >>>> >>>> I also need a sponsor to commit the changes. >>> Looks good. Maybe the strings could be changed to fit the existing >>> though, e.g. "GC ref-proc" -> "Reference processing", and "GC >>> aggregate-data" -> "Aggregate data". >> That might be worth doing, but not as a part of this cleanup. Changing >> the log output is usually a much greater undertaking than this small >> cleanup. >> > Fine with me. Since aggregate-data is a new string, I think it's good if we give it a good name from the start. I'm just opposing trying to change "GC ref-proc" in this change. thanks, StefanK > > Thanks, > Thomas > > From kirk at kodewerk.com Mon Sep 22 20:58:50 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 22 Sep 2014 13:58:50 -0700 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <1411394018.2742.61.camel@cirrus> References: <541C4ACD.1010709@oracle.com> <1411376769.2742.2.camel@cirrus> <542024BD.9070304@oracle.com> <1411394018.2742.61.camel@cirrus> Message-ID: Hi Thomas, The string "[GC remark [GC graph-trace, 0.0095070 secs] [GC ref-proc, 0.0151560 secs] [GC string-unlink, 0.0211210 secs] [GC symbol-unlink, 0.0635730 secs] [GC aggregate-data, 0.0102910 secs], 0.1199190 secs] ? as listed in the web-rev is fine. This is easily machine parseable and it follows the hyphenated format that has been traditionally used in the GC logs. My only comment is that GC at the beginning of each block is noise but if it makes you happier to have it there... so be it.If this is the output that you can guarantee and it won?t be corrupted by other records and/or flag settings then I think this breakdown will not only be very useful, it will be appreciated. Kind regards, Kirk Pepperdine PS why I prefer the hyphenated output is that it?s easier pick out in cases where output is mixed with other forms of application logging On Sep 22, 2014, at 6:53 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-09-22 at 15:31 +0200, Stefan Karlsson wrote: >> On 2014-09-22 11:06, Thomas Schatzl wrote: >>> Hi, >>> >>> On Fri, 2014-09-19 at 11:25 -0400, Joseph Provino wrote: >>>> Hi all, >>>> >>>> Can I have reviews for the following small change that logs more G1 >>>> Concurrent Mark >>>> Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() >>>> because it's >>>> used in places other than remark. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8027450 >>>> >>>> Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ >>>> >>>> Testing: jprt >>>> >>>> I also need a sponsor to commit the changes. >>> Looks good. Maybe the strings could be changed to fit the existing >>> though, e.g. "GC ref-proc" -> "Reference processing", and "GC >>> aggregate-data" -> "Aggregate data". >> >> That might be worth doing, but not as a part of this cleanup. Changing >> the log output is usually a much greater undertaking than this small >> cleanup. >> > > Fine with me. > > Thanks, > Thomas > > -------------- 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 stefan.karlsson at oracle.com Tue Sep 23 11:08:10 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 23 Sep 2014 13:08:10 +0200 Subject: RFR (XS): JDK-8027450 : Improve time reporting in G1 remark In-Reply-To: <541C4ACD.1010709@oracle.com> References: <541C4ACD.1010709@oracle.com> Message-ID: <5421549A.6030509@oracle.com> Hi all, I'm pushing this change as is, and have created this follow-up RFE where the strings of the phases can be discussed: https://bugs.openjdk.java.net/browse/JDK-8058944 thanks, StefanK On 19/09/14 17:25, Joseph Provino wrote: > Hi all, > > Can I have reviews for the following small change that logs more G1 > Concurrent Mark > Trace Times. I also changed G1RemarkGCTraceTime() to G1CMTraceTime() > because it's > used in places other than remark. > > CR: https://bugs.openjdk.java.net/browse/JDK-8027450 > > Webrev:http://cr.openjdk.java.net/~jprovino/8027450/webrev.00/ > > Testing: jprt > > I also need a sponsor to commit the changes. > Thanks. > > joe From bengt.rutisson at oracle.com Tue Sep 23 11:36:19 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 23 Sep 2014 13:36:19 +0200 Subject: CRR (S): 8058495: G1: normalize names for isHumongous() and friends. In-Reply-To: <54182C58.7020708@oracle.com> References: <54172772.3090308@twitter.com> <54182C58.7020708@oracle.com> Message-ID: <54215B33.7010708@oracle.com> Hi all, On 2014-09-16 14:26, Bengt Rutisson wrote: > > Hi Tony, > > On 2014-09-15 19:52, Tony Printezis wrote: >> Hi all, >> >> This is a follow-up to JDK-8057768, proposed by Thomas. It normalizes >> some of the humongous-related method names (and enums). The changes are: >> >> HeapRegion::isHumongous() -> is_humongous() >> HeapRegion::startsHumongous() -> is_starts_humongous() >> HeapRegion::continuesHumongous() -> is_continues_humongous() >> >> HeapRegion::set_startsHumongous() -> set_starts_humongous() >> HeapRegion::set_continuesHumongous() -> set_continues_humongous() >> >> HeapRegionType::HumMask -> HumongousMask >> HeapRegionType::HumStartsTag -> StartsHumongousTag >> HeapRegionType::HumContTag -> ContinuesHumongousTag >> >> G1CollectedHeap::isHumongous() -> is_humongous() >> >> Webrev is here: >> >> http://cr.openjdk.java.net/~tonyp/8058495/webrev.0/ > > Looks good. > >> >> Could I get a couple of reviews please (and a sponsor!!!)? :-) > > I can sponsor this. In order to avoid some merge conflicts I may wait > a couple of days before I push. But I'll handle it soon. Now it has been pushed. http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f29fc48b201f Thanks, Bengt > > Thanks, > Bengt > > >> >> Thanks, >> >> Tony >> > From sangheon.kim at oracle.com Tue Sep 23 13:31:14 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Tue, 23 Sep 2014 06:31:14 -0700 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations Message-ID: <54217622.8010100@oracle.com> Hi all, can I have reviews for the following small change that changes the uses of the "int" type for thread ids into uints like everywhere else? Thomas agreed to sponsor the change. CR: https://bugs.openjdk.java.net/browse/JDK-8036116 Webrev: http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ Testing: jprt Thanks, Sangheon From joseph.provino at oracle.com Tue Sep 23 13:38:02 2014 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 23 Sep 2014 09:38:02 -0400 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations In-Reply-To: <54217622.8010100@oracle.com> References: <54217622.8010100@oracle.com> Message-ID: <542177BA.4020800@oracle.com> Hi Sangheon, looks good to me. Note, I'm not a "Reviewer"... joe On 9/23/2014 9:31 AM, Sangheon Kim wrote: > Hi all, > > can I have reviews for the following small change that changes the > uses of the "int" type for thread ids into uints like everywhere else? > > Thomas agreed to sponsor the change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8036116 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ > > > Testing: jprt > > Thanks, > Sangheon From stefan.karlsson at oracle.com Tue Sep 23 13:48:23 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 23 Sep 2014 15:48:23 +0200 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations In-Reply-To: <54217622.8010100@oracle.com> References: <54217622.8010100@oracle.com> Message-ID: <54217A27.30303@oracle.com> Hi Sangheon, On 23/09/14 15:31, Sangheon Kim wrote: > Hi all, > > can I have reviews for the following small change that changes the > uses of the "int" type for thread ids into uints like everywhere else? > > Thomas agreed to sponsor the change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8036116 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ > The patch looks good. However, it is based against http://hg.openjdk.java.net/jdk9/dev/hotspot instead of http://hg.openjdk.java.net/jdk9/hs-gc/hotspot, where most of our changes should be pushed to. Parts of the code you change have already been removed in hs-gc. thanks, StefanK > > Testing: jprt > > Thanks, > Sangheon -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Tue Sep 23 15:15:58 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 23 Sep 2014 17:15:58 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints Message-ID: <54218EAE.3070002@oracle.com> Hi all, this small change enables us to skip two possible safepoints in CollectorPolicy::satisfy_failed_metadata_allocation: 1. When a thread continues a loop after having been stalled due to a GC_locker initiated Full GC. 2. When the VM_CollectForMetadata VM operation's prologue fails because a full GC has already been run just prior to the CollectForMetadata VM operation. The way this is done is simply by trying to allocate at the start of the loop. This way, whenever we loop around and a full GC has happened, the allocation request might be satisfied and we can do an early return. Webrev: http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8058963 Testing: - JPRT - Aurora: - Kitchensink - Weblogic+Medrec - runThese - vm.quick, regression, gc, compiler, runtime, parallel class loading, metaspace, oom - JTReg tests Thanks, Erik From jesper.wilhelmsson at oracle.com Tue Sep 23 19:41:15 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 23 Sep 2014 21:41:15 +0200 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <541C43AC.8070607@oracle.com> References: <541C43AC.8070607@oracle.com> Message-ID: <5421CCDB.1080103@oracle.com> Hi, It would be nice if the different TestShrinkAuxiliaryData##.java source files were identical except for the number. Currently in 0 the main method is before the test, 10 does not have an empty line between the methods, and 15-30 has an empty line before the first method that I don't think adds anything to the readability. I don't necessarily care about the exact layout, as long as all of them looks the same. The TEST.groups does not list the 30-version of the test. There are some inconsistencies in the formatting of TestShrinkAuxiliaryDataBase.java as well. Some methods starts with an empty line others do not, in some places there are spaces around arguments in function calls, some long lines are broken up on several lines others are not. All these are minor issues, but it would look nicer if it was consistent. Other than that it looks good. /Jesper Andrey Zakharov skrev 19/9/14 16:54: > Hello, team > Could you please review bunch of tests for feature > https://bugs.openjdk.java.net/browse/JDK-8038423: G1: Decommit memory within the > heap > > the inner scenario is allocate array of objects, link this objects to each > other, mutate some of this objects to fill RSet in G1 and deallocate objects. > inner test expected at least not growing commit memory size of heap and > non-heap. It's hard to separate featured non-heap usages from overall non-heap > usages of internal structures, so we can expect that non-heap commit memory size > can even grows up. > > outer test rotate *G1ConcRSLogCacheSize* and *ObjectAlignmentInBytes* (for > 64bits) options values and runs inner test. > *G1ConcRSLogCacheSize* is iterated from 0, 2^0 to 2^31, but test calculates > maximum available memory and use according pow of 2. > ObjectAlignmentInBytes is iterated from 2^3 to 2^8 > > As outer tests spawns an inner tests 6 times it needs a longer timeout = 120 > seconds * 6 = 720 seconds. > Also, I've separate 1 large test to several tests for different > G1ConcRSLogCacheSize options to avoid even longer timeout. > > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.00/ > > bug for test: > https://bugs.openjdk.java.net/browse/JDK-8043766 > > feature bug: > https://bugs.openjdk.java.net/browse/JDK-8038423 > > > > Thanks. > > From sangheon.kim at oracle.com Tue Sep 23 21:15:59 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Tue, 23 Sep 2014 14:15:59 -0700 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations In-Reply-To: <54217A27.30303@oracle.com> References: <54217622.8010100@oracle.com> <54217A27.30303@oracle.com> Message-ID: <5421E30F.1020404@oracle.com> Hi Stefan, Thanks for the point. Here is another webrev worked on "hs-gc". As you mentioned there are some difference between jdk9-dev and hs-gc. i.e. some functions are removed in g1ParScanTrheadState.hpp and g1ParScanTrheadState.inline.hpp in hs-gc. Webrev: http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.01/ Thanks, Sangheon On 09/23/2014 06:48 AM, Stefan Karlsson wrote: > Hi Sangheon, > > On 23/09/14 15:31, Sangheon Kim wrote: >> Hi all, >> >> can I have reviews for the following small change that changes the >> uses of the "int" type for thread ids into uints like everywhere else? >> >> Thomas agreed to sponsor the change. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8036116 >> >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ >> > > The patch looks good. However, it is based against > http://hg.openjdk.java.net/jdk9/dev/hotspot instead of > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot, where most of our > changes should be pushed to. Parts of the code you change have already > been removed in hs-gc. > > thanks, > StefanK > > >> >> Testing: jprt >> >> Thanks, >> Sangheon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Tue Sep 23 21:22:26 2014 From: derek.white at oracle.com (Derek White) Date: Tue, 23 Sep 2014 17:22:26 -0400 Subject: Ways to get gc stats programatically or logged? Message-ID: <5421E492.6000008@oracle.com> Hi All, I'm doing a writeup on a soft real-time system (robots for the FIRST Robotics Competition) and I'm looking for ways to get gc stats like max pause time and total gc time. I can sum up verbosegc numbers but I'd like to make this easy for some customers to run. I'd like to get these numbers in a production build, and both logged and display in some slick tool like visualvm. Any ideas? Thanks, - Derek From erik.osterlund at lnu.se Tue Sep 23 21:41:51 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 23 Sep 2014 21:41:51 +0000 Subject: Ways to get gc stats programatically or logged? In-Reply-To: <5421E492.6000008@oracle.com> References: <5421E492.6000008@oracle.com> Message-ID: <3F1815E0-798A-4643-A843-EEFA91FE7168@lnu.se> Think http://www.azulsystems.com/jHiccup gets the job done. /Erik On 23 Sep 2014, at 23:22, Derek White wrote: > Hi All, > > I'm doing a writeup on a soft real-time system (robots for the FIRST Robotics Competition) and I'm looking for ways to get gc stats like max pause time and total gc time. I can sum up verbosegc numbers but I'd like to make this easy for some customers to run. > > I'd like to get these numbers in a production build, and both logged and display in some slick tool like visualvm. > > Any ideas? > > Thanks, > - Derek > From chf at redhat.com Tue Sep 23 22:17:30 2014 From: chf at redhat.com (Christine Flood) Date: Tue, 23 Sep 2014 18:17:30 -0400 (EDT) Subject: Ways to get gc stats programatically or logged? In-Reply-To: <5421E492.6000008@oracle.com> References: <5421E492.6000008@oracle.com> Message-ID: <1406965811.42978597.1411510650136.JavaMail.zimbra@redhat.com> Hey Derek, how are you? If you are willing to use -XX:+UseSerialGC, -XX:+TraceGen0Time and -XX:+TraceGen1Time are available in product builds and give you some of what you are looking for. [Accumulated GC generation 0 time 0.0965850 secs, 3 GC's, avg GC time 0.0321950] [Accumulated GC generation 1 time 2.0486370 secs, 12 GC's, avg GC time 0.1707197] Christine ----- Original Message ----- > From: "Derek White" > To: hotspot-gc-dev at openjdk.java.net > Sent: Tuesday, September 23, 2014 5:22:26 PM > Subject: Ways to get gc stats programatically or logged? > > Hi All, > > I'm doing a writeup on a soft real-time system (robots for the FIRST > Robotics Competition) and I'm looking for ways to get gc stats like max > pause time and total gc time. I can sum up verbosegc numbers but I'd > like to make this easy for some customers to run. > > I'd like to get these numbers in a production build, and both logged and > display in some slick tool like visualvm. > > Any ideas? > > Thanks, > - Derek > > From staffan.friberg at oracle.com Tue Sep 23 22:59:43 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 23 Sep 2014 15:59:43 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <5418B6A5.8070609@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> <54178A86.4090500@oracle.com> <5418AE85.1070309@oracle.com> <5418B6A5.8070609@oracle.com> Message-ID: <5421FB5F.3090208@oracle.com> Anyone available to do a second review? Thanks, Staffan On 09/16/2014 03:16 PM, Vladimir Kozlov wrote: > Looks fine but you need to add '.' at the end of statements in the > comment you modified. No need for re-review. > > Thanks, > Vladimir > > On 9/16/14 2:41 PM, Staffan Friberg wrote: >> Thanks Vladimir, >> >> Updated with your suggestions. Added a small comment in >> g1_can_remove_pre_barrier method since the alloc == NULL check is quite >> a bit earlier. >> >> New webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.03 >> >> Cheers, >> Staffan >> >> >> On 09/15/2014 05:55 PM, Vladimir Kozlov wrote: >>> You need only check (alloc == st_alloc) because alloc != NULL at this >>> point: >>> >>> + if (st_alloc != NULL && alloc == st_alloc) { >>> >>> >>> You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == >>> NULL check). >>> >>> I would also reverse the last check there because you bailout from >>> loop anyway: >>> >>> + if (captured_store == NULL || captured_store == >>> st_init->zero_memory()) { >>> + return true; >>> + } >>> + } >>> + } >>> + >>> + // Unless there is an explicit 'continue', we must bail out here, >>> >>> >>> Vladimir >>> >>> On 9/15/14 3:31 PM, Staffan Friberg wrote: >>>> Hi Vladimir, >>>> >>>> Uploaded a new webrev with fixes to the below issues, >>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 >>>> >>>> Still removes expected barriers. >>>> >>>> Thanks, >>>> Staffan >>>> >>>> On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >>>>> Fix indention in 2 checks: >>>>> >>>>> + if (use_ReduceInitialCardMarks() && >>>>> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >>>>> >>>>> Typo 'iff' in both comments: >>>>> >>>>> + * Returns true iff the barrier can be removed >>>>> >>>>> In g1_can_remove_post_barrier() use: >>>>> >>>>> + // Start search from Store node >>>>> + Node* ctrl = store->in(MemNode::Control); >>>>> >>>>> Control edge can't point to an other Store so you should not check it >>>>> inside loop. >>>>> As result you don't need loop. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> I updated the documentation, and uploaded a new webrev, >>>>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>>>>> >>>>>> Thanks for agreeing to sponsor, and the good idea about pushing to >>>>>> hs-gc for extra coverage. >>>>>> >>>>>> Thanks, >>>>>> Staffan >>>>>> >>>>>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Copying both the compiler and GC alias as the optimization >>>>>>>> involves >>>>>>>> both >>>>>>>> groups. >>>>>>>> >>>>>>>> This optimization aims to avoid generating G1 barriers for newly >>>>>>>> allocated objects where the compiler can prove that the object >>>>>>>> has not >>>>>>>> been written to earlier and there is no safepoint between the >>>>>>>> allocation >>>>>>>> and the write. The bug has some further details and microbenchmark >>>>>>>> result. The new code has fairly extensive comments about the >>>>>>>> optimization. >>>>>>>> >>>>>>>> It would be great if the GC team can help validate that the >>>>>>>> premise of >>>>>>>> the optimization is correct as well. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>>>>> I mostly read through the comments since I can't decode what the IR >>>>>>> transforms >>>>>>> intend to do :) >>>>>>> >>>>>>> We usually stick to the terms "old generation" and "young >>>>>>> generation" instead >>>>>>> of "Old Space" and "Young Space". >>>>>>> >>>>>>> "G1 also requires to keep track of objects between different >>>>>>> + * regions to enable evacuation of old regions" >>>>>>> should probably be. >>>>>>> .."to keep track of references between different regions" >>>>>>> >>>>>>> I leave it to the compiler team to review the actual code changes. >>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>>>>> >>>>>>>> I would also need a sponsor for this change if it passes review. >>>>>>> I'll push this to hs-gc after review since we have more G1 test >>>>>>> coverage on >>>>>>> hs-gc. >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> Thanks, >>>>>>>> Staffan >>>>>> >>>> >> From ecki at zusammenkunft.net Tue Sep 23 23:19:22 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 24 Sep 2014 01:19:22 +0200 Subject: Ways to get gc stats programatically or logged? In-Reply-To: <5421E492.6000008@oracle.com> References: <5421E492.6000008@oracle.com> Message-ID: <20140924011922.0000442d.ecki@zusammenkunft.net> Hello, not sure how much automation you need and how much time you want to spend. But the open source GCViewer can parse and graph GClogs. It can also be used as a parser or to export it in CSV format. It is however not very complete with G1 events. https://github.com/chewiebug/GCViewer/wiki From inside the VM you can always sample the JMX MBeans provided by hotspot. Each pool can have a before/after statistic. But its not so fine grained than verbose GC logs are. And unfortunatelly you need to sample it as there are no notifications. The third option is I guess the flight recorder. As you are insise Oracle it should not be a too big of a problem. I however dont know how complete the events are. Gruss Bernd Am Tue, 23 Sep 2014 17:22:26 -0400 schrieb Derek White : > Hi All, > > I'm doing a writeup on a soft real-time system (robots for the FIRST > Robotics Competition) and I'm looking for ways to get gc stats like > max pause time and total gc time. I can sum up verbosegc numbers but > I'd like to make this easy for some customers to run. > > I'd like to get these numbers in a production build, and both logged > and display in some slick tool like visualvm. > > Any ideas? > > Thanks, > - Derek > From kirk at kodewerk.com Wed Sep 24 00:45:19 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 23 Sep 2014 17:45:19 -0700 Subject: Ways to get gc stats programatically or logged? In-Reply-To: <5421E492.6000008@oracle.com> References: <5421E492.6000008@oracle.com> Message-ID: <45E90AC4-88C8-415F-81B8-56EB0451F6BB@kodewerk.com> Hi Derek, I have a plugin that does stuff with these numbers. It?s called MemoryPoolView and it?s on java.net. Please contact me off list for more information. Kind regards Kirk Pepperdine On Sep 23, 2014, at 2:22 PM, Derek White wrote: > Hi All, > > I'm doing a writeup on a soft real-time system (robots for the FIRST Robotics Competition) and I'm looking for ways to get gc stats like max pause time and total gc time. I can sum up verbosegc numbers but I'd like to make this easy for some customers to run. > > I'd like to get these numbers in a production build, and both logged and display in some slick tool like visualvm. > > Any ideas? > > Thanks, > - Derek > -------------- 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 bengt.rutisson at oracle.com Wed Sep 24 08:01:10 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 24 Sep 2014 10:01:10 +0200 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations In-Reply-To: <5421E30F.1020404@oracle.com> References: <54217622.8010100@oracle.com> <54217A27.30303@oracle.com> <5421E30F.1020404@oracle.com> Message-ID: <54227A46.7060505@oracle.com> Hi Sangheon, On 2014-09-23 23:15, Sangheon Kim wrote: > Hi Stefan, > > Thanks for the point. > Here is another webrev worked on "hs-gc". > As you mentioned there are some difference between jdk9-dev and hs-gc. > i.e. some functions are removed in g1ParScanTrheadState.hpp and > g1ParScanTrheadState.inline.hpp in hs-gc. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.01/ > Latest webrev looks good to me. Thanks, Bengt > > Thanks, > Sangheon > > > On 09/23/2014 06:48 AM, Stefan Karlsson wrote: >> Hi Sangheon, >> >> On 23/09/14 15:31, Sangheon Kim wrote: >>> Hi all, >>> >>> can I have reviews for the following small change that changes the >>> uses of the "int" type for thread ids into uints like everywhere else? >>> >>> Thomas agreed to sponsor the change. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8036116 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ >>> >> >> The patch looks good. However, it is based against >> http://hg.openjdk.java.net/jdk9/dev/hotspot instead of >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot, where most of our >> changes should be pushed to. Parts of the code you change have >> already been removed in hs-gc. >> >> thanks, >> StefanK >> >> >>> >>> Testing: jprt >>> >>> Thanks, >>> Sangheon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Wed Sep 24 08:15:26 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 24 Sep 2014 10:15:26 +0200 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations In-Reply-To: <5421E30F.1020404@oracle.com> References: <54217622.8010100@oracle.com> <54217A27.30303@oracle.com> <5421E30F.1020404@oracle.com> Message-ID: <54227D9E.80803@oracle.com> On 23/09/14 23:15, Sangheon Kim wrote: > Hi Stefan, > > Thanks for the point. > Here is another webrev worked on "hs-gc". > As you mentioned there are some difference between jdk9-dev and hs-gc. > i.e. some functions are removed in g1ParScanTrheadState.hpp and > g1ParScanTrheadState.inline.hpp in hs-gc. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.01/ > Looks good. StefanK > > Thanks, > Sangheon > > > On 09/23/2014 06:48 AM, Stefan Karlsson wrote: >> Hi Sangheon, >> >> On 23/09/14 15:31, Sangheon Kim wrote: >>> Hi all, >>> >>> can I have reviews for the following small change that changes the >>> uses of the "int" type for thread ids into uints like everywhere else? >>> >>> Thomas agreed to sponsor the change. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8036116 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ >>> >> >> The patch looks good. However, it is based against >> http://hg.openjdk.java.net/jdk9/dev/hotspot instead of >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot, where most of our >> changes should be pushed to. Parts of the code you change have >> already been removed in hs-gc. >> >> thanks, >> StefanK >> >> >>> >>> Testing: jprt >>> >>> Thanks, >>> Sangheon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Wed Sep 24 08:11:23 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 24 Sep 2014 12:11:23 +0400 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <5421CCDB.1080103@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> Message-ID: <54227CAB.6000703@oracle.com> Andrey, I would also suggest to eliminate inheritance and directly instantiate TestShrinkAuxiliaryDataBase in all your tests. Regards, Filipp. On 09/23/2014 11:41 PM, Jesper Wilhelmsson wrote: > Hi, > > It would be nice if the different TestShrinkAuxiliaryData##.java source files > were identical except for the number. Currently in 0 the main method is before > the test, 10 does not have an empty line between the methods, and 15-30 has an > empty line before the first method that I don't think adds anything to the > readability. I don't necessarily care about the exact layout, as long as all > of them looks the same. > > The TEST.groups does not list the 30-version of the test. > > There are some inconsistencies in the formatting of > TestShrinkAuxiliaryDataBase.java as well. Some methods starts with an empty > line others do not, in some places there are spaces around arguments in > function calls, some long lines are broken up on several lines others are not. > All these are minor issues, but it would look nicer if it was consistent. > > Other than that it looks good. > /Jesper > > Andrey Zakharov skrev 19/9/14 16:54: >> Hello, team >> Could you please review bunch of tests for feature >> https://bugs.openjdk.java.net/browse/JDK-8038423: G1: Decommit memory within the >> heap >> >> the inner scenario is allocate array of objects, link this objects to each >> other, mutate some of this objects to fill RSet in G1 and deallocate objects. >> inner test expected at least not growing commit memory size of heap and >> non-heap. It's hard to separate featured non-heap usages from overall non-heap >> usages of internal structures, so we can expect that non-heap commit memory size >> can even grows up. >> >> outer test rotate *G1ConcRSLogCacheSize* and *ObjectAlignmentInBytes* (for >> 64bits) options values and runs inner test. >> *G1ConcRSLogCacheSize* is iterated from 0, 2^0 to 2^31, but test calculates >> maximum available memory and use according pow of 2. >> ObjectAlignmentInBytes is iterated from 2^3 to 2^8 >> >> As outer tests spawns an inner tests 6 times it needs a longer timeout = 120 >> seconds * 6 = 720 seconds. >> Also, I've separate 1 large test to several tests for different >> G1ConcRSLogCacheSize options to avoid even longer timeout. >> >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.00/ >> >> bug for test: >> https://bugs.openjdk.java.net/browse/JDK-8043766 >> >> feature bug: >> https://bugs.openjdk.java.net/browse/JDK-8038423 >> >> >> >> Thanks. >> >> From bengt.rutisson at oracle.com Wed Sep 24 10:49:19 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 24 Sep 2014 12:49:19 +0200 Subject: RFR (S): JDK-8031116 : Fix thread-id types in G1 remembered set implementations In-Reply-To: <54227D9E.80803@oracle.com> References: <54217622.8010100@oracle.com> <54217A27.30303@oracle.com> <5421E30F.1020404@oracle.com> <54227D9E.80803@oracle.com> Message-ID: <5422A1AF.6010800@oracle.com> On 2014-09-24 10:15, Stefan Karlsson wrote: > On 23/09/14 23:15, Sangheon Kim wrote: >> Hi Stefan, >> >> Thanks for the point. >> Here is another webrev worked on "hs-gc". >> As you mentioned there are some difference between jdk9-dev and >> hs-gc. i.e. some functions are removed in g1ParScanTrheadState.hpp >> and g1ParScanTrheadState.inline.hpp in hs-gc. >> >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.01/ >> > > Looks good. I went a head and pushed this. Here's the changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/cedaeee5e645 Thanks, Bengt > > StefanK >> >> Thanks, >> Sangheon >> >> >> On 09/23/2014 06:48 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 23/09/14 15:31, Sangheon Kim wrote: >>>> Hi all, >>>> >>>> can I have reviews for the following small change that changes the >>>> uses of the "int" type for thread ids into uints like everywhere else? >>>> >>>> Thomas agreed to sponsor the change. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8036116 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8036116-kim/webrev.00/ >>>> >>> >>> The patch looks good. However, it is based against >>> http://hg.openjdk.java.net/jdk9/dev/hotspot instead of >>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot, where most of our >>> changes should be pushed to. Parts of the code you change have >>> already been removed in hs-gc. >>> >>> thanks, >>> StefanK >>> >>> >>>> >>>> Testing: jprt >>>> >>>> Thanks, >>>> Sangheon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Wed Sep 24 15:51:39 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Wed, 24 Sep 2014 08:51:39 -0700 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags Message-ID: <5422E88B.60408@oracle.com> Hi all, can I have reviews for the following small change to update G1ConcRefinementThreads variable? And also I need a sponsor for this. CR: https://bugs.openjdk.java.net/browse/JDK-8047976 Webrev: http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ Testing: jprt Thanks, Sangheon From jesper.wilhelmsson at oracle.com Wed Sep 24 16:35:56 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 24 Sep 2014 18:35:56 +0200 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <5422E88B.60408@oracle.com> References: <5422E88B.60408@oracle.com> Message-ID: <5422F2EC.3050303@oracle.com> Looks good. I can sponsor this. /Jesper Sangheon Kim skrev 24/9/14 17:51: > Hi all, > > can I have reviews for the following small change to update > G1ConcRefinementThreads variable? > And also I need a sponsor for this. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8047976 > > Webrev: > http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ > > > Testing: jprt > > Thanks, > Sangheon From andrey.x.zakharov at oracle.com Wed Sep 24 17:26:02 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Wed, 24 Sep 2014 21:26:02 +0400 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <54227CAB.6000703@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> Message-ID: <5422FEAA.1070806@oracle.com> Hi, all Thanks for comments! here is updated webrev with code cleanup and removed redundant inheritance http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.01/ Thanks. On 24.09.2014 12:11, Filipp Zhinkin wrote: > Andrey, > > I would also suggest to eliminate inheritance and directly instantiate > TestShrinkAuxiliaryDataBase in all your tests. > > Regards, > Filipp. > > On 09/23/2014 11:41 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> It would be nice if the different TestShrinkAuxiliaryData##.java >> source files were identical except for the number. Currently in 0 the >> main method is before the test, 10 does not have an empty line >> between the methods, and 15-30 has an empty line before the first >> method that I don't think adds anything to the readability. I don't >> necessarily care about the exact layout, as long as all of them looks >> the same. >> >> The TEST.groups does not list the 30-version of the test. >> >> There are some inconsistencies in the formatting of >> TestShrinkAuxiliaryDataBase.java as well. Some methods starts with an >> empty line others do not, in some places there are spaces around >> arguments in function calls, some long lines are broken up on several >> lines others are not. >> All these are minor issues, but it would look nicer if it was >> consistent. >> >> Other than that it looks good. >> /Jesper >> >> Andrey Zakharov skrev 19/9/14 16:54: >>> Hello, team >>> Could you please review bunch of tests for feature >>> https://bugs.openjdk.java.net/browse/JDK-8038423: G1: Decommit >>> memory within the >>> heap >>> >>> the inner scenario is allocate array of objects, link this objects >>> to each >>> other, mutate some of this objects to fill RSet in G1 and deallocate >>> objects. >>> inner test expected at least not growing commit memory size of heap and >>> non-heap. It's hard to separate featured non-heap usages from >>> overall non-heap >>> usages of internal structures, so we can expect that non-heap commit >>> memory size >>> can even grows up. >>> >>> outer test rotate *G1ConcRSLogCacheSize* and >>> *ObjectAlignmentInBytes* (for >>> 64bits) options values and runs inner test. >>> *G1ConcRSLogCacheSize* is iterated from 0, 2^0 to 2^31, but test >>> calculates >>> maximum available memory and use according pow of 2. >>> ObjectAlignmentInBytes is iterated from 2^3 to 2^8 >>> >>> As outer tests spawns an inner tests 6 times it needs a longer >>> timeout = 120 >>> seconds * 6 = 720 seconds. >>> Also, I've separate 1 large test to several tests for different >>> G1ConcRSLogCacheSize options to avoid even longer timeout. >>> >>> webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.00/ >>> >>> bug for test: >>> https://bugs.openjdk.java.net/browse/JDK-8043766 >>> >>> feature bug: >>> https://bugs.openjdk.java.net/browse/JDK-8038423 >>> >>> >>> >>> Thanks. >>> >>> > From jesper.wilhelmsson at oracle.com Wed Sep 24 17:54:30 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 24 Sep 2014 19:54:30 +0200 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <5422FEAA.1070806@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> Message-ID: <54230556.3080109@oracle.com> This looks much better! Thanks for fixing this! Ship it. /Jesper Andrey Zakharov skrev 24/9/14 19:26: > Hi, all > Thanks for comments! > > here is updated webrev with code cleanup and removed redundant inheritance > > http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.01/ > > Thanks. > > On 24.09.2014 12:11, Filipp Zhinkin wrote: >> Andrey, >> >> I would also suggest to eliminate inheritance and directly instantiate >> TestShrinkAuxiliaryDataBase in all your tests. >> >> Regards, >> Filipp. >> >> On 09/23/2014 11:41 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> It would be nice if the different TestShrinkAuxiliaryData##.java source files >>> were identical except for the number. Currently in 0 the main method is >>> before the test, 10 does not have an empty line between the methods, and >>> 15-30 has an empty line before the first method that I don't think adds >>> anything to the readability. I don't necessarily care about the exact >>> layout, as long as all of them looks the same. >>> >>> The TEST.groups does not list the 30-version of the test. >>> >>> There are some inconsistencies in the formatting of >>> TestShrinkAuxiliaryDataBase.java as well. Some methods starts with an empty >>> line others do not, in some places there are spaces around arguments in >>> function calls, some long lines are broken up on several lines others are not. >>> All these are minor issues, but it would look nicer if it was consistent. >>> >>> Other than that it looks good. >>> /Jesper >>> >>> Andrey Zakharov skrev 19/9/14 16:54: >>>> Hello, team >>>> Could you please review bunch of tests for feature >>>> https://bugs.openjdk.java.net/browse/JDK-8038423: G1: Decommit memory within >>>> the >>>> heap >>>> >>>> the inner scenario is allocate array of objects, link this objects to each >>>> other, mutate some of this objects to fill RSet in G1 and deallocate objects. >>>> inner test expected at least not growing commit memory size of heap and >>>> non-heap. It's hard to separate featured non-heap usages from overall non-heap >>>> usages of internal structures, so we can expect that non-heap commit memory >>>> size >>>> can even grows up. >>>> >>>> outer test rotate *G1ConcRSLogCacheSize* and *ObjectAlignmentInBytes* (for >>>> 64bits) options values and runs inner test. >>>> *G1ConcRSLogCacheSize* is iterated from 0, 2^0 to 2^31, but test calculates >>>> maximum available memory and use according pow of 2. >>>> ObjectAlignmentInBytes is iterated from 2^3 to 2^8 >>>> >>>> As outer tests spawns an inner tests 6 times it needs a longer timeout = 120 >>>> seconds * 6 = 720 seconds. >>>> Also, I've separate 1 large test to several tests for different >>>> G1ConcRSLogCacheSize options to avoid even longer timeout. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.00/ >>>> >>>> bug for test: >>>> https://bugs.openjdk.java.net/browse/JDK-8043766 >>>> >>>> feature bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8038423 >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >> > From derek.white at oracle.com Wed Sep 24 21:26:17 2014 From: derek.white at oracle.com (Derek White) Date: Wed, 24 Sep 2014 17:26:17 -0400 Subject: Ways to get gc stats programatically or logged? In-Reply-To: <5421E492.6000008@oracle.com> References: <5421E492.6000008@oracle.com> Message-ID: <542336F9.80009@oracle.com> Thanks everyone, that was some great information! - Derek On 9/23/14, 5:22 PM, Derek White wrote: > Hi All, > > I'm doing a writeup on a soft real-time system (robots for the FIRST > Robotics Competition) and I'm looking for ways to get gc stats like > max pause time and total gc time. I can sum up verbosegc numbers but > I'd like to make this easy for some customers to run. > > I'd like to get these numbers in a production build, and both logged > and display in some slick tool like visualvm. > > Any ideas? > > Thanks, > - Derek > From thomas.schatzl at oracle.com Thu Sep 25 07:32:33 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 25 Sep 2014 09:32:33 +0200 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <5422E88B.60408@oracle.com> References: <5422E88B.60408@oracle.com> Message-ID: <1411630353.2707.9.camel@cirrus> Hi, On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: > Hi all, > > can I have reviews for the following small change to update > G1ConcRefinementThreads variable? > And also I need a sponsor for this. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8047976 > > Webrev: > http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ > Please update the flag during argument processing, not every time the method is called. Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think. Thanks, Thomas From mikael.gerdin at oracle.com Thu Sep 25 07:34:10 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 25 Sep 2014 09:34:10 +0200 Subject: RFR [8u40] 8048268, 8057722 Code root migration In-Reply-To: <5420005D.4020003@oracle.com> References: <1764736.3hHflHvShp@mgerdin03> <5420005D.4020003@oracle.com> Message-ID: <42779946.qNALFltajV@mgerdin03> On Monday 22 September 2014 12.56.29 Bengt Rutisson wrote: > Hi Mikael, Thanks Bengt, Thomas for the reviews. I'm all set to push this now. /Mikael > > On 2014-09-17 09:07, Mikael Gerdin wrote: > > Hi all, > > > > I'd like to backport 8048268 and the related bugfix 8057722 to 8u40 to > > reduce the performance impact of code root migration. > > > > The original patch for 8048268 did not apply cleanly due to some spelling > > and style changes. > > > > These changes depend on 8056084 which is out for review on hotspot-dev. > > I plan to push these changes together once they're through review. > > > > Review threads: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010582.h > > tml > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-September/0107 > > 09.html > > > > Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8048268 > > I didn't look through all the changes for 8048268. When I tried the > backport myself the only conflict I got was the spelling fix of > "successfully" in g1CollectedHeap.hpp. If that was the only conflict you > got then your backport looks good. > > > https://bugs.openjdk.java.net/browse/JDK-8057722 > > Looks good. > > Bengt > > > Webrevs: > > http://cr.openjdk.java.net/~mgerdin/8048268/8u/webrev/ > > http://cr.openjdk.java.net/~mgerdin/8057722/8u/webrev/ > > > > /Mikael From thomas.schatzl at oracle.com Thu Sep 25 09:01:09 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 25 Sep 2014 11:01:09 +0200 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <1411630353.2707.9.camel@cirrus> References: <5422E88B.60408@oracle.com> <1411630353.2707.9.camel@cirrus> Message-ID: <1411635669.2707.18.camel@cirrus> Hi, On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote: > Hi, > > On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: > > Hi all, > > > > can I have reviews for the following small change to update > > G1ConcRefinementThreads variable? > > And also I need a sponsor for this. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8047976 > > > > Webrev: > > http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ > > > > Please update the flag during argument processing, not every time the > method is called. > > Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think. > Please also add a jtreg test case. At least one test case that verifies that with G1 the G1ConcRefinementThreads is not zero if nothing or zero is passed, and another one that checks that the value passed is taken over. The test could parse the output of -XX:+PrintFlagsFinal. The test gc/arguments/TestObjectTenuringFlags.java shows how this is done. There is also some behavior that seems to be wrong: if you manually set the number of G1ConcRefinementThreads to zero (which means "automatically select"), -XX:+PrintFlagsFinal still prints "G1ConcRefinementThreads := 0". Imo even in this case the output should contain the actual number of threads used. At least if you set ConcGCThreads manually to 0, the flag is set to the actual value after argument processing. ParallelGCThreads also shows 0 here, but I think this part of bug JDK-6979279 and should be fixed there. Thanks, Thomas From marcus.larsson at oracle.com Thu Sep 25 10:28:15 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 25 Sep 2014 12:28:15 +0200 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <250318A9-D40B-4DF8-A9F2-30BF9A5828B7@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> <540D9052.7030608@oracle.com> <250318A9-D40B-4DF8-A9F2-30BF9A5828B7@oracle.com> Message-ID: <5423EE3F.3050203@oracle.com> Hi Kim, I appreciate your feedback on this. Some comments are inline. On 09/19/2014 08:52 PM, Kim Barrett wrote: > On Sep 8, 2014, at 7:17 AM, Marcus Larsson wrote: >> New webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8043243v2/ > Sorry for the late review; I was on vacation and only now catching up > on this. > > This change replaces some macros with function templates. These > function templates take a "space" argument and require that it support > a specific protocol. Actually, there seem to be two protocols, one a > subset of the other: > > // base protocol > HeapWord* scan_limit(space*) > bool block_is_obj(space*, const HeapWord*) > size_t block_size(space*, const HeapWord*) > > // addtional protocol > size_t adjust_obj_size(space*, size_t) > size_t obj_size(space*, const HeapWord*) > > [Not sure why space arguments are not const in most or all cases.] This was also my first thought, but after digging deeper I found that there's really only a single protocol. (Either that, or you could say there are three protocols, one for each template function.) Each subclass of CompactibleSpace seems to make use of all of the template functions, sometimes via CompactibleSpace::adjust_pointers/compact, and hence require all of the above functions (both protocols), although they sometimes also override these functions when necessary. > The "usual" way to do that is with virtual functions declared in the > base class and implemented in the derived classes. I'm going to > ignore that approach, as I suspect it was (probably correctly) deemed > too expensive in performace for these operations that look to be > fairly light weight and probably performance critical. I also put > "usual" in quotes, since in some communities or contexts that would > not at all be the preferred approach. > > A point of nomenclature: the proposed code uses the term "proxy", > where I think the more usual terminology (per Gang-of-Four) would be > "adaptor" (or "adapter" - the C++ community seems to prefer the -or > spelling, GoF uses -er). > > One thing that is missing is any definition of the "concepts" required > by these function templates. Presently that's only implicitly encoded > in the calls made by those functions, and by the definitions of the > new "proxy" classes. There really should be at least documentation > associated with the functions describing their requirements. Code to > check the arguments satisfy those requirements would be better, but I > don't think hotspot has any infrastructure to help with that. I added some comments trying to document the requirements on the SpaceTypes for these functions. > > The function templates are declared as ordinary member functions > rather than static member functions, with the requirement that they > will be called with "this" as the first (space) argument, e.g. > "this == space" > is a requirement for these functions. That should be asserted, or > these functions should be static member functions. I don't know if > the latter will work without further changes; there might be uses of > the implicit this in the current implementations of these functions, > which may argue that the presently implicit "concept" definitions are > incomplete. Changed the template functions to be static instead, like they probably should have been from the beginning. The previous solution had some functions called via the implicit "this", while others were called using the proxy. > > The proposed adaptation mechanism is to provide an auxiliary class > providing static functions on the space value that forward to related > functions in that object. > > Alternatives that come to mind that I like better include: > > - Add the needed functions to the associated classes, rather than > providing auxiliary forwarding classes. Note that this doesn't > involve virtual functions; I'm suggesting static polymorphism here, > not runtime polymorphism. These should be ordinary member functions > invoked as space->fn(). [They could instead be static member > functions taking space as an argument, but then they would need to be > called as SpaceType::fn(space), which doesn't seem like an > improvement.] This is, of course, an intrusive approach, but the scan > function templates are in the API of a base class, so providing > support directly in the derived classes is reasonable. I think this is a good idea, and modified the changeset to use this alternative rather than the auxiliary proxy/adapter classes. To avoid name collisions, the block_is_obj and block_size functions used during scanning were named scanned_block_is_obj and scanned_block_size. To allow non-virtual calls of block_size for HeapRegions I moved the prepare_for_compaction from G1OffsetTableContigSpace to the HeapRegion class, and implemented the required functions in this class instead. > > - Add free functions with overloads for the relevant classes. Lack of > namespace usage in hotspot might make this less attractive. Also, > there aren't good primary / default definitions available for most or > all of these operations. > > Assuming the auxiliary class approach is retained, the current > implementation has the adaptor (called proxy) type as a template > parameter that the caller must explicitly supply. A better approach > would be to compute the adaptor type from the space type in the body > of the function templates. > > The adaptor type could be added directly to the relevant space types > as a public typedef, e.g. in each class add > > typedef ADAPTOR_TYPE ScanAdaptor; > > A non-intrusive approach would be to provide a metafunction for > mapping from space type to adaptor type, e.g. > > - Add to CompactibleSpace class > > template struct ScanAdaptor; > > - For each space class that requires scan adaptation, define > > template<> > struct CompactibleSpace::ScanAdaptor { > typedef ADAPTOR_TYPE type; > }; > > Then, in each of the scan templates, eliminate the SpaceProxy template > parameter and add one of the following typedefs to the body, as > appropriate for the computation approach: > > typedef typename SpaceType::ScanAdaptor SpaceProxy; > > or > > typedef typename CompactibleSpace::ScanAdaptor::type SpaceProxy; > > [possibly renaming SpaceProxy] > > This eliminates the need for callers to explicitly specify the adaptor > type in calls to the scan functions. > > There are other approaches to this whole problem, such as using CRTP > (the Curiously Recurring Template Pattern) but that would be > substantially further from the presently proposed changes, and I think > not necessarily better in this case, so I'm not going to discuss that > further. > > That's a lot of commentary, with several possible options, so I'll be > specific about what I currently think should be done. > > - Document the requirements of the new function templates on their > space argument, e.g. what operations must SpaceType provide. [Some > documentation about what these functions do might be nice too.] > > - Change the new function templates to be static member functions > rather than ordinary member functions, or if that is too onerous > then at least assert this == space. > > - Add the needed operations directly to the relevant classes, as > ordinary member functions, and eliminate the auxiliary classes. > Alternatively, if the auxiliary class approach is preferred by > others, then compute that class from the space class by one of the > methods suggested above. > As a side note I was unable to compile this with disabled precompiled headers, so the new changeset also has some some new #includes to fix this. New webrev: http://cr.openjdk.java.net/~mlarsson/8043243/webrev.00/ Regards, Marcus From thomas.schatzl at oracle.com Thu Sep 25 11:08:14 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 25 Sep 2014 13:08:14 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over In-Reply-To: <541C0FED.90200@oracle.com> References: <5412E184.70700@oracle.com> <1410872796.2755.45.camel@cirrus> <541C0FED.90200@oracle.com> Message-ID: <1411643294.2707.24.camel@cirrus> Hi Marcus, On Fri, 2014-09-19 at 13:13 +0200, Marcus Larsson wrote: > Hi Thomas, thanks for reviewing! > [...] >New webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8058298v2/ > > Changes from previous webrev: > http://cr.openjdk.java.net/~brutisso/webrev-8058298v1-v2/ > thanks for the changes, look good. One final request :) Is it possible to make the HRClaimer of G1ParRemoveSelfForwardPtrsTask a member of the task like it is done for all the other tasks? Then we would also get rid of the parameterless constructor for HeapRegionClaimer. I saw that you are also working on "JDK-6979279: remove special-case code for ParallelGCThreads==0". With that change, G1CollectedHeap::use_parallel_gc_threads() would be always true, allowing to make HeapRegionClaimer::initialize() private. Thanks, Thomas From andrey.x.zakharov at oracle.com Thu Sep 25 16:28:30 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 25 Sep 2014 20:28:30 +0400 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <5422FEAA.1070806@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> Message-ID: <542442AE.4040701@oracle.com> BTW, tested in aurora with latest jdk 8 updates 593423.ute.hs_jtreg.accept.full Thanks! On 24.09.2014 21:26, Andrey Zakharov wrote: > Hi, all > Thanks for comments! > > here is updated webrev with code cleanup and removed redundant > inheritance > > http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.01/ > > Thanks. > > On 24.09.2014 12:11, Filipp Zhinkin wrote: >> Andrey, >> >> I would also suggest to eliminate inheritance and directly >> instantiate TestShrinkAuxiliaryDataBase in all your tests. >> >> Regards, >> Filipp. >> >> On 09/23/2014 11:41 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> It would be nice if the different TestShrinkAuxiliaryData##.java >>> source files were identical except for the number. Currently in 0 >>> the main method is before the test, 10 does not have an empty line >>> between the methods, and 15-30 has an empty line before the first >>> method that I don't think adds anything to the readability. I don't >>> necessarily care about the exact layout, as long as all of them >>> looks the same. >>> >>> The TEST.groups does not list the 30-version of the test. >>> >>> There are some inconsistencies in the formatting of >>> TestShrinkAuxiliaryDataBase.java as well. Some methods starts with >>> an empty line others do not, in some places there are spaces around >>> arguments in function calls, some long lines are broken up on >>> several lines others are not. >>> All these are minor issues, but it would look nicer if it was >>> consistent. >>> >>> Other than that it looks good. >>> /Jesper >>> >>> Andrey Zakharov skrev 19/9/14 16:54: >>>> Hello, team >>>> Could you please review bunch of tests for feature >>>> https://bugs.openjdk.java.net/browse/JDK-8038423: G1: Decommit >>>> memory within the >>>> heap >>>> >>>> the inner scenario is allocate array of objects, link this objects >>>> to each >>>> other, mutate some of this objects to fill RSet in G1 and >>>> deallocate objects. >>>> inner test expected at least not growing commit memory size of heap >>>> and >>>> non-heap. It's hard to separate featured non-heap usages from >>>> overall non-heap >>>> usages of internal structures, so we can expect that non-heap >>>> commit memory size >>>> can even grows up. >>>> >>>> outer test rotate *G1ConcRSLogCacheSize* and >>>> *ObjectAlignmentInBytes* (for >>>> 64bits) options values and runs inner test. >>>> *G1ConcRSLogCacheSize* is iterated from 0, 2^0 to 2^31, but test >>>> calculates >>>> maximum available memory and use according pow of 2. >>>> ObjectAlignmentInBytes is iterated from 2^3 to 2^8 >>>> >>>> As outer tests spawns an inner tests 6 times it needs a longer >>>> timeout = 120 >>>> seconds * 6 = 720 seconds. >>>> Also, I've separate 1 large test to several tests for different >>>> G1ConcRSLogCacheSize options to avoid even longer timeout. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8043766/webrev.00/ >>>> >>>> bug for test: >>>> https://bugs.openjdk.java.net/browse/JDK-8043766 >>>> >>>> feature bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8038423 >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >> > From kim.barrett at oracle.com Thu Sep 25 21:48:11 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 25 Sep 2014 17:48:11 -0400 Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods In-Reply-To: <5423EE3F.3050203@oracle.com> References: <53FF16B0.4090809@oracle.com> <53FF1D0F.8030906@oracle.com> <540D9052.7030608@oracle.com> <250318A9-D40B-4DF8-A9F2-30BF9A5828B7@oracle.com> <5423EE3F.3050203@oracle.com> Message-ID: <892B5C0B-05AE-43E0-A769-DDDAA96CCA87@oracle.com> On Sep 25, 2014, at 6:28 AM, Marcus Larsson wrote: > > I appreciate your feedback on this. Some comments are inline. And any responses similarly. I?ll comment on the new webrev separately. > On 09/19/2014 08:52 PM, Kim Barrett wrote: > This was also my first thought, but after digging deeper I found that there's really only a single protocol. > (Either that, or you could say there are three protocols, one for each template function.) > Each subclass of CompactibleSpace seems to make use of all of the template functions, > sometimes via CompactibleSpace::adjust_pointers/compact, and hence require all of the above functions > (both protocols), although they sometimes also override these functions when necessary. Yes. I was a bit confused previously. Fortunately, it seems like the direction of the changes I suggested was still reasonably valid. > Changed the template functions to be static instead, like they probably should have been from the beginning. > The previous solution had some functions called via the implicit "this", while others were called using the proxy. I suspected as much. > To allow non-virtual calls of block_size for HeapRegions I moved the prepare_for_compaction from G1OffsetTableContigSpace > to the HeapRegion class, and implemented the required functions in this class instead. Hm, this might be worrying, or might not. I?ll need to look at the webrev to understand this. From mikael.gerdin at oracle.com Fri Sep 26 08:06:42 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 26 Sep 2014 10:06:42 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <54218EAE.3070002@oracle.com> References: <54218EAE.3070002@oracle.com> Message-ID: <2165163.QVx9T10jn1@mgerdin03> Hi Erik, On Tuesday 23 September 2014 17.15.58 Erik Helin wrote: > Hi all, > > this small change enables us to skip two possible safepoints in > CollectorPolicy::satisfy_failed_metadata_allocation: > > 1. When a thread continues a loop after having been stalled due to a > GC_locker initiated Full GC. > 2. When the VM_CollectForMetadata VM operation's prologue fails because > a full GC has already been run just prior to the CollectForMetadata VM > operation. > > The way this is done is simply by trying to allocate at the start of the > loop. This way, whenever we loop around and a full GC has happened, the > allocation request might be satisfied and we can do an early return. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ Change looks good. /Mikael > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8058963 > > Testing: > - JPRT > - Aurora: > - Kitchensink > - Weblogic+Medrec > - runThese > - vm.quick, regression, gc, compiler, runtime, parallel class loading, > metaspace, oom > - JTReg tests > > Thanks, > Erik From bengt.rutisson at oracle.com Fri Sep 26 08:04:40 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 26 Sep 2014 10:04:40 +0200 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <1411635669.2707.18.camel@cirrus> References: <5422E88B.60408@oracle.com> <1411630353.2707.9.camel@cirrus> <1411635669.2707.18.camel@cirrus> Message-ID: <54251E18.1020006@oracle.com> Hi all, Here's an updated webrev from Sangheon: http://cr.openjdk.java.net/~brutisso/8047976/webrev.02/ From Sangheon: "This includes Thomas's comments about: 1) Moving value set to Arguments::set_g1_gc_flags() 2) Adding jtreg test for G1ConcRefinementThreads variable" Thanks, Bengt On 2014-09-25 11:01, Thomas Schatzl wrote: > Hi, > > On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote: >> Hi, >> >> On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: >>> Hi all, >>> >>> can I have reviews for the following small change to update >>> G1ConcRefinementThreads variable? >>> And also I need a sponsor for this. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8047976 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ >>> >> Please update the flag during argument processing, not every time the >> method is called. >> >> Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think. >> > Please also add a jtreg test case. At least one test case that verifies > that with G1 the G1ConcRefinementThreads is not zero if nothing or zero > is passed, and another one that checks that the value passed is taken > over. > > The test could parse the output of -XX:+PrintFlagsFinal. The test > gc/arguments/TestObjectTenuringFlags.java shows how this is done. > > There is also some behavior that seems to be wrong: if you manually set > the number of G1ConcRefinementThreads to zero (which means > "automatically select"), -XX:+PrintFlagsFinal still prints > "G1ConcRefinementThreads := 0". Imo even in this case the output should > contain the actual number of threads used. > > At least if you set ConcGCThreads manually to 0, the flag is set to the > actual value after argument processing. > > ParallelGCThreads also shows 0 here, but I think this part of bug > JDK-6979279 and should be fixed there. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Fri Sep 26 08:40:48 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 26 Sep 2014 10:40:48 +0200 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <54251E18.1020006@oracle.com> References: <5422E88B.60408@oracle.com> <1411630353.2707.9.camel@cirrus> <1411635669.2707.18.camel@cirrus> <54251E18.1020006@oracle.com> Message-ID: <1411720848.2689.5.camel@cirrus> Hi Sangheon, On Fri, 2014-09-26 at 10:04 +0200, Bengt Rutisson wrote: > Hi all, > > Here's an updated webrev from Sangheon: > > http://cr.openjdk.java.net/~brutisso/8047976/webrev.02/ > > From Sangheon: > > "This includes Thomas's comments about: > 1) Moving value set to Arguments::set_g1_gc_flags() > 2) Adding jtreg test for G1ConcRefinementThreads variable" The changes in the Hotspot code look okay to me. Thanks! Some comments about the test case code: - There is a typo in AUTO_SELCT_THREADS_COUNT, should be AUTO_SELECT_THREADS_COUNT I think. - There is no need to have @build and @run lines if you do not use special options to invoke the test afaik. Otherwise looks okay. Thanks, Thomas > > Thanks, > Bengt > > > On 2014-09-25 11:01, Thomas Schatzl wrote: > > Hi, > > > > On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote: > >> Hi, > >> > >> On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: > >>> Hi all, > >>> > >>> can I have reviews for the following small change to update > >>> G1ConcRefinementThreads variable? > >>> And also I need a sponsor for this. > >>> > >>> CR: > >>> https://bugs.openjdk.java.net/browse/JDK-8047976 > >>> > >>> Webrev: > >>> http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ > >>> > >> Please update the flag during argument processing, not every time the > >> method is called. > >> > >> Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think. > >> > > Please also add a jtreg test case. At least one test case that verifies > > that with G1 the G1ConcRefinementThreads is not zero if nothing or zero > > is passed, and another one that checks that the value passed is taken > > over. > > > > The test could parse the output of -XX:+PrintFlagsFinal. The test > > gc/arguments/TestObjectTenuringFlags.java shows how this is done. > > > > There is also some behavior that seems to be wrong: if you manually set > > the number of G1ConcRefinementThreads to zero (which means > > "automatically select"), -XX:+PrintFlagsFinal still prints > > "G1ConcRefinementThreads := 0". Imo even in this case the output should > > contain the actual number of threads used. > > > > At least if you set ConcGCThreads manually to 0, the flag is set to the > > actual value after argument processing. > > > > ParallelGCThreads also shows 0 here, but I think this part of bug > > JDK-6979279 and should be fixed there. > > > > Thanks, > > Thomas > > > > > From thomas.schatzl at oracle.com Fri Sep 26 09:46:42 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 26 Sep 2014 11:46:42 +0200 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <542442AE.4040701@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> <542442AE.4040701@oracle.com> Message-ID: <1411724802.2689.35.camel@cirrus> Hi Andrey, On Thu, 2014-09-25 at 20:28 +0400, Andrey Zakharov wrote: > BTW, tested in aurora with latest jdk 8 updates > 593423.ute.hs_jtreg.accept.full Some questions: - the different tests seem to be only different in the number of iterations the allocate/link/mutate/deallocate cycle runs. They all use the same G1ConcRSLogCacheSize, but vary object alignment. That seems okay, but why is there need to run for different amount of time, particularly so many? Earlier versions of the test varied G1ConcRSLogCacheSize and object alignment, and did only a single iteration always. Not sure if simply testing G1ConcRSLogCacheSize for a few important values (0, 10, 15, maybe not even the last because the only difference in code is for 0 and something) and a single fixed length (not necessarily a single iteration) would achieve the same job? G1ConcRSLogCacheSize of 10 does not require that much memory (and in fact is default) so that you need to worry about its maximum size. - fixing G1ConcRSLogCacheSize would also remove the need to calculate some maximum value for G1ConcRSLogCacheSize. GetMaxCacheSize() calculates the maximum G1ConcRSLogCacheSize based on the free java heap. However, the data structure is allocated on the C heap, there is no real connection between free java heap and free C heap anyway. Thanks, Thomas From andrey.x.zakharov at oracle.com Fri Sep 26 10:33:30 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Fri, 26 Sep 2014 14:33:30 +0400 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <1411724802.2689.35.camel@cirrus> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> <542442AE.4040701@oracle.com> <1411724802.2689.35.camel@cirrus> Message-ID: <542540FA.4030206@oracle.com> On 26.09.2014 13:46, Thomas Schatzl wrote: > Hi Andrey, > > On Thu, 2014-09-25 at 20:28 +0400, Andrey Zakharov wrote: >> BTW, tested in aurora with latest jdk 8 updates >> 593423.ute.hs_jtreg.accept.full > Some questions: > > - the different tests seem to be only different in the number of > iterations the allocate/link/mutate/deallocate cycle runs. They all use > the same G1ConcRSLogCacheSize, but vary object alignment. Different tests initiates Base class with different cache size number protected TestShrinkAuxiliaryData(int RSetCacheSize) { this.RSetCacheSize = RSetCacheSize; } which then goes to: vmOpts.add("-XX:G1ConcRSLogCacheSize=" + RSetCacheSize); So tests runs with different options G1ConcRSLogCacheSize and ObjectAlignmentInBytes for non-32 bits systems > > That seems okay, but why is there need to run for different amount of > time, particularly so many? it runs DEFAULT_ITERATION_COUNT=1 for now > > Earlier versions of the test varied G1ConcRSLogCacheSize and object > alignment, and did only a single iteration always. Not sure if simply > testing G1ConcRSLogCacheSize for a few important values (0, 10, 15, > maybe not even the last because the only difference in code is for 0 and > something) and a single fixed length (not necessarily a single > iteration) would achieve the same job? > > G1ConcRSLogCacheSize of 10 does not require that much memory (and in > fact is default) so that you need to worry about its maximum size. I'm worried about 2^23 - 2^30 caches size which can brings massive swapping and timeouts of tests > > - fixing G1ConcRSLogCacheSize would also remove the need to calculate > some maximum value for G1ConcRSLogCacheSize. GetMaxCacheSize() > calculates the maximum G1ConcRSLogCacheSize based on the free java heap. > However, the data structure is allocated on the C heap, there is no real > connection between free java heap and free C heap anyway. Could please, suggest something here? I'm just judging about available memory by available heap memory. Thanks. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Fri Sep 26 10:47:36 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 26 Sep 2014 12:47:36 +0200 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <542540FA.4030206@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> <542442AE.4040701@oracle.com> <1411724802.2689.35.camel@cirrus> <542540FA.4030206@oracle.com> Message-ID: <1411728456.2689.48.camel@cirrus> Hi, On Fri, 2014-09-26 at 14:33 +0400, Andrey Zakharov wrote: > On 26.09.2014 13:46, Thomas Schatzl wrote: > > Hi Andrey, > > > > On Thu, 2014-09-25 at 20:28 +0400, Andrey Zakharov wrote: > >> BTW, tested in aurora with latest jdk 8 updates > >> 593423.ute.hs_jtreg.accept.full > > Some questions: > > > > - the different tests seem to be only different in the number of > > iterations the allocate/link/mutate/deallocate cycle runs. They all use > > the same G1ConcRSLogCacheSize, but vary object alignment. > Different tests initiates Base class with different cache size number > protected TestShrinkAuxiliaryData(int RSetCacheSize) { > this.RSetCacheSize = RSetCacheSize; > } > > which then goes to: > vmOpts.add("-XX:G1ConcRSLogCacheSize=" + RSetCacheSize); > > So tests runs with different options G1ConcRSLogCacheSize and > ObjectAlignmentInBytes for non-32 bits systems Okay, I got it now how the tests work. Thanks. > > G1ConcRSLogCacheSize of 10 does not require that much memory (and in > > fact is default) so that you need to worry about its maximum size. > I'm worried about 2^23 - 2^30 caches size which can brings massive > swapping and timeouts of tests Then I suggest just removing the ...Data25/Data30, even ...Data20, tests. There is not much difference in behavior from a GC point of view between these heap sizes. The values are simply used to size that data structure. > > - fixing G1ConcRSLogCacheSize would also remove the need to calculate > > some maximum value for G1ConcRSLogCacheSize. GetMaxCacheSize() > > calculates the maximum G1ConcRSLogCacheSize based on the free java heap. > > However, the data structure is allocated on the C heap, there is no real > > connection between free java heap and free C heap anyway. > Could please, suggest something here? > I'm just judging about available memory by available heap memory. > Thanks. Available Java heap memory (Runtime.freeMemory() returns the available memory on the Java heap), not available C heap memory. One has no direct connection to the other. By simply removing the tests with the large G1ConcRSLogCacheSize values, which imo do not add a lot, you do not need such a contrived check. Thanks, Thomas From bengt.rutisson at oracle.com Fri Sep 26 10:49:17 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 26 Sep 2014 12:49:17 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <54218EAE.3070002@oracle.com> References: <54218EAE.3070002@oracle.com> Message-ID: <542544AD.5050504@oracle.com> Hi Erik, The change looks good. One minor thing is that Metaspace::expand_and_allocate() and Metaspace::allocate() have different exposure even though they are both supposed to be internal to Metaspace. It would be nice to treat them the same way. Talked to Erik and we think that keeping the friend declaration of CollectorPolicy makes sense and in that case we can move expand_and_allocate() from being public to being private. Thanks, Bengt On 2014-09-23 17:15, Erik Helin wrote: > Hi all, > > this small change enables us to skip two possible safepoints in > CollectorPolicy::satisfy_failed_metadata_allocation: > > 1. When a thread continues a loop after having been stalled due to a > GC_locker initiated Full GC. > 2. When the VM_CollectForMetadata VM operation's prologue fails > because a full GC has already been run just prior to the > CollectForMetadata VM operation. > > The way this is done is simply by trying to allocate at the start of > the loop. This way, whenever we loop around and a full GC has > happened, the allocation request might be satisfied and we can do an > early return. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8058963 > > Testing: > - JPRT > - Aurora: > - Kitchensink > - Weblogic+Medrec > - runThese > - vm.quick, regression, gc, compiler, runtime, parallel class loading, > metaspace, oom > - JTReg tests > > Thanks, > Erik From andrey.x.zakharov at oracle.com Fri Sep 26 11:01:15 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Fri, 26 Sep 2014 15:01:15 +0400 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <1411728456.2689.48.camel@cirrus> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> <542442AE.4040701@oracle.com> <1411724802.2689.35.camel@cirrus> <542540FA.4030206@oracle.com> <1411728456.2689.48.camel@cirrus> Message-ID: <5425477B.3000005@oracle.com> On 26.09.2014 14:47, Thomas Schatzl wrote: > G1ConcRSLogCacheSize of 10 does not require that much memory (and in > fact is default) so that you need to worry about its maximum size. >> I'm worried about 2^23 - 2^30 caches size which can brings massive >> swapping and timeouts of tests > Then I suggest just removing the ...Data25/Data30, even ...Data20, > tests. There is not much difference in behavior from a GC point of view > between these heap sizes. The values are simply used to size that data > structure. >>> - fixing G1ConcRSLogCacheSize would also remove the need to calculate >>> some maximum value for G1ConcRSLogCacheSize. GetMaxCacheSize() >>> calculates the maximum G1ConcRSLogCacheSize based on the free java heap. >>> However, the data structure is allocated on the C heap, there is no real >>> connection between free java heap and free C heap anyway. >> Could please, suggest something here? >> I'm just judging about available memory by available heap memory. >> Thanks. > Available Java heap memory (Runtime.freeMemory() returns the available > memory on the Java heap), not available C heap memory. One has no direct > connection to the other. > > By simply removing the tests with the large G1ConcRSLogCacheSize values, > which imo do not add a lot, you do not need such a contrived check. As we have this feature in product - there needs to be tested. > Thanks, > Thomas > > From thomas.schatzl at oracle.com Fri Sep 26 11:15:23 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 26 Sep 2014 13:15:23 +0200 Subject: [RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures In-Reply-To: <5425477B.3000005@oracle.com> References: <541C43AC.8070607@oracle.com> <5421CCDB.1080103@oracle.com> <54227CAB.6000703@oracle.com> <5422FEAA.1070806@oracle.com> <542442AE.4040701@oracle.com> <1411724802.2689.35.camel@cirrus> <542540FA.4030206@oracle.com> <1411728456.2689.48.camel@cirrus> <5425477B.3000005@oracle.com> Message-ID: <1411730123.2689.59.camel@cirrus> Hi, On Fri, 2014-09-26 at 15:01 +0400, Andrey Zakharov wrote: > On 26.09.2014 14:47, Thomas Schatzl wrote: > > G1ConcRSLogCacheSize of 10 does not require that much memory (and in > > fact is default) so that you need to worry about its maximum size. > >> I'm worried about 2^23 - 2^30 caches size which can brings massive > >> swapping and timeouts of tests > > Then I suggest just removing the ...Data25/Data30, even ...Data20, > > tests. There is not much difference in behavior from a GC point of view > > between these heap sizes. The values are simply used to size that data > > structure. > >>> - fixing G1ConcRSLogCacheSize would also remove the need to calculate > >>> some maximum value for G1ConcRSLogCacheSize. GetMaxCacheSize() > >>> calculates the maximum G1ConcRSLogCacheSize based on the free java heap. > >>> However, the data structure is allocated on the C heap, there is no real > >>> connection between free java heap and free C heap anyway. > >> Could please, suggest something here? > >> I'm just judging about available memory by available heap memory. > >> Thanks. > > Available Java heap memory (Runtime.freeMemory() returns the available > > memory on the Java heap), not available C heap memory. One has no direct > > connection to the other. > > > > By simply removing the tests with the large G1ConcRSLogCacheSize values, > > which imo do not add a lot, you do not need such a contrived check. > As we have this feature in product - there needs to be tested. :) Well, I would prefer to do the test whether G1 supports higher G1ConcRSLogCacheSize values in a different test/CR, but feel free to keep it. Reviewed. Thanks, Thomas From jesper.wilhelmsson at oracle.com Fri Sep 26 11:39:45 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 26 Sep 2014 13:39:45 +0200 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <1411720848.2689.5.camel@cirrus> References: <5422E88B.60408@oracle.com> <1411630353.2707.9.camel@cirrus> <1411635669.2707.18.camel@cirrus> <54251E18.1020006@oracle.com> <1411720848.2689.5.camel@cirrus> Message-ID: <54255081.6020007@oracle.com> Thomas Schatzl skrev 26/9/14 10:40: > Hi Sangheon, > > On Fri, 2014-09-26 at 10:04 +0200, Bengt Rutisson wrote: >> Hi all, >> >> Here's an updated webrev from Sangheon: >> >> http://cr.openjdk.java.net/~brutisso/8047976/webrev.02/ >> >> From Sangheon: >> >> "This includes Thomas's comments about: >> 1) Moving value set to Arguments::set_g1_gc_flags() >> 2) Adding jtreg test for G1ConcRefinementThreads variable" > > The changes in the Hotspot code look okay to me. Thanks! > > Some comments about the test case code: > > - There is a typo in AUTO_SELCT_THREADS_COUNT, should be > AUTO_SELECT_THREADS_COUNT I think. > - There is no need to have @build and @run lines if you do not use > special options to invoke the test afaik. Once this is fixed I'm fine with this change. If you send an "hg export" of the change I'll push it. /Jesper > > Otherwise looks okay. > > Thanks, > Thomas > > >> >> Thanks, >> Bengt >> >> >> On 2014-09-25 11:01, Thomas Schatzl wrote: >>> Hi, >>> >>> On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: >>>>> Hi all, >>>>> >>>>> can I have reviews for the following small change to update >>>>> G1ConcRefinementThreads variable? >>>>> And also I need a sponsor for this. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8047976 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ >>>>> >>>> Please update the flag during argument processing, not every time the >>>> method is called. >>>> >>>> Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think. >>>> >>> Please also add a jtreg test case. At least one test case that verifies >>> that with G1 the G1ConcRefinementThreads is not zero if nothing or zero >>> is passed, and another one that checks that the value passed is taken >>> over. >>> >>> The test could parse the output of -XX:+PrintFlagsFinal. The test >>> gc/arguments/TestObjectTenuringFlags.java shows how this is done. >>> >>> There is also some behavior that seems to be wrong: if you manually set >>> the number of G1ConcRefinementThreads to zero (which means >>> "automatically select"), -XX:+PrintFlagsFinal still prints >>> "G1ConcRefinementThreads := 0". Imo even in this case the output should >>> contain the actual number of threads used. >>> >>> At least if you set ConcGCThreads manually to 0, the flag is set to the >>> actual value after argument processing. >>> >>> ParallelGCThreads also shows 0 here, but I think this part of bug >>> JDK-6979279 and should be fixed there. >>> >>> Thanks, >>> Thomas >>> >>> >> > > From erik.helin at oracle.com Fri Sep 26 14:45:20 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 26 Sep 2014 16:45:20 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <542544AD.5050504@oracle.com> References: <54218EAE.3070002@oracle.com> <542544AD.5050504@oracle.com> Message-ID: <54257C00.5070201@oracle.com> Hi Bengt, On 2014-09-26 12:49, Bengt Rutisson wrote: > > Hi Erik, > > The change looks good. thanks! On 2014-09-26 12:49, Bengt Rutisson wrote: > One minor thing is that Metaspace::expand_and_allocate() and > Metaspace::allocate() have different exposure even though they are both > supposed to be internal to Metaspace. It would be nice to treat them the > same way. Talked to Erik and we think that keeping the friend > declaration of CollectorPolicy makes sense and in that case we can move > expand_and_allocate() from being public to being private. Good idea, I've uploaded new webrevs: - full: http://cr.openjdk.java.net/~ehelin/8058963/webrev.01/ - inc: http://cr.openjdk.java.net/~ehelin/8058963/webrev.00-01/ Thanks, Erik > Thanks, > Bengt > > > On 2014-09-23 17:15, Erik Helin wrote: >> Hi all, >> >> this small change enables us to skip two possible safepoints in >> CollectorPolicy::satisfy_failed_metadata_allocation: >> >> 1. When a thread continues a loop after having been stalled due to a >> GC_locker initiated Full GC. >> 2. When the VM_CollectForMetadata VM operation's prologue fails >> because a full GC has already been run just prior to the >> CollectForMetadata VM operation. >> >> The way this is done is simply by trying to allocate at the start of >> the loop. This way, whenever we loop around and a full GC has >> happened, the allocation request might be satisfied and we can do an >> early return. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8058963 >> >> Testing: >> - JPRT >> - Aurora: >> - Kitchensink >> - Weblogic+Medrec >> - runThese >> - vm.quick, regression, gc, compiler, runtime, parallel class loading, >> metaspace, oom >> - JTReg tests >> >> Thanks, >> Erik > From erik.helin at oracle.com Fri Sep 26 14:45:40 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 26 Sep 2014 16:45:40 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <2165163.QVx9T10jn1@mgerdin03> References: <54218EAE.3070002@oracle.com> <2165163.QVx9T10jn1@mgerdin03> Message-ID: <54257C14.7050002@oracle.com> Hi Mikael, On 2014-09-26 10:06, Mikael Gerdin wrote: > Hi Erik, > > On Tuesday 23 September 2014 17.15.58 Erik Helin wrote: >> Hi all, >> >> this small change enables us to skip two possible safepoints in >> CollectorPolicy::satisfy_failed_metadata_allocation: >> >> 1. When a thread continues a loop after having been stalled due to a >> GC_locker initiated Full GC. >> 2. When the VM_CollectForMetadata VM operation's prologue fails because >> a full GC has already been run just prior to the CollectForMetadata VM >> operation. >> >> The way this is done is simply by trying to allocate at the start of the >> loop. This way, whenever we loop around and a full GC has happened, the >> allocation request might be satisfied and we can do an early return. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ > > Change looks good. Thanks! Erik > /Mikael > >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8058963 >> >> Testing: >> - JPRT >> - Aurora: >> - Kitchensink >> - Weblogic+Medrec >> - runThese >> - vm.quick, regression, gc, compiler, runtime, parallel class loading, >> metaspace, oom >> - JTReg tests >> >> Thanks, >> Erik > From sangheon.kim at oracle.com Fri Sep 26 15:35:02 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 26 Sep 2014 08:35:02 -0700 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <1411720848.2689.5.camel@cirrus> References: <5422E88B.60408@oracle.com> <1411630353.2707.9.camel@cirrus> <1411635669.2707.18.camel@cirrus> <54251E18.1020006@oracle.com> <1411720848.2689.5.camel@cirrus> Message-ID: <542587A6.3060900@oracle.com> Hi Thomas, Thank you for reviewing this. As there's no special option for @build/@run lines, I will remove them. And fix the typo. Bengt, thanks for uploading this fix too. Thanks, Sangheon Thanks for the review and On 09/26/2014 01:40 AM, Thomas Schatzl wrote: > Hi Sangheon, > > On Fri, 2014-09-26 at 10:04 +0200, Bengt Rutisson wrote: >> Hi all, >> >> Here's an updated webrev from Sangheon: >> >> http://cr.openjdk.java.net/~brutisso/8047976/webrev.02/ >> >> From Sangheon: >> >> "This includes Thomas's comments about: >> 1) Moving value set to Arguments::set_g1_gc_flags() >> 2) Adding jtreg test for G1ConcRefinementThreads variable" > The changes in the Hotspot code look okay to me. Thanks! > > Some comments about the test case code: > > - There is a typo in AUTO_SELCT_THREADS_COUNT, should be > AUTO_SELECT_THREADS_COUNT I think. > - There is no need to have @build and @run lines if you do not use > special options to invoke the test afaik. > > Otherwise looks okay. > > Thanks, > Thomas > > >> Thanks, >> Bengt >> >> >> On 2014-09-25 11:01, Thomas Schatzl wrote: >>> Hi, >>> >>> On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: >>>>> Hi all, >>>>> >>>>> can I have reviews for the following small change to update >>>>> G1ConcRefinementThreads variable? >>>>> And also I need a sponsor for this. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8047976 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ >>>>> >>>> Please update the flag during argument processing, not every time the >>>> method is called. >>>> >>>> Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think. >>>> >>> Please also add a jtreg test case. At least one test case that verifies >>> that with G1 the G1ConcRefinementThreads is not zero if nothing or zero >>> is passed, and another one that checks that the value passed is taken >>> over. >>> >>> The test could parse the output of -XX:+PrintFlagsFinal. The test >>> gc/arguments/TestObjectTenuringFlags.java shows how this is done. >>> >>> There is also some behavior that seems to be wrong: if you manually set >>> the number of G1ConcRefinementThreads to zero (which means >>> "automatically select"), -XX:+PrintFlagsFinal still prints >>> "G1ConcRefinementThreads := 0". Imo even in this case the output should >>> contain the actual number of threads used. >>> >>> At least if you set ConcGCThreads manually to 0, the flag is set to the >>> actual value after argument processing. >>> >>> ParallelGCThreads also shows 0 here, but I think this part of bug >>> JDK-6979279 and should be fixed there. >>> >>> Thanks, >>> Thomas >>> >>> > From sangheon.kim at oracle.com Fri Sep 26 15:36:26 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 26 Sep 2014 08:36:26 -0700 Subject: RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags In-Reply-To: <54255081.6020007@oracle.com> References: <5422E88B.60408@oracle.com> <1411630353.2707.9.camel@cirrus> <1411635669.2707.18.camel@cirrus> <54251E18.1020006@oracle.com> <1411720848.2689.5.camel@cirrus> <54255081.6020007@oracle.com> Message-ID: <542587FA.9010303@oracle.com> Hi Jesper, Thank you for sponsoring this change. I will send you once the fix is ready on other email. Thanks, Sangheon On 09/26/2014 04:39 AM, Jesper Wilhelmsson wrote: > Thomas Schatzl skrev 26/9/14 10:40: >> Hi Sangheon, >> >> On Fri, 2014-09-26 at 10:04 +0200, Bengt Rutisson wrote: >>> Hi all, >>> >>> Here's an updated webrev from Sangheon: >>> >>> http://cr.openjdk.java.net/~brutisso/8047976/webrev.02/ >>> >>> From Sangheon: >>> >>> "This includes Thomas's comments about: >>> 1) Moving value set to Arguments::set_g1_gc_flags() >>> 2) Adding jtreg test for G1ConcRefinementThreads variable" >> >> The changes in the Hotspot code look okay to me. Thanks! >> >> Some comments about the test case code: >> >> - There is a typo in AUTO_SELCT_THREADS_COUNT, should be >> AUTO_SELECT_THREADS_COUNT I think. >> - There is no need to have @build and @run lines if you do not use >> special options to invoke the test afaik. > > Once this is fixed I'm fine with this change. > If you send an "hg export" of the change I'll push it. > /Jesper > >> >> Otherwise looks okay. >> >> Thanks, >> Thomas >> >> >>> >>> Thanks, >>> Bengt >>> >>> >>> On 2014-09-25 11:01, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote: >>>>> Hi, >>>>> >>>>> On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote: >>>>>> Hi all, >>>>>> >>>>>> can I have reviews for the following small change to update >>>>>> G1ConcRefinementThreads variable? >>>>>> And also I need a sponsor for this. >>>>>> >>>>>> CR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8047976 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ >>>>>> >>>>> Please update the flag during argument processing, not every time the >>>>> method is called. >>>>> >>>>> Somewhere in Arguments::set_g1_gc_flags() would be appropriate I >>>>> think. >>>>> >>>> Please also add a jtreg test case. At least one test case that >>>> verifies >>>> that with G1 the G1ConcRefinementThreads is not zero if nothing or >>>> zero >>>> is passed, and another one that checks that the value passed is taken >>>> over. >>>> >>>> The test could parse the output of -XX:+PrintFlagsFinal. The test >>>> gc/arguments/TestObjectTenuringFlags.java shows how this is done. >>>> >>>> There is also some behavior that seems to be wrong: if you manually >>>> set >>>> the number of G1ConcRefinementThreads to zero (which means >>>> "automatically select"), -XX:+PrintFlagsFinal still prints >>>> "G1ConcRefinementThreads := 0". Imo even in this case the output >>>> should >>>> contain the actual number of threads used. >>>> >>>> At least if you set ConcGCThreads manually to 0, the flag is set to >>>> the >>>> actual value after argument processing. >>>> >>>> ParallelGCThreads also shows 0 here, but I think this part of bug >>>> JDK-6979279 and should be fixed there. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> >> From bengt.rutisson at oracle.com Mon Sep 29 08:14:33 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 29 Sep 2014 10:14:33 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <54257C00.5070201@oracle.com> References: <54218EAE.3070002@oracle.com> <542544AD.5050504@oracle.com> <54257C00.5070201@oracle.com> Message-ID: <542914E9.8090707@oracle.com> On 2014-09-26 16:45, Erik Helin wrote: > Hi Bengt, > > On 2014-09-26 12:49, Bengt Rutisson wrote: >> >> Hi Erik, >> >> The change looks good. > > thanks! > > On 2014-09-26 12:49, Bengt Rutisson wrote: >> One minor thing is that Metaspace::expand_and_allocate() and >> Metaspace::allocate() have different exposure even though they are both >> supposed to be internal to Metaspace. It would be nice to treat them the >> same way. Talked to Erik and we think that keeping the friend >> declaration of CollectorPolicy makes sense and in that case we can move >> expand_and_allocate() from being public to being private. > > Good idea, I've uploaded new webrevs: > - full: http://cr.openjdk.java.net/~ehelin/8058963/webrev.01/ > - inc: http://cr.openjdk.java.net/~ehelin/8058963/webrev.00-01/ Looks good. Bengt > > Thanks, > Erik > >> Thanks, >> Bengt >> >> >> On 2014-09-23 17:15, Erik Helin wrote: >>> Hi all, >>> >>> this small change enables us to skip two possible safepoints in >>> CollectorPolicy::satisfy_failed_metadata_allocation: >>> >>> 1. When a thread continues a loop after having been stalled due to a >>> GC_locker initiated Full GC. >>> 2. When the VM_CollectForMetadata VM operation's prologue fails >>> because a full GC has already been run just prior to the >>> CollectForMetadata VM operation. >>> >>> The way this is done is simply by trying to allocate at the start of >>> the loop. This way, whenever we loop around and a full GC has >>> happened, the allocation request might be satisfied and we can do an >>> early return. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8058963 >>> >>> Testing: >>> - JPRT >>> - Aurora: >>> - Kitchensink >>> - Weblogic+Medrec >>> - runThese >>> - vm.quick, regression, gc, compiler, runtime, parallel class >>> loading, >>> metaspace, oom >>> - JTReg tests >>> >>> Thanks, >>> Erik >> From erik.helin at oracle.com Mon Sep 29 08:23:42 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 29 Sep 2014 10:23:42 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <542914E9.8090707@oracle.com> References: <54218EAE.3070002@oracle.com> <542544AD.5050504@oracle.com> <54257C00.5070201@oracle.com> <542914E9.8090707@oracle.com> Message-ID: <5429170E.8060408@oracle.com> On 2014-09-29 10:14, Bengt Rutisson wrote: > > On 2014-09-26 16:45, Erik Helin wrote: >> Hi Bengt, >> >> On 2014-09-26 12:49, Bengt Rutisson wrote: >>> >>> Hi Erik, >>> >>> The change looks good. >> >> thanks! >> >> On 2014-09-26 12:49, Bengt Rutisson wrote: >>> One minor thing is that Metaspace::expand_and_allocate() and >>> Metaspace::allocate() have different exposure even though they are both >>> supposed to be internal to Metaspace. It would be nice to treat them the >>> same way. Talked to Erik and we think that keeping the friend >>> declaration of CollectorPolicy makes sense and in that case we can move >>> expand_and_allocate() from being public to being private. >> >> Good idea, I've uploaded new webrevs: >> - full: http://cr.openjdk.java.net/~ehelin/8058963/webrev.01/ >> - inc: http://cr.openjdk.java.net/~ehelin/8058963/webrev.00-01/ > > Looks good. Thanks! Erik > Bengt > > > >> >> Thanks, >> Erik >> >>> Thanks, >>> Bengt >>> >>> >>> On 2014-09-23 17:15, Erik Helin wrote: >>>> Hi all, >>>> >>>> this small change enables us to skip two possible safepoints in >>>> CollectorPolicy::satisfy_failed_metadata_allocation: >>>> >>>> 1. When a thread continues a loop after having been stalled due to a >>>> GC_locker initiated Full GC. >>>> 2. When the VM_CollectForMetadata VM operation's prologue fails >>>> because a full GC has already been run just prior to the >>>> CollectForMetadata VM operation. >>>> >>>> The way this is done is simply by trying to allocate at the start of >>>> the loop. This way, whenever we loop around and a full GC has >>>> happened, the allocation request might be satisfied and we can do an >>>> early return. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8058963 >>>> >>>> Testing: >>>> - JPRT >>>> - Aurora: >>>> - Kitchensink >>>> - Weblogic+Medrec >>>> - runThese >>>> - vm.quick, regression, gc, compiler, runtime, parallel class >>>> loading, >>>> metaspace, oom >>>> - JTReg tests >>>> >>>> Thanks, >>>> Erik >>> > From mikael.gerdin at oracle.com Mon Sep 29 08:45:32 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 29 Sep 2014 10:45:32 +0200 Subject: RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints In-Reply-To: <542914E9.8090707@oracle.com> References: <54218EAE.3070002@oracle.com> <54257C00.5070201@oracle.com> <542914E9.8090707@oracle.com> Message-ID: <3020252.m64q3TPB8L@mgerdin03> On Monday 29 September 2014 10.14.33 Bengt Rutisson wrote: > On 2014-09-26 16:45, Erik Helin wrote: > > Hi Bengt, > > > > On 2014-09-26 12:49, Bengt Rutisson wrote: > >> Hi Erik, > >> > >> The change looks good. > > > > thanks! > > > > On 2014-09-26 12:49, Bengt Rutisson wrote: > >> One minor thing is that Metaspace::expand_and_allocate() and > >> Metaspace::allocate() have different exposure even though they are both > >> supposed to be internal to Metaspace. It would be nice to treat them the > >> same way. Talked to Erik and we think that keeping the friend > >> declaration of CollectorPolicy makes sense and in that case we can move > >> expand_and_allocate() from being public to being private. > > > > Good idea, I've uploaded new webrevs: > > - full: http://cr.openjdk.java.net/~ehelin/8058963/webrev.01/ > > - inc: http://cr.openjdk.java.net/~ehelin/8058963/webrev.00-01/ > > Looks good. +1 /Mikael > > Bengt > > > Thanks, > > Erik > > > >> Thanks, > >> Bengt > >> > >> On 2014-09-23 17:15, Erik Helin wrote: > >>> Hi all, > >>> > >>> this small change enables us to skip two possible safepoints in > >>> CollectorPolicy::satisfy_failed_metadata_allocation: > >>> > >>> 1. When a thread continues a loop after having been stalled due to a > >>> GC_locker initiated Full GC. > >>> 2. When the VM_CollectForMetadata VM operation's prologue fails > >>> because a full GC has already been run just prior to the > >>> CollectForMetadata VM operation. > >>> > >>> The way this is done is simply by trying to allocate at the start of > >>> the loop. This way, whenever we loop around and a full GC has > >>> happened, the allocation request might be satisfied and we can do an > >>> early return. > >>> > >>> Webrev: > >>> http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/ > >>> > >>> Bug: > >>> https://bugs.openjdk.java.net/browse/JDK-8058963 > >>> > >>> Testing: > >>> - JPRT > >>> > >>> - Aurora: > >>> - Kitchensink > >>> - Weblogic+Medrec > >>> - runThese > >>> - vm.quick, regression, gc, compiler, runtime, parallel class > >>> > >>> loading, > >>> > >>> metaspace, oom > >>> > >>> - JTReg tests > >>> > >>> Thanks, > >>> Erik From thomas.schatzl at oracle.com Mon Sep 29 08:49:13 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 29 Sep 2014 10:49:13 +0200 Subject: RFR (XS): 8u40 Backport of 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set Message-ID: <1411980553.2945.12.camel@cirrus> Hi all, can I have reviews for a merge error to backport 8052172 to 8u40? In particular, this hunk from g1ParScanThreadState.hpp: @@ -124,8 +110,17 @@ _refs->push(ref); } - template inline void update_rs(HeapRegion* from, T* p, int tid); - + template void update_rs(HeapRegion* from, T* p, int tid) { + // If the new value of the field points to the same region or + // is the to-space, we don't need to include it in the Rset updates. + if (!from->is_in_reserved(oopDesc::load_decode_heap_oop(p)) && !from->is_survivor()) { + size_t card_index = ctbs()->index_for(p); + // If the card hasn't been added to the buffer, do it. + if (ctbs()->mark_card_deferred(card_index)) { + dirty_card_queue().enqueue((jbyte*)ctbs()->byte_for_index(card_index)); + } + } + } private: inline HeapWord* allocate(GCAllocPurpose purpose, size_t word_sz); did not apply cleanly any more because later changes removed the allocation methods. The remainder of the change applied cleanly. CR: https://bugs.openjdk.java.net/browse/JDK-8052172 Original Webrev: http://cr.openjdk.java.net/~tschatzl/8052172/webrev/ 8u40 Webrev: http://cr.openjdk.java.net/~tschatzl/8052172/webrev.8u40/ Thanks, Thomas From bengt.rutisson at oracle.com Mon Sep 29 09:02:32 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 29 Sep 2014 11:02:32 +0200 Subject: RFR (XS): 8u40 Backport of 8052172: Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set In-Reply-To: <1411980553.2945.12.camel@cirrus> References: <1411980553.2945.12.camel@cirrus> Message-ID: <54292028.8060305@oracle.com> Hi Thomas, On 2014-09-29 10:49, Thomas Schatzl wrote: > Hi all, > > can I have reviews for a merge error to backport 8052172 to 8u40? > > In particular, this hunk from g1ParScanThreadState.hpp: > > @@ -124,8 +110,17 @@ > _refs->push(ref); > } > > - template inline void update_rs(HeapRegion* from, T* p, int tid); > - > + template void update_rs(HeapRegion* from, T* p, int tid) { > + // If the new value of the field points to the same region or > + // is the to-space, we don't need to include it in the Rset updates. > + if (!from->is_in_reserved(oopDesc::load_decode_heap_oop(p)) && !from->is_survivor()) { > + size_t card_index = ctbs()->index_for(p); > + // If the card hasn't been added to the buffer, do it. > + if (ctbs()->mark_card_deferred(card_index)) { > + dirty_card_queue().enqueue((jbyte*)ctbs()->byte_for_index(card_index)); > + } > + } > + } > private: > > inline HeapWord* allocate(GCAllocPurpose purpose, size_t word_sz); > > did not apply cleanly any more because later changes removed the > allocation methods. > > The remainder of the change applied cleanly. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8052172 > Original Webrev: > http://cr.openjdk.java.net/~tschatzl/8052172/webrev/ > 8u40 Webrev: > http://cr.openjdk.java.net/~tschatzl/8052172/webrev.8u40/ I only looked at the merge in g1ParScanThreadState.hpp. I assume everything else is fine since it applied cleanly. g1ParScanThreadState.hpp looks good. Ship it! Bengt > > Thanks, > Thomas > From sangheon.kim at oracle.com Mon Sep 29 23:30:32 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Mon, 29 Sep 2014 16:30:32 -0700 Subject: RFR (S): JDK-8027428: Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 Message-ID: <5429EB98.6070602@oracle.com> Hi all, can I have reviews for the following small change to print taskqueue statistics for parallel gc, parNew and G1? Main changes are: 1) printing by 'ParallelGCVerbose' flag, not 'PrintGCDetails && ParallelGCVerbose'. 2) printing logs via 'gclog_or_tty', not 'tty'. 3) adding 'totals' row to sums up. CR: https://bugs.openjdk.java.net/browse/JDK-8027428 Webrev: http://cr.openjdk.java.net/~jwilhelm/8027428/ Testing: jprt Thanks, Sangheon From bengt.rutisson at oracle.com Tue Sep 30 08:02:28 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 30 Sep 2014 10:02:28 +0200 Subject: RFR (XXS): JDK-8059452: G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent Message-ID: <542A6394.6050408@oracle.com> Hi everyone, Can I have a couple of reviews for this small change to update two default values: http://cr.openjdk.java.net/~brutisso/8059452/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059452 From the bug report: When the flags G1HeapWastePercent and G1MixedGCLiveThresholdPercent were introduced their default values were picked without much performance analysis. Recent performance runs indicate that G1HeapWastePercent often benefit from a lower value and that G1MixedGCLiveThresholdPercent benefit from a higher value. Suggestion is to change the default for G1HeapWastePercent to 5 (used to be 10) adn G1MixedGCLiveThresholdPercent to 85 (used to be 65). Thanks, Bengt From bengt.rutisson at oracle.com Tue Sep 30 08:36:44 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 30 Sep 2014 10:36:44 +0200 Subject: RFR (S): JDK-8027428: Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 In-Reply-To: <5429EB98.6070602@oracle.com> References: <5429EB98.6070602@oracle.com> Message-ID: <542A6B9C.9030800@oracle.com> Hi Sangheon, On 2014-09-30 01:30, Sangheon Kim wrote: > Hi all, > > can I have reviews for the following small change to print taskqueue > statistics > for parallel gc, parNew and G1? > Main changes are: > 1) printing by 'ParallelGCVerbose' flag, not 'PrintGCDetails && > ParallelGCVerbose'. > 2) printing logs via 'gclog_or_tty', not 'tty'. > 3) adding 'totals' row to sums up. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8027428 > > Webrev: > http://cr.openjdk.java.net/~jwilhelm/8027428/ Thanks for fixing this. Could you provide some examples of what the output looks like for the different GCs now? It would make it easier to review this if I had examples of the output for ParNew, ParallelGC and G1. I'm also wondering if we can have an even more descriptive declaration of ParallelGCVerbose in globals.hpp. With your change it says: 1532 product(bool, ParallelGCVerbose, false, \ 1533 "Print verbose collection statistics output for parallel" \ 1534 "collectors") \ But there is a lot of logging that has to do with parallel work (at least in G1) that is not controlled by this flag. It seems to me that the flag actually only controls the task queue statistics. Ideally we could change the name of the flag, but that will be too much overhead I guess. But we can maybe updated the description to indicate more what it actually controls. Thanks, Bengt > > Testing: jprt > > Thanks, > Sangheon From marcus.larsson at oracle.com Tue Sep 30 09:43:08 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 30 Sep 2014 11:43:08 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over In-Reply-To: <1411643294.2707.24.camel@cirrus> References: <5412E184.70700@oracle.com> <1410872796.2755.45.camel@cirrus> <541C0FED.90200@oracle.com> <1411643294.2707.24.camel@cirrus> Message-ID: <542A7B2C.8030408@oracle.com> Hi Thomas, On 09/25/2014 01:08 PM, Thomas Schatzl wrote: > Hi Marcus, > > On Fri, 2014-09-19 at 13:13 +0200, Marcus Larsson wrote: >> Hi Thomas, thanks for reviewing! >> > [...] >> New webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8058298v2/ >> >> Changes from previous webrev: >> http://cr.openjdk.java.net/~brutisso/webrev-8058298v1-v2/ >> > thanks for the changes, look good. > > One final request :) Is it possible to make the HRClaimer of > G1ParRemoveSelfForwardPtrsTask a member of the task like it is done for > all the other tasks? Then we would also get rid of the parameterless > constructor for HeapRegionClaimer. I can do that. This alone will however not allow us to get rid of the parameterless constructor unfortunately. Some tasks still conditionally use the HRClaimer (G1ParVerifyFinalCountTask, G1ParFinalCountTask for example), initializing the HRClaimer in the task constructor only if use_parallel_gc_threads() is true. > I saw that you are also working on "JDK-6979279: remove special-case > code for ParallelGCThreads==0". With that change, > G1CollectedHeap::use_parallel_gc_threads() would be always true, > allowing to make HeapRegionClaimer::initialize() private. Yes, together with that change it would be possible to remove the empty constructor and just keep the initialization code in the other constructor, removing the need for the initialize function completely. I'm however thinking the above patch could include those changes to the HRClaimer, since it is only possible after making those changes anyway. For now, I moved the claimer to the task as you requested. New webrev: http://cr.openjdk.java.net/~mlarsson/8058298/webrev.02/ Incremental webrev: http://cr.openjdk.java.net/~mlarsson/8058298/webrev.01-02/ Thanks, Marcus > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Sep 30 09:55:27 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Sep 2014 11:55:27 +0200 Subject: RFR: 8058298: Separate heap region iterator claim values from the data structures iterated over In-Reply-To: <542A7B2C.8030408@oracle.com> References: <5412E184.70700@oracle.com> <1410872796.2755.45.camel@cirrus> <541C0FED.90200@oracle.com> <1411643294.2707.24.camel@cirrus> <542A7B2C.8030408@oracle.com> Message-ID: <1412070927.2791.10.camel@cirrus> Hi Marcus, On Tue, 2014-09-30 at 11:43 +0200, Marcus Larsson wrote: > Hi Thomas, > > > On 09/25/2014 01:08 PM, Thomas Schatzl wrote: > > Hi Marcus, > > > > On Fri, 2014-09-19 at 13:13 +0200, Marcus Larsson wrote: > >> Hi Thomas, thanks for reviewing! > >> > > [...] > >> New webrev: > >> http://cr.openjdk.java.net/~brutisso/webrev-8058298v2/ > >> > >> Changes from previous webrev: > >> http://cr.openjdk.java.net/~brutisso/webrev-8058298v1-v2/ > >> > > thanks for the changes, look good. > > > > One final request :) Is it possible to make the HRClaimer of > > G1ParRemoveSelfForwardPtrsTask a member of the task like it is done for > > all the other tasks? Then we would also get rid of the parameterless > > constructor for HeapRegionClaimer. > > I can do that. This alone will however not allow us to get rid of the > parameterless constructor unfortunately. > Some tasks still conditionally use the HRClaimer > (G1ParVerifyFinalCountTask, G1ParFinalCountTask for example), > initializing the HRClaimer in the task constructor only if > use_parallel_gc_threads() is true. > > > I saw that you are also working on "JDK-6979279: remove special-case > > code for ParallelGCThreads==0". With that change, > > G1CollectedHeap::use_parallel_gc_threads() would be always true, > > allowing to make HeapRegionClaimer::initialize() private. > > Yes, together with that change it would be possible to remove the empty > constructor and just keep > the initialization code in the other constructor, removing the need for > the initialize function completely. > I'm however thinking the above patch could include those changes to the > HRClaimer, since it is only possible > after making those changes anyway. > > For now, I moved the claimer to the task as you requested. > Okay, thanks. Looks okay. > New webrev: > http://cr.openjdk.java.net/~mlarsson/8058298/webrev.02/ > > Incremental webrev: > http://cr.openjdk.java.net/~mlarsson/8058298/webrev.01-02/ > Thanks, Thomas From thomas.schatzl at oracle.com Tue Sep 30 10:02:40 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Sep 2014 12:02:40 +0200 Subject: RFR (XXS): JDK-8059452: G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent In-Reply-To: <542A6394.6050408@oracle.com> References: <542A6394.6050408@oracle.com> Message-ID: <1412071360.2791.14.camel@cirrus> On Tue, 2014-09-30 at 10:02 +0200, Bengt Rutisson wrote: > Hi everyone, > > Can I have a couple of reviews for this small change to update two > default values: > > http://cr.openjdk.java.net/~brutisso/8059452/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8059452 > > From the bug report: > > When the flags G1HeapWastePercent and G1MixedGCLiveThresholdPercent were > introduced their default values were picked without much performance > analysis. > > Recent performance runs indicate that G1HeapWastePercent often benefit > from a lower value and that G1MixedGCLiveThresholdPercent benefit from a > higher value. > > Suggestion is to change the default for G1HeapWastePercent to 5 (used to > be 10) adn G1MixedGCLiveThresholdPercent to 85 (used to be 65). Fine with me. Thanks, Thomas From jesper.wilhelmsson at oracle.com Tue Sep 30 10:22:08 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 30 Sep 2014 12:22:08 +0200 Subject: RFR (XXS): JDK-8059452: G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent In-Reply-To: <1412071360.2791.14.camel@cirrus> References: <542A6394.6050408@oracle.com> <1412071360.2791.14.camel@cirrus> Message-ID: <542A8450.4090808@oracle.com> Ship it! /Jesper Thomas Schatzl skrev 30/9/14 12:02: > On Tue, 2014-09-30 at 10:02 +0200, Bengt Rutisson wrote: >> Hi everyone, >> >> Can I have a couple of reviews for this small change to update two >> default values: >> >> http://cr.openjdk.java.net/~brutisso/8059452/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8059452 >> >> From the bug report: >> >> When the flags G1HeapWastePercent and G1MixedGCLiveThresholdPercent were >> introduced their default values were picked without much performance >> analysis. >> >> Recent performance runs indicate that G1HeapWastePercent often benefit >> from a lower value and that G1MixedGCLiveThresholdPercent benefit from a >> higher value. >> >> Suggestion is to change the default for G1HeapWastePercent to 5 (used to >> be 10) adn G1MixedGCLiveThresholdPercent to 85 (used to be 65). > > Fine with me. > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Tue Sep 30 11:15:40 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 30 Sep 2014 13:15:40 +0200 Subject: RFR (XXS): JDK-8059452: G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent In-Reply-To: <542A8450.4090808@oracle.com> References: <542A6394.6050408@oracle.com> <1412071360.2791.14.camel@cirrus> <542A8450.4090808@oracle.com> Message-ID: <542A90DC.9040908@oracle.com> Thanks for the reviews Thomas and Jesper! Bengt On 2014-09-30 12:22, Jesper Wilhelmsson wrote: > Ship it! > /Jesper > > Thomas Schatzl skrev 30/9/14 12:02: >> On Tue, 2014-09-30 at 10:02 +0200, Bengt Rutisson wrote: >>> Hi everyone, >>> >>> Can I have a couple of reviews for this small change to update two >>> default values: >>> >>> http://cr.openjdk.java.net/~brutisso/8059452/webrev.00/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059452 >>> >>> From the bug report: >>> >>> When the flags G1HeapWastePercent and G1MixedGCLiveThresholdPercent >>> were >>> introduced their default values were picked without much performance >>> analysis. >>> >>> Recent performance runs indicate that G1HeapWastePercent often benefit >>> from a lower value and that G1MixedGCLiveThresholdPercent benefit >>> from a >>> higher value. >>> >>> Suggestion is to change the default for G1HeapWastePercent to 5 >>> (used to >>> be 10) adn G1MixedGCLiveThresholdPercent to 85 (used to be 65). >> >> Fine with me. >> >> Thanks, >> Thomas >> >> From stefan.johansson at oracle.com Tue Sep 30 15:28:42 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 30 Sep 2014 17:28:42 +0200 Subject: RFR: 8059466: Force young GC to initiate marking cycle when stat update is requested Message-ID: <542ACC2A.2080006@oracle.com> Hi, Please review this change to allow status updates to initiate a marking cycle: https://bugs.openjdk.java.net/browse/JDK-8059466 Webrev: http://cr.openjdk.java.net/~sjohanss/8059466/webrev.00/ Summary: The "update_allocation_context_stats" GC cause has been split up to two causes, one for FullGC and one for young. The young one can be used to start a marking cycle. Thanks, Stefan From erik.osterlund at lnu.se Tue Sep 30 15:39:17 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 30 Sep 2014 15:39:17 +0000 Subject: Replace full GC macros with CRTP templates Message-ID: <936BA943-7DD0-41AB-B637-BE555C7EF919@lnu.se> Hi, I didn't like the macros in memory/space.inline.hpp so I replaced them with good old templates instead so I could sleep at night. In particular, the Curiously Recurring Template Pattern (CRTP) C++ idiom was used to solve the problem of writing code referencing the code of the derived subclasses without needing virtual calls (static polymorphism). The macros (e.g. finding out if a block is an object etc) passed in as arguments to the other macros (oh God) have been replaced with intuitive closures. All in all macros passed to macros are now closures, the main macros themselves are now inlined template methods achieving the same goals. If you, like me, want to sleep well at night, do the right thing and vote yes and I will provide a patch. :) /Erik From stefan.karlsson at oracle.com Tue Sep 30 15:55:21 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Sep 2014 17:55:21 +0200 Subject: Replace full GC macros with CRTP templates In-Reply-To: <936BA943-7DD0-41AB-B637-BE555C7EF919@lnu.se> References: <936BA943-7DD0-41AB-B637-BE555C7EF919@lnu.se> Message-ID: <542AD269.5080009@oracle.com> Hi Eric, On 2014-09-30 17:39, Erik ?sterlund wrote: > Hi, > > I didn't like the macros in memory/space.inline.hpp so I replaced them with good old templates instead so I could sleep at night. > In particular, the Curiously Recurring Template Pattern (CRTP) C++ idiom was used to solve the problem of writing code referencing the code of the derived subclasses without needing virtual calls (static polymorphism). > > The macros (e.g. finding out if a block is an object etc) passed in as arguments to the other macros (oh God) have been replaced with intuitive closures. > All in all macros passed to macros are now closures, the main macros themselves are now inlined template methods achieving the same goals. > > If you, like me, want to sleep well at night, do the right thing and vote yes and I will provide a patch. :) Did you see this thread? http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010606.html StefanK > > /Erik From erik.osterlund at lnu.se Tue Sep 30 16:17:38 2014 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 30 Sep 2014 16:17:38 +0000 Subject: Replace full GC macros with CRTP templates In-Reply-To: <542AD269.5080009@oracle.com> References: <936BA943-7DD0-41AB-B637-BE555C7EF919@lnu.se> <542AD269.5080009@oracle.com> Message-ID: I appear to have missed this. Looks like we have solved the same problem but in slightly different ways. Mine uses more modular closures and a down-casted derived space object instead of a space proxy object. I'm fine with whichever variant as long as the macros become inline methods. :) /Erik On 30 Sep 2014, at 17:55, Stefan Karlsson wrote: > Hi Eric, > > On 2014-09-30 17:39, Erik ?sterlund wrote: >> Hi, >> >> I didn't like the macros in memory/space.inline.hpp so I replaced them with good old templates instead so I could sleep at night. >> In particular, the Curiously Recurring Template Pattern (CRTP) C++ idiom was used to solve the problem of writing code referencing the code of the derived subclasses without needing virtual calls (static polymorphism). >> >> The macros (e.g. finding out if a block is an object etc) passed in as arguments to the other macros (oh God) have been replaced with intuitive closures. >> All in all macros passed to macros are now closures, the main macros themselves are now inlined template methods achieving the same goals. >> >> If you, like me, want to sleep well at night, do the right thing and vote yes and I will provide a patch. :) > > Did you see this thread? > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010606.html > > StefanK >> >> /Erik > From sangheon.kim at oracle.com Tue Sep 30 17:41:47 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Tue, 30 Sep 2014 10:41:47 -0700 Subject: RFR (S): JDK-8027428: Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 In-Reply-To: <542A6B9C.9030800@oracle.com> References: <5429EB98.6070602@oracle.com> <542A6B9C.9030800@oracle.com> Message-ID: <542AEB5B.7090800@oracle.com> Hi Bengt, Thank you for looking at this change. On 09/30/2014 01:36 AM, Bengt Rutisson wrote: > > Hi Sangheon, > > On 2014-09-30 01:30, Sangheon Kim wrote: >> Hi all, >> >> can I have reviews for the following small change to print taskqueue >> statistics >> for parallel gc, parNew and G1? >> Main changes are: >> 1) printing by 'ParallelGCVerbose' flag, not 'PrintGCDetails && >> ParallelGCVerbose'. >> 2) printing logs via 'gclog_or_tty', not 'tty'. >> 3) adding 'totals' row to sums up. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8027428 >> >> Webrev: >> http://cr.openjdk.java.net/~jwilhelm/8027428/ > > Thanks for fixing this. Could you provide some examples of what the > output looks like for the different GCs now? It would make it easier > to review this if I had examples of the output for ParNew, ParallelGC > and G1. Here's examples of logs. (-XX:+ParallelGCVerbose -XX:+PrintGCDetails) As you can see, ParNew and G1 has 'tot' while Parallel doesn't. 1. ParallelGC: before applying this patch, BOLD 'tot' raw is absent. [2014-09-30T17:15:29.66] #1: [GC (Allocation Failure) == GC Tasks Stats, GC 2 [2014-09-30T17:15:29.66] thr qpush qpop qpop-s qattempt qsteal opush omax [2014-09-30T17:15:29.66] --- ---------- ---------- ---------- ---------- ---------- ---------- ---------- [2014-09-30T17:15:29.66] 0 24213 23961 1101 848 847 0 0 [2014-09-30T17:15:29.66] 1 22197 20795 85 47 46 0 0 [2014-09-30T17:15:29.66] 2 22499 22147 932 703 702 0 0 [2014-09-30T17:15:29.66] 3 20790 20492 956 710 709 0 0 [2014-09-30T17:15:29.66] 4 0 0 0 0 0 0 0 _*[2014-09-30T17:15:29.66] tot 89699 87395 3074 2308 2304 0 0*_ [2014-09-30T17:15:29.66] --------masked------- arrays array [2014-09-30T17:15:29.66] thr push steal chunked chunks [2014-09-30T17:15:29.66] --- ---------- ---------- ---------- ---------- [2014-09-30T17:15:29.66] 0 282 185 5 282 [2014-09-30T17:15:29.66] 1 147 23 13 148 [2014-09-30T17:15:29.66] 2 187 178 0 187 [2014-09-30T17:15:29.66] 3 243 184 2 242 [2014-09-30T17:15:29.66] 4 0 0 0 0 2. ParNewGC [2014-09-30T17:26:47.08] #0: [GC (Allocation Failure) #0: [ParNewGC Termination Stats [2014-09-30T17:26:47.08] elapsed --strong roots-- -------termination------- [2014-09-30T17:26:47.08] thr ms ms % ms % attempts [2014-09-30T17:26:47.08] --- --------- --------- ------ --------- ------ -------- [2014-09-30T17:26:47.08] 0 6.12 3.76 61.44 0.15 2.45 2 [2014-09-30T17:26:47.08] 1 6.15 5.52 89.83 0.00 0.00 1 [2014-09-30T17:26:47.08] 2 6.15 0.57 9.23 0.16 2.63 1 [2014-09-30T17:26:47.08] 3 6.15 0.31 5.11 0.15 2.43 1 [2014-09-30T17:26:47.08] GC Task Stats [2014-09-30T17:26:47.08] thr qpush qpop qpop-s qattempt qsteal opush omax [2014-09-30T17:26:47.08] --- ---------- ---------- ---------- ---------- ---------- ---------- ---------- [2014-09-30T17:26:47.08] 0 26371 26041 462 130 128 0 0 [2014-09-30T17:26:47.08] 1 9186 9138 0 1 0 0 0 [2014-09-30T17:26:47.08] 2 12761 12591 834 287 286 0 0 [2014-09-30T17:26:47.08] 3 17908 17755 930 288 287 0 0 _[2014-09-30T17:26:47.08] tot 66226 65525 2226 706 701 0 0_ 3. G1GC [2014-09-30T17:31:53.87] #0: [GC pause (G1 Evacuation Pause) (young)GC Termination Stats [2014-09-30T17:31:53.87] elapsed --strong roots-- -------termination------- ------waste (KiB)------ [2014-09-30T17:31:53.87] thr ms ms % ms % attempts total alloc undo [2014-09-30T17:31:53.87] --- --------- --------- ------ --------- ------ -------- ------- ------- ------- [2014-09-30T17:31:53.88] 2 3.63 0.01 0.20 0.00 0.09 13 0 0 0 [2014-09-30T17:31:53.88] 3 3.65 0.01 0.18 0.00 0.08 13 0 0 0 [2014-09-30T17:31:53.88] 1 3.71 0.02 0.46 0.00 0.06 5 0 0 0 [2014-09-30T17:31:53.88] 0 6.83 2.32 34.01 0.00 0.00 1 0 0 0 [2014-09-30T17:31:53.88] , 0.0077719 secs] [2014-09-30T17:31:53.88] [Parallel Time: 6.9 ms, GC Workers: 4] [2014-09-30T17:31:53.88] [GC Worker Start (ms): Min: 244.3, Avg: 246.7, Max: 247.5, Diff: 3.1] [2014-09-30T17:31:53.88] [Ext Root Scanning (ms): Min: 0.0, Avg: 0.4, Max: 1.7, Diff: 1.7, Sum: 1.8] [2014-09-30T17:31:53.88] [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [2014-09-30T17:31:53.88] [Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0] [2014-09-30T17:31:53.88] [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [2014-09-30T17:31:53.88] [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.2, Diff: 0.2, Sum: 0.2] [2014-09-30T17:31:53.88] [Object Copy (ms): Min: 3.6, Avg: 3.9, Max: 4.8, Diff: 1.2, Sum: 15.7] [2014-09-30T17:31:53.88] [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [2014-09-30T17:31:53.88] [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.0, Sum: 0.3] [2014-09-30T17:31:53.88] [GC Worker Total (ms): Min: 3.7, Avg: 4.5, Max: 6.8, Diff: 3.2, Sum: 17.9] [2014-09-30T17:31:53.88] [GC Worker End (ms): Min: 251.1, Avg: 251.1, Max: 251.2, Diff: 0.0] [2014-09-30T17:31:53.88] [Code Root Fixup: 0.1 ms] [2014-09-30T17:31:53.88] [Code Root Purge: 0.0 ms] [2014-09-30T17:31:53.88] [Clear CT: 0.1 ms] [2014-09-30T17:31:53.88] [Other: 0.8 ms] [2014-09-30T17:31:53.88] [Choose CSet: 0.0 ms] [2014-09-30T17:31:53.88] [Ref Proc: 0.6 ms] [2014-09-30T17:31:53.88] [Ref Enq: 0.1 ms] [2014-09-30T17:31:53.88] [Redirty Cards: 0.0 ms] [2014-09-30T17:31:53.88] [Humongous Reclaim: 0.0 ms] [2014-09-30T17:31:53.88] [Free CSet: 0.0 ms] [2014-09-30T17:31:53.88] [Eden: 14.0M(14.0M)->0.0B(18.0M) Survivors: 0.0B->2048.0K Heap: 14.0M(64.0M)->2400.0K(64.0M)] [2014-09-30T17:31:53.88] GC Task Stats [2014-09-30T17:31:53.88] thr qpush qpop qpop-s qattempt qsteal opush omax [2014-09-30T17:31:53.88] --- ---------- ---------- ---------- ---------- ---------- ---------- ---------- [2014-09-30T17:31:53.88] 0 53278 34205 10 2 0 0 0 [2014-09-30T17:31:53.88] 1 8978 8672 4194 6843 6837 0 0 [2014-09-30T17:31:53.88] 2 9325 9067 4222 6748 6734 0 0 [2014-09-30T17:31:53.88] 3 8461 8212 3795 6329 6315 0 0 _[2014-09-30T17:31:53.88] tot 80042 60156 12221 19922 19886 0 0_ [2014-09-30T17:31:53.88] [Times: user=0.02 sys=0.00 real=0.01 secs] > > I'm also wondering if we can have an even more descriptive declaration > of ParallelGCVerbose in globals.hpp. With your change it says: > > 1532 product(bool, ParallelGCVerbose, > false, \ > 1533 "Print verbose collection statistics output for > parallel" \ > 1534 "collectors") \ > > But there is a lot of logging that has to do with parallel work (at > least in G1) that is not controlled by this flag. It seems to me that > the flag actually only controls the task queue statistics. Ideally we > could change the name of the flag, but that will be too much overhead > I guess. But we can maybe updated the description to indicate more > what it actually controls. After applying this patch, I see this flag in 4 routines (3 files). And as all of them are stats for 'taskqueue' and 'termination', I changed the description as a statistics related flag. But if it's not enough, may I ask your opinion? 1. g1CollectedHeap.cpp a) TASKQUEUE_STATS_ONLY(if (ParallelGCVerbose) print_taskqueue_stats()); b) if (ParallelGCVerbose) { MutexLocker x(stats_lock()); pss.print_termination_stats(worker_id); c) if (ParallelGCVerbose) G1ParScanThreadState::print_termination_stats_hdr(); 2. parNewGeneration.cpp a) if (ParallelGCVerbose) { TASKQUEUE_STATS_ONLY(thread_state_set.print_termination_stats()); TASKQUEUE_STATS_ONLY(thread_state_set.print_taskqueue_stats()); 3. psPromotionManager.cpp a) TASKQUEUE_STATS_ONLY(if (ParallelGCVerbose) print_taskqueue_stats()); Thanks, Sangheon > > Thanks, > Bengt > >> >> Testing: jprt >> >> Thanks, >> Sangheon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Tue Sep 30 20:58:35 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 30 Sep 2014 22:58:35 +0200 Subject: RFR (S): JDK-8027428: Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 In-Reply-To: <542AEB5B.7090800@oracle.com> References: <5429EB98.6070602@oracle.com> <542A6B9C.9030800@oracle.com> <542AEB5B.7090800@oracle.com> Message-ID: <542B197B.1000308@oracle.com> Hi, Sangheon Kim skrev 30/9/14 19:41: > Hi Bengt, > > Thank you for looking at this change. > > On 09/30/2014 01:36 AM, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> On 2014-09-30 01:30, Sangheon Kim wrote: >>> Hi all, >>> >>> can I have reviews for the following small change to print taskqueue statistics >>> for parallel gc, parNew and G1? >>> Main changes are: >>> 1) printing by 'ParallelGCVerbose' flag, not 'PrintGCDetails && >>> ParallelGCVerbose'. >>> 2) printing logs via 'gclog_or_tty', not 'tty'. >>> 3) adding 'totals' row to sums up. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8027428 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8027428/ >> >> Thanks for fixing this. Could you provide some examples of what the output >> looks like for the different GCs now? It would make it easier to review this >> if I had examples of the output for ParNew, ParallelGC and G1. > Here's examples of logs. (-XX:+ParallelGCVerbose -XX:+PrintGCDetails) > As you can see, ParNew and G1 has 'tot' while Parallel doesn't. > > 1. ParallelGC: before applying this patch, BOLD 'tot' raw is absent. > [2014-09-30T17:15:29.66] #1: [GC (Allocation Failure) == GC Tasks Stats, GC 2 > [2014-09-30T17:15:29.66] thr qpush qpop qpop-s qattempt > qsteal opush omax > [2014-09-30T17:15:29.66] --- ---------- ---------- ---------- ---------- > ---------- ---------- ---------- > [2014-09-30T17:15:29.66] 0 24213 23961 1101 848 > 847 0 0 > [2014-09-30T17:15:29.66] 1 22197 20795 85 47 > 46 0 0 > [2014-09-30T17:15:29.66] 2 22499 22147 932 703 > 702 0 0 > [2014-09-30T17:15:29.66] 3 20790 20492 956 710 > 709 0 0 > [2014-09-30T17:15:29.66] 4 0 0 0 0 > 0 0 0 > _*[2014-09-30T17:15:29.66] tot 89699 87395 3074 2308 > 2304 0 0*_ > [2014-09-30T17:15:29.66] --------masked------- arrays array > [2014-09-30T17:15:29.66] thr push steal chunked chunks > [2014-09-30T17:15:29.66] --- ---------- ---------- ---------- ---------- > [2014-09-30T17:15:29.66] 0 282 185 5 282 > [2014-09-30T17:15:29.66] 1 147 23 13 148 > [2014-09-30T17:15:29.66] 2 187 178 0 187 > [2014-09-30T17:15:29.66] 3 243 184 2 242 > [2014-09-30T17:15:29.66] 4 0 0 0 0 > > 2. ParNewGC > [2014-09-30T17:26:47.08] #0: [GC (Allocation Failure) #0: [ParNewGC Termination > Stats > [2014-09-30T17:26:47.08] elapsed --strong roots-- -------termination------- > [2014-09-30T17:26:47.08] thr ms ms % ms % attempts > [2014-09-30T17:26:47.08] --- --------- --------- ------ --------- ------ -------- > [2014-09-30T17:26:47.08] 0 6.12 3.76 61.44 0.15 2.45 2 > [2014-09-30T17:26:47.08] 1 6.15 5.52 89.83 0.00 0.00 1 > [2014-09-30T17:26:47.08] 2 6.15 0.57 9.23 0.16 2.63 1 > [2014-09-30T17:26:47.08] 3 6.15 0.31 5.11 0.15 2.43 1 > [2014-09-30T17:26:47.08] GC Task Stats > [2014-09-30T17:26:47.08] thr qpush qpop qpop-s qattempt > qsteal opush omax > [2014-09-30T17:26:47.08] --- ---------- ---------- ---------- ---------- > ---------- ---------- ---------- > [2014-09-30T17:26:47.08] 0 26371 26041 462 130 > 128 0 0 > [2014-09-30T17:26:47.08] 1 9186 9138 0 1 > 0 0 0 > [2014-09-30T17:26:47.08] 2 12761 12591 834 287 > 286 0 0 > [2014-09-30T17:26:47.08] 3 17908 17755 930 288 > 287 0 0 > _[2014-09-30T17:26:47.08] tot 66226 65525 2226 706 > 701 0 0_ > > 3. G1GC > [2014-09-30T17:31:53.87] #0: [GC pause (G1 Evacuation Pause) (young)GC > Termination Stats > [2014-09-30T17:31:53.87] elapsed --strong roots-- > -------termination------- ------waste (KiB)------ > [2014-09-30T17:31:53.87] thr ms ms % ms % attempts > total alloc undo > [2014-09-30T17:31:53.87] --- --------- --------- ------ --------- ------ > -------- ------- ------- ------- > [2014-09-30T17:31:53.88] 2 3.63 0.01 0.20 0.00 0.09 > 13 0 0 0 > [2014-09-30T17:31:53.88] 3 3.65 0.01 0.18 0.00 0.08 > 13 0 0 0 > [2014-09-30T17:31:53.88] 1 3.71 0.02 0.46 0.00 0.06 > 5 0 0 0 > [2014-09-30T17:31:53.88] 0 6.83 2.32 34.01 0.00 0.00 > 1 0 0 0 > [2014-09-30T17:31:53.88] , 0.0077719 secs] > [2014-09-30T17:31:53.88] [Parallel Time: 6.9 ms, GC Workers: 4] > [2014-09-30T17:31:53.88] [GC Worker Start (ms): Min: 244.3, Avg: 246.7, > Max: 247.5, Diff: 3.1] > [2014-09-30T17:31:53.88] [Ext Root Scanning (ms): Min: 0.0, Avg: 0.4, Max: > 1.7, Diff: 1.7, Sum: 1.8] > [2014-09-30T17:31:53.88] [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, > Diff: 0.0, Sum: 0.0] > [2014-09-30T17:31:53.88] [Processed Buffers: Min: 0, Avg: 0.0, Max: 0, > Diff: 0, Sum: 0] > [2014-09-30T17:31:53.88] [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, > Diff: 0.0, Sum: 0.0] > [2014-09-30T17:31:53.88] [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, > Max: 0.2, Diff: 0.2, Sum: 0.2] > [2014-09-30T17:31:53.88] [Object Copy (ms): Min: 3.6, Avg: 3.9, Max: 4.8, > Diff: 1.2, Sum: 15.7] > [2014-09-30T17:31:53.88] [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, > Diff: 0.0, Sum: 0.0] > [2014-09-30T17:31:53.88] [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: > 0.1, Diff: 0.0, Sum: 0.3] > [2014-09-30T17:31:53.88] [GC Worker Total (ms): Min: 3.7, Avg: 4.5, Max: > 6.8, Diff: 3.2, Sum: 17.9] > [2014-09-30T17:31:53.88] [GC Worker End (ms): Min: 251.1, Avg: 251.1, Max: > 251.2, Diff: 0.0] > [2014-09-30T17:31:53.88] [Code Root Fixup: 0.1 ms] > [2014-09-30T17:31:53.88] [Code Root Purge: 0.0 ms] > [2014-09-30T17:31:53.88] [Clear CT: 0.1 ms] > [2014-09-30T17:31:53.88] [Other: 0.8 ms] > [2014-09-30T17:31:53.88] [Choose CSet: 0.0 ms] > [2014-09-30T17:31:53.88] [Ref Proc: 0.6 ms] > [2014-09-30T17:31:53.88] [Ref Enq: 0.1 ms] > [2014-09-30T17:31:53.88] [Redirty Cards: 0.0 ms] > [2014-09-30T17:31:53.88] [Humongous Reclaim: 0.0 ms] > [2014-09-30T17:31:53.88] [Free CSet: 0.0 ms] > [2014-09-30T17:31:53.88] [Eden: 14.0M(14.0M)->0.0B(18.0M) Survivors: > 0.0B->2048.0K Heap: 14.0M(64.0M)->2400.0K(64.0M)] > [2014-09-30T17:31:53.88] GC Task Stats > [2014-09-30T17:31:53.88] thr qpush qpop qpop-s qattempt > qsteal opush omax > [2014-09-30T17:31:53.88] --- ---------- ---------- ---------- ---------- > ---------- ---------- ---------- > [2014-09-30T17:31:53.88] 0 53278 34205 10 2 > 0 0 0 > [2014-09-30T17:31:53.88] 1 8978 8672 4194 6843 > 6837 0 0 > [2014-09-30T17:31:53.88] 2 9325 9067 4222 6748 > 6734 0 0 > [2014-09-30T17:31:53.88] 3 8461 8212 3795 6329 > 6315 0 0 > _[2014-09-30T17:31:53.88] tot 80042 60156 12221 19922 > 19886 0 0_ > [2014-09-30T17:31:53.88] [Times: user=0.02 sys=0.00 real=0.01 secs] > >> >> I'm also wondering if we can have an even more descriptive declaration of >> ParallelGCVerbose in globals.hpp. With your change it says: >> >> 1532 product(bool, ParallelGCVerbose, >> false, \ >> 1533 "Print verbose collection statistics output for >> parallel" \ >> 1534 "collectors") \ >> >> But there is a lot of logging that has to do with parallel work (at least in >> G1) that is not controlled by this flag. It seems to me that the flag actually >> only controls the task queue statistics. Ideally we could change the name of >> the flag, but that will be too much overhead I guess. But we can maybe updated >> the description to indicate more what it actually controls. > After applying this patch, I see this flag in 4 routines (3 files). > And as all of them are stats for 'taskqueue' and 'termination', I changed the > description as a statistics related flag. > But if it's not enough, may I ask your opinion? I don't like that this flag controls some, but not all logging for parallel Stuff. I think we should do one of the following: A. Use ParallelGCVerbose for all verbose logging related to parallel stuff in all GCs, or B. Only use ParallelGCVerbose in ParallelGC. There aren't that many occurrences of the flag so at least B doesn't seem to be too much work. A is trickier since it involves finding all verbose logging related to parallel stuff. Keeping the flag as it is now and adding a description that says what it controls is not an attractive option imho. Such a description will rapidly become disinformation if the flag is used for some new logging. If it is too much work to fix A or B, or any other viable solution in this change I would prefer to keep the current slightly vague description (but remove the word "output") and create a CR to fix the usage of the flag. Thanks, /Jesper > > 1. g1CollectedHeap.cpp > a) TASKQUEUE_STATS_ONLY(if (ParallelGCVerbose) print_taskqueue_stats()); > b) if (ParallelGCVerbose) { > MutexLocker x(stats_lock()); > pss.print_termination_stats(worker_id); > c) if (ParallelGCVerbose) G1ParScanThreadState::print_termination_stats_hdr(); > 2. parNewGeneration.cpp > a) if (ParallelGCVerbose) { > TASKQUEUE_STATS_ONLY(thread_state_set.print_termination_stats()); > TASKQUEUE_STATS_ONLY(thread_state_set.print_taskqueue_stats()); > 3. psPromotionManager.cpp > a) TASKQUEUE_STATS_ONLY(if (ParallelGCVerbose) print_taskqueue_stats()); > > Thanks, > Sangheon > > >> >> Thanks, >> Bengt >> >>> >>> Testing: jprt >>> >>> Thanks, >>> Sangheon >> > From sangheon.kim at oracle.com Tue Sep 30 23:50:15 2014 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Tue, 30 Sep 2014 16:50:15 -0700 Subject: RFR (S): JDK-8027428: Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 In-Reply-To: <542B197B.1000308@oracle.com> References: <5429EB98.6070602@oracle.com> <542A6B9C.9030800@oracle.com> <542AEB5B.7090800@oracle.com> <542B197B.1000308@oracle.com> Message-ID: <542B41B7.8070205@oracle.com> Hi Jesper, Thank you for reviewing this. On 09/30/2014 01:58 PM, Jesper Wilhelmsson wrote: > Hi, > > Sangheon Kim skrev 30/9/14 19:41: >> Hi Bengt, >> >> Thank you for looking at this change. >> >> On 09/30/2014 01:36 AM, Bengt Rutisson wrote: >>> >>> Hi Sangheon, >>> >>> On 2014-09-30 01:30, Sangheon Kim wrote: >>>> Hi all, >>>> >>>> can I have reviews for the following small change to print >>>> taskqueue statistics >>>> for parallel gc, parNew and G1? >>>> Main changes are: >>>> 1) printing by 'ParallelGCVerbose' flag, not 'PrintGCDetails && >>>> ParallelGCVerbose'. >>>> 2) printing logs via 'gclog_or_tty', not 'tty'. >>>> 3) adding 'totals' row to sums up. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8027428 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8027428/ >>> >>> Thanks for fixing this. Could you provide some examples of what the >>> output >>> looks like for the different GCs now? It would make it easier to >>> review this >>> if I had examples of the output for ParNew, ParallelGC and G1. >> Here's examples of logs. (-XX:+ParallelGCVerbose -XX:+PrintGCDetails) >> As you can see, ParNew and G1 has 'tot' while Parallel doesn't. >> >> 1. ParallelGC: before applying this patch, BOLD 'tot' raw is absent. >> [2014-09-30T17:15:29.66] #1: [GC (Allocation Failure) == GC Tasks >> Stats, GC 2 >> [2014-09-30T17:15:29.66] thr qpush qpop qpop-s qattempt >> qsteal opush omax >> [2014-09-30T17:15:29.66] --- ---------- ---------- ---------- ---------- >> ---------- ---------- ---------- >> [2014-09-30T17:15:29.66] 0 24213 23961 1101 848 >> 847 0 0 >> [2014-09-30T17:15:29.66] 1 22197 20795 85 47 >> 46 0 0 >> [2014-09-30T17:15:29.66] 2 22499 22147 932 703 >> 702 0 0 >> [2014-09-30T17:15:29.66] 3 20790 20492 956 710 >> 709 0 0 >> [2014-09-30T17:15:29.66] 4 0 0 0 0 >> 0 0 0 >> _*[2014-09-30T17:15:29.66] tot 89699 87395 3074 2308 >> 2304 0 0*_ >> [2014-09-30T17:15:29.66] --------masked------- arrays array >> [2014-09-30T17:15:29.66] thr push steal chunked chunks >> [2014-09-30T17:15:29.66] --- ---------- ---------- ---------- ---------- >> [2014-09-30T17:15:29.66] 0 282 185 5 282 >> [2014-09-30T17:15:29.66] 1 147 23 13 148 >> [2014-09-30T17:15:29.66] 2 187 178 0 187 >> [2014-09-30T17:15:29.66] 3 243 184 2 242 >> [2014-09-30T17:15:29.66] 4 0 0 0 0 >> >> 2. ParNewGC >> [2014-09-30T17:26:47.08] #0: [GC (Allocation Failure) #0: [ParNewGC >> Termination >> Stats >> [2014-09-30T17:26:47.08] elapsed --strong roots-- >> -------termination------- >> [2014-09-30T17:26:47.08] thr ms ms % ms % >> attempts >> [2014-09-30T17:26:47.08] --- --------- --------- ------ --------- >> ------ -------- >> [2014-09-30T17:26:47.08] 0 6.12 3.76 61.44 0.15 >> 2.45 2 >> [2014-09-30T17:26:47.08] 1 6.15 5.52 89.83 0.00 >> 0.00 1 >> [2014-09-30T17:26:47.08] 2 6.15 0.57 9.23 0.16 >> 2.63 1 >> [2014-09-30T17:26:47.08] 3 6.15 0.31 5.11 0.15 >> 2.43 1 >> [2014-09-30T17:26:47.08] GC Task Stats >> [2014-09-30T17:26:47.08] thr qpush qpop qpop-s qattempt >> qsteal opush omax >> [2014-09-30T17:26:47.08] --- ---------- ---------- ---------- ---------- >> ---------- ---------- ---------- >> [2014-09-30T17:26:47.08] 0 26371 26041 462 130 >> 128 0 0 >> [2014-09-30T17:26:47.08] 1 9186 9138 0 1 >> 0 0 0 >> [2014-09-30T17:26:47.08] 2 12761 12591 834 287 >> 286 0 0 >> [2014-09-30T17:26:47.08] 3 17908 17755 930 288 >> 287 0 0 >> _[2014-09-30T17:26:47.08] tot 66226 65525 2226 706 >> 701 0 0_ >> >> 3. G1GC >> [2014-09-30T17:31:53.87] #0: [GC pause (G1 Evacuation Pause) (young)GC >> Termination Stats >> [2014-09-30T17:31:53.87] elapsed --strong roots-- >> -------termination------- ------waste (KiB)------ >> [2014-09-30T17:31:53.87] thr ms ms % ms % >> attempts >> total alloc undo >> [2014-09-30T17:31:53.87] --- --------- --------- ------ --------- ------ >> -------- ------- ------- ------- >> [2014-09-30T17:31:53.88] 2 3.63 0.01 0.20 0.00 0.09 >> 13 0 0 0 >> [2014-09-30T17:31:53.88] 3 3.65 0.01 0.18 0.00 0.08 >> 13 0 0 0 >> [2014-09-30T17:31:53.88] 1 3.71 0.02 0.46 0.00 0.06 >> 5 0 0 0 >> [2014-09-30T17:31:53.88] 0 6.83 2.32 34.01 0.00 0.00 >> 1 0 0 0 >> [2014-09-30T17:31:53.88] , 0.0077719 secs] >> [2014-09-30T17:31:53.88] [Parallel Time: 6.9 ms, GC Workers: 4] >> [2014-09-30T17:31:53.88] [GC Worker Start (ms): Min: 244.3, >> Avg: 246.7, >> Max: 247.5, Diff: 3.1] >> [2014-09-30T17:31:53.88] [Ext Root Scanning (ms): Min: 0.0, >> Avg: 0.4, Max: >> 1.7, Diff: 1.7, Sum: 1.8] >> [2014-09-30T17:31:53.88] [Update RS (ms): Min: 0.0, Avg: 0.0, >> Max: 0.0, >> Diff: 0.0, Sum: 0.0] >> [2014-09-30T17:31:53.88] [Processed Buffers: Min: 0, Avg: >> 0.0, Max: 0, >> Diff: 0, Sum: 0] >> [2014-09-30T17:31:53.88] [Scan RS (ms): Min: 0.0, Avg: 0.0, >> Max: 0.0, >> Diff: 0.0, Sum: 0.0] >> [2014-09-30T17:31:53.88] [Code Root Scanning (ms): Min: 0.0, >> Avg: 0.0, >> Max: 0.2, Diff: 0.2, Sum: 0.2] >> [2014-09-30T17:31:53.88] [Object Copy (ms): Min: 3.6, Avg: 3.9, >> Max: 4.8, >> Diff: 1.2, Sum: 15.7] >> [2014-09-30T17:31:53.88] [Termination (ms): Min: 0.0, Avg: 0.0, >> Max: 0.0, >> Diff: 0.0, Sum: 0.0] >> [2014-09-30T17:31:53.88] [GC Worker Other (ms): Min: 0.0, Avg: >> 0.1, Max: >> 0.1, Diff: 0.0, Sum: 0.3] >> [2014-09-30T17:31:53.88] [GC Worker Total (ms): Min: 3.7, Avg: >> 4.5, Max: >> 6.8, Diff: 3.2, Sum: 17.9] >> [2014-09-30T17:31:53.88] [GC Worker End (ms): Min: 251.1, Avg: >> 251.1, Max: >> 251.2, Diff: 0.0] >> [2014-09-30T17:31:53.88] [Code Root Fixup: 0.1 ms] >> [2014-09-30T17:31:53.88] [Code Root Purge: 0.0 ms] >> [2014-09-30T17:31:53.88] [Clear CT: 0.1 ms] >> [2014-09-30T17:31:53.88] [Other: 0.8 ms] >> [2014-09-30T17:31:53.88] [Choose CSet: 0.0 ms] >> [2014-09-30T17:31:53.88] [Ref Proc: 0.6 ms] >> [2014-09-30T17:31:53.88] [Ref Enq: 0.1 ms] >> [2014-09-30T17:31:53.88] [Redirty Cards: 0.0 ms] >> [2014-09-30T17:31:53.88] [Humongous Reclaim: 0.0 ms] >> [2014-09-30T17:31:53.88] [Free CSet: 0.0 ms] >> [2014-09-30T17:31:53.88] [Eden: 14.0M(14.0M)->0.0B(18.0M) Survivors: >> 0.0B->2048.0K Heap: 14.0M(64.0M)->2400.0K(64.0M)] >> [2014-09-30T17:31:53.88] GC Task Stats >> [2014-09-30T17:31:53.88] thr qpush qpop qpop-s qattempt >> qsteal opush omax >> [2014-09-30T17:31:53.88] --- ---------- ---------- ---------- ---------- >> ---------- ---------- ---------- >> [2014-09-30T17:31:53.88] 0 53278 34205 10 2 >> 0 0 0 >> [2014-09-30T17:31:53.88] 1 8978 8672 4194 6843 >> 6837 0 0 >> [2014-09-30T17:31:53.88] 2 9325 9067 4222 6748 >> 6734 0 0 >> [2014-09-30T17:31:53.88] 3 8461 8212 3795 6329 >> 6315 0 0 >> _[2014-09-30T17:31:53.88] tot 80042 60156 12221 19922 >> 19886 0 0_ >> [2014-09-30T17:31:53.88] [Times: user=0.02 sys=0.00 real=0.01 secs] >> >>> >>> I'm also wondering if we can have an even more descriptive >>> declaration of >>> ParallelGCVerbose in globals.hpp. With your change it says: >>> >>> 1532 product(bool, ParallelGCVerbose, >>> false, \ >>> 1533 "Print verbose collection statistics output for >>> parallel" \ >>> 1534 "collectors") \ >>> >>> But there is a lot of logging that has to do with parallel work (at >>> least in >>> G1) that is not controlled by this flag. It seems to me that the >>> flag actually >>> only controls the task queue statistics. Ideally we could change the >>> name of >>> the flag, but that will be too much overhead I guess. But we can >>> maybe updated >>> the description to indicate more what it actually controls. >> After applying this patch, I see this flag in 4 routines (3 files). >> And as all of them are stats for 'taskqueue' and 'termination', I >> changed the >> description as a statistics related flag. >> But if it's not enough, may I ask your opinion? > > I don't like that this flag controls some, but not all logging for > parallel Stuff. I think we should do one of the following: > > A. Use ParallelGCVerbose for all verbose logging related to parallel > stuff in all GCs, or > > B. Only use ParallelGCVerbose in ParallelGC. > > There aren't that many occurrences of the flag so at least B doesn't > seem to be too much work. A is trickier since it involves finding all > verbose logging related to parallel stuff. > > Keeping the flag as it is now and adding a description that says what > it controls is not an attractive option imho. Such a description will > rapidly become disinformation if the flag is used for some new > logging. If it is too much work to fix A or B, or any other viable > solution in this change I would prefer to keep the current slightly > vague description (but remove the word "output") and create a CR to > fix the usage of the flag. Agree with that vague description(w/o "output") would be better in this case. Does anyone have an opinion on this description change? Thanks, Sangheon > > Thanks, > /Jesper > >> >> 1. g1CollectedHeap.cpp >> a) TASKQUEUE_STATS_ONLY(if (ParallelGCVerbose) >> print_taskqueue_stats()); >> b) if (ParallelGCVerbose) { >> MutexLocker x(stats_lock()); >> pss.print_termination_stats(worker_id); >> c) if (ParallelGCVerbose) >> G1ParScanThreadState::print_termination_stats_hdr(); >> 2. parNewGeneration.cpp >> a) if (ParallelGCVerbose) { >> TASKQUEUE_STATS_ONLY(thread_state_set.print_termination_stats()); >> TASKQUEUE_STATS_ONLY(thread_state_set.print_taskqueue_stats()); >> 3. psPromotionManager.cpp >> a) TASKQUEUE_STATS_ONLY(if (ParallelGCVerbose) >> print_taskqueue_stats()); >> >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Testing: jprt >>>> >>>> Thanks, >>>> Sangheon >>> >>