From kim.barrett at oracle.com Wed Jan 2 07:31:50 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Jan 2019 02:31:50 -0500 Subject: RFR: 8215985: ZGC: Simplify reference processing in light of JDK-8175797 Message-ID: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> Please review this change to ZGC reference processing to take advantage of the changes made by JDK-8175797, which made Reference.enqueue clear the referent and made Reference.enqueue unsupported by FinalReference. As a result of JDK-8175797, the special treatment of the 'next' field by the GC is no longer needed for most reference type; only FinalReference needs special handling of that field. This means (except for FinalReference, e.g. REF_FINAL) the 'next' field no longer needs to be examined by discovery, and does not need to be self-looped by notification (eliminating a CAS to deal with possible concurrent enqueue). In discover_reference, the order of tests was changed because the inactive final reference case should be relatively rare. Doing the "strongly alive or null" test first should be a better order, with the remaining tests being for somewhat uncommon special cases that would pass that discoverability test. CR: https://bugs.openjdk.java.net/browse/JDK-8215985 Webrev: http://cr.openjdk.java.net/~kbarrett/8215985/open.00/ Testing: mach5 tier{1-4}, hs-tier{5-8}-gc. From erik.osterlund at oracle.com Wed Jan 2 12:09:57 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 2 Jan 2019 13:09:57 +0100 Subject: RFR: 8215985: ZGC: Simplify reference processing in light of JDK-8175797 In-Reply-To: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> References: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> Message-ID: Hi Kim, Looks good to me. Thanks, /Erik On 2019-01-02 08:31, Kim Barrett wrote: > Please review this change to ZGC reference processing to take > advantage of the changes made by JDK-8175797, which made > Reference.enqueue clear the referent and made Reference.enqueue > unsupported by FinalReference. > > As a result of JDK-8175797, the special treatment of the 'next' field > by the GC is no longer needed for most reference type; only > FinalReference needs special handling of that field. This means > (except for FinalReference, e.g. REF_FINAL) the 'next' field no longer > needs to be examined by discovery, and does not need to be self-looped > by notification (eliminating a CAS to deal with possible concurrent > enqueue). > > In discover_reference, the order of tests was changed because the > inactive final reference case should be relatively rare. Doing the > "strongly alive or null" test first should be a better order, with the > remaining tests being for somewhat uncommon special cases that would > pass that discoverability test. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8215985 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8215985/open.00/ > > Testing: > mach5 tier{1-4}, hs-tier{5-8}-gc. > > From zgu at redhat.com Wed Jan 2 17:49:18 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 02 Jan 2019 12:49:18 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect Message-ID: <1546451358.3477.18.camel@redhat.com> TerminatorTerminator::should_exit_termination() might return true to abort ongoing termination, due to external events. However, it should not introduce side-effect that may conflict with termination result, because the current termination may have completed, even TerminatorTerminator::should_exit_termination() returns true. This undesirable side-effect is a blocker of JDK-8215047. With JDK- 8215047, termination protocol should complete in one of two consistent state. The side-effect of setting abort flag in this particular case, G1CMTask may re-enter termination protocol with completed terminator. Bug: https://bugs.openjdk.java.net/browse/JDK-8215299 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215299/webrev.00/ Test: hotspot_gc on Linux 64 (fastdebug and releas) Thanks, -Zhengyu From kim.barrett at oracle.com Wed Jan 2 18:35:52 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Jan 2019 13:35:52 -0500 Subject: RFR: 8215985: ZGC: Simplify reference processing in light of JDK-8175797 In-Reply-To: References: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> Message-ID: <3E86812B-D98D-4812-9065-65970FC0B131@oracle.com> > On Jan 2, 2019, at 7:09 AM, Erik ?sterlund wrote: > > Hi Kim, > > Looks good to me. Thanks! > Thanks, > /Erik > > On 2019-01-02 08:31, Kim Barrett wrote: >> Please review this change to ZGC reference processing to take >> advantage of the changes made by JDK-8175797, which made >> Reference.enqueue clear the referent and made Reference.enqueue >> unsupported by FinalReference. >> As a result of JDK-8175797, the special treatment of the 'next' field >> by the GC is no longer needed for most reference type; only >> FinalReference needs special handling of that field. This means >> (except for FinalReference, e.g. REF_FINAL) the 'next' field no longer >> needs to be examined by discovery, and does not need to be self-looped >> by notification (eliminating a CAS to deal with possible concurrent >> enqueue). >> In discover_reference, the order of tests was changed because the >> inactive final reference case should be relatively rare. Doing the >> "strongly alive or null" test first should be a better order, with the >> remaining tests being for somewhat uncommon special cases that would >> pass that discoverability test. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8215985 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8215985/open.00/ >> Testing: >> mach5 tier{1-4}, hs-tier{5-8}-gc. From zgu at redhat.com Thu Jan 3 15:49:12 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 03 Jan 2019 10:49:12 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state Message-ID: <1546530552.3477.31.camel@redhat.com> Threads that enter termination protocol, should always see the same termination result, terminated or aborted. And terminator should always complete in one of two following states: Terminated: _offered_termination == _n_threads (all threads arrived and terminated) Aborted: _offered_termination = 0 (none of threads completed) Current implementation does not guarantee that, so that, it can leave terminator in inconsistent states. The inconsistent states can trigger assertion failure when reset the terminator for reuse (vs. reset_for_reuse() method) Bug: https://bugs.openjdk.java.net/browse/JDK-8215047 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.00/index.htm l Test: hotspot_gc on Linux x64 (fastdebug and release) Thanks, -Zhengyu From leihouyju at gmail.com Mon Jan 7 01:41:03 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Mon, 7 Jan 2019 09:41:03 +0800 Subject: [PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance In-Reply-To: References: Message-ID: Hi all, I submitted a patch about two weeks ago in the previous mail, however, I have not received any response so far. Did I miss something? I just follow the instructions in the webpage about *How to Contribute*. Can someone sponsor this patch? Any reviews are well appreciated! Best Regrads, Haoyu Li, Institute of Parallel and Distributed Systems(IPADS), School of Software, Shanghai Jiao Tong University Haoyu Li ?2018?12?24??? ??1:38??? > Hi all? > I have developed a patch to enhance the full GC performance of Parallel > Scavenge on OpenJDK 11, may I have some reviews? The patch is described as > follows and attached in this mail. > > *Problem* > Parallel Scavenge(PS) implements a compacting algorithm to do the full GC, > and we find that this algorithm leads in terrible GC thread utilization > (like only 8% on Derby benchmark in SPECjvm2008 suite) since there are > serious dependencies between heap regions, i.e., a region is available to > receive live objects from its source regions only after it has been > collected. The work stealing does not solve this problem, idle GC threads > cannot steal anything because most regions are unavailable to collect. > > *Optimization* > We propose *shadow region* to solve the above problem. The basic idea is > to let GC threads collect unavailable regions in advance by copying their > live data into newly allocated empty regions, i.e., shadow regions, to > resolve the region dependencies. The contents of shadow regions will be > copied back to the corresponding regions later. With our approach, GC > threads can keep working at most of the time without suffering from any > work stealing failure (except the work stealing failure happened in the end > of a full GC). And we notice that the to space in young gen is always > empty, so we exploit the empty regions in to space to play the role of > shadow regoins (if the ScavengeBeforeFullGC option is on, regions in eden > space may be used, too) and avoid allocating shadow regions from off heap > memory. > > *Evaluation* > We evaluate the full GC performance with our patch on DaCapo, SPECjvm2008, > JOlden benchmark suits, and the results shows that shadow region > optimization could improve full GC throughput by 2.1X on average, up to > 3.2X. > > The patch and evaluation result are attached. > > Best Regrads, > Haoyu Li, > Institute of Parallel and Distributed Systems(IPADS), > School of Software, > Shanghai Jiao Tong University > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.su at oracle.com Mon Jan 7 03:04:15 2019 From: paul.su at oracle.com (Paul Su) Date: Sun, 6 Jan 2019 19:04:15 -0800 Subject: [PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance In-Reply-To: References: Message-ID: <8244DD69-9E4C-4409-9042-0F2832F76ADE@oracle.com> Hi Haoyu, Thanks for your contribution. The past two weeks were holidays for most of the US and European regions. We are also in the middle of a critical phase of our release process. We are aware of your proposal and will consider it and provide feedback as soon as possible. Thanks, Paul > On Jan 6, 2019, at 5:41 PM, Haoyu Li wrote: > > Hi all, > > I submitted a patch about two weeks ago in the previous mail, however, I have not received any response so far. Did I miss something? I just follow the instructions in the webpage about How to Contribute. Can someone sponsor this patch? Any reviews are well appreciated! > > Best Regrads, > Haoyu Li, > Institute of Parallel and Distributed Systems(IPADS), > School of Software, > Shanghai Jiao Tong University > > > Haoyu Li ?2018?12?24??? ??1:38??? >> Hi all? >> I have developed a patch to enhance the full GC performance of Parallel Scavenge on OpenJDK 11, may I have some reviews? The patch is described as follows and attached in this mail. >> >> Problem >> Parallel Scavenge(PS) implements a compacting algorithm to do the full GC, and we find that this algorithm leads in terrible GC thread utilization (like only 8% on Derby benchmark in SPECjvm2008 suite) since there are serious dependencies between heap regions, i.e., a region is available to receive live objects from its source regions only after it has been collected. The work stealing does not solve this problem, idle GC threads cannot steal anything because most regions are unavailable to collect. >> >> Optimization >> We propose shadow region to solve the above problem. The basic idea is to let GC threads collect unavailable regions in advance by copying their live data into newly allocated empty regions, i.e., shadow regions, to resolve the region dependencies. The contents of shadow regions will be copied back to the corresponding regions later. With our approach, GC threads can keep working at most of the time without suffering from any work stealing failure (except the work stealing failure happened in the end of a full GC). And we notice that the to space in young gen is always empty, so we exploit the empty regions in to space to play the role of shadow regoins (if the ScavengeBeforeFullGC option is on, regions in eden space may be used, too) and avoid allocating shadow regions from off heap memory. >> >> Evaluation >> We evaluate the full GC performance with our patch on DaCapo, SPECjvm2008, JOlden benchmark suits, and the results shows that shadow region optimization could improve full GC throughput by 2.1X on average, up to 3.2X. >> >> The patch and evaluation result are attached. >> >> Best Regrads, >> Haoyu Li, >> Institute of Parallel and Distributed Systems(IPADS), >> School of Software, >> Shanghai Jiao Tong University -------------- next part -------------- An HTML attachment was scrubbed... URL: From leihouyju at gmail.com Mon Jan 7 04:08:24 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Mon, 7 Jan 2019 12:08:24 +0800 Subject: [PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance In-Reply-To: <8244DD69-9E4C-4409-9042-0F2832F76ADE@oracle.com> References: <8244DD69-9E4C-4409-9042-0F2832F76ADE@oracle.com> Message-ID: Hi Paul, Thanks for your reply, and hope you have had good holidays. I will wait for the feedback. Best, Haoyu Li Paul Su ?2019?1?7??? ??11:04??? > Hi Haoyu, > > Thanks for your contribution. The past two weeks were holidays for most of > the US and European regions. We are also in the middle of a critical phase > of our release process. We are aware of your proposal and will consider it > and provide feedback as soon as possible. > > Thanks, > Paul > > On Jan 6, 2019, at 5:41 PM, Haoyu Li wrote: > > Hi all, > > I submitted a patch about two weeks ago in the previous mail, however, I > have not received any response so far. Did I miss something? I just follow > the instructions in the webpage about *How to Contribute*. Can someone > sponsor this patch? Any reviews are well appreciated! > > Best Regrads, > Haoyu Li, > Institute of Parallel and Distributed Systems(IPADS), > School of Software, > Shanghai Jiao Tong University > > > Haoyu Li ?2018?12?24??? ??1:38??? > >> Hi all? >> I have developed a patch to enhance the full GC performance of Parallel >> Scavenge on OpenJDK 11, may I have some reviews? The patch is described as >> follows and attached in this mail. >> >> *Problem* >> Parallel Scavenge(PS) implements a compacting algorithm to do the full >> GC, and we find that this algorithm leads in terrible GC thread utilization >> (like only 8% on Derby benchmark in SPECjvm2008 suite) since there are >> serious dependencies between heap regions, i.e., a region is available to >> receive live objects from its source regions only after it has been >> collected. The work stealing does not solve this problem, idle GC threads >> cannot steal anything because most regions are unavailable to collect. >> >> *Optimization* >> We propose *shadow region* to solve the above problem. The basic idea is >> to let GC threads collect unavailable regions in advance by copying their >> live data into newly allocated empty regions, i.e., shadow regions, to >> resolve the region dependencies. The contents of shadow regions will be >> copied back to the corresponding regions later. With our approach, GC >> threads can keep working at most of the time without suffering from any >> work stealing failure (except the work stealing failure happened in the end >> of a full GC). And we notice that the to space in young gen is always >> empty, so we exploit the empty regions in to space to play the role of >> shadow regoins (if the ScavengeBeforeFullGC option is on, regions in eden >> space may be used, too) and avoid allocating shadow regions from off heap >> memory. >> >> *Evaluation* >> We evaluate the full GC performance with our patch on DaCapo, >> SPECjvm2008, JOlden benchmark suits, and the results shows that shadow >> region optimization could improve full GC throughput by 2.1X on average, up >> to 3.2X. >> >> The patch and evaluation result are attached. >> >> Best Regrads, >> Haoyu Li, >> Institute of Parallel and Distributed Systems(IPADS), >> School of Software, >> Shanghai Jiao Tong University >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.liden at oracle.com Mon Jan 7 09:28:23 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 7 Jan 2019 10:28:23 +0100 Subject: RFR: 8215985: ZGC: Simplify reference processing in light of JDK-8175797 In-Reply-To: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> References: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> Message-ID: On 1/2/19 8:31 AM, Kim Barrett wrote: > Please review this change to ZGC reference processing to take > advantage of the changes made by JDK-8175797, which made > Reference.enqueue clear the referent and made Reference.enqueue > unsupported by FinalReference. > > As a result of JDK-8175797, the special treatment of the 'next' field > by the GC is no longer needed for most reference type; only > FinalReference needs special handling of that field. This means > (except for FinalReference, e.g. REF_FINAL) the 'next' field no longer > needs to be examined by discovery, and does not need to be self-looped > by notification (eliminating a CAS to deal with possible concurrent > enqueue). > > In discover_reference, the order of tests was changed because the > inactive final reference case should be relatively rare. Doing the > "strongly alive or null" test first should be a better order, with the > remaining tests being for somewhat uncommon special cases that would > pass that discoverability test. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8215985 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8215985/open.00/ Looks good. After this change I think I'd like to do some (mostly cosmetic) adjustments in this area, but I'll follow up with a separate RFE for this later. cheers, Per > > Testing: > mach5 tier{1-4}, hs-tier{5-8}-gc. > > From thomas.schatzl at oracle.com Mon Jan 7 10:01:03 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 07 Jan 2019 11:01:03 +0100 Subject: RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder In-Reply-To: <9257C756-18C8-4342-91FA-C4CB920B500B@amazon.com> References: <3032b16a-1fe5-0381-c2b2-f6ec602ec269@bell-sw.com> <200b91e9-97f2-e8b2-4503-aeb943f75aad@oracle.com> <966f44c0-ae79-8920-fab5-5b0b3134190a@oracle.com> <47232924-ea7e-ea5a-73a9-10b00c02c59e@oracle.com> <9257C756-18C8-4342-91FA-C4CB920B500B@amazon.com> Message-ID: <40f6501b66db705703c5735360b5ed86f33553b6.camel@oracle.com> Hi all, On Mon, 2018-12-31 at 15:26 +0000, Hohensee, Paul wrote: > Yes, please proceed with the fix to tlab_alloc_reserve(). The > original assert was doing its job of detecting a bug. > > You're correct, I was looking at > http://cr.openjdk.java.net/~bulasevich/8214235/webrev.01/. In that, > chunks less than min_fill_size() could be left unfilled. Unlikely, > but possible given a bug somewhere else. > > In http://cr.openjdk.java.net/~bulasevich/8214235/webrev.00/, if the > space available between top() and hard_end() is less than > min_fill_size(), fill_with_dummy_object() should assert. > The .00 patch is the correct and most space-efficient one. As described earlier, if the VM can always fit a minimum sized object in any remainder, we do not need a tlab alloc reserve (i.e. end == hard_end). The suggested change in CollectedHeap::tlab_alloc_reserve() would just waste some memory in these cases. This is e.g. the case on 32 bit systems with ObjectAlignmentInBytes>=8 (the default) where the minimum instance size is 8 bytes, or on 64 bit systems with ObjectAlignmentInBytes>=16 where minimum object instance is 16 bytes. A better check instead of "top() < hard_end()" would be "top() != hard_end()" - as in this case, if Universe::fill_with_dummy_object() is still not able to fill in an object (it should if everything has been done correctly), it would assert for us. Basically in case objects are not aligned correctly. (I already tried to suggest something like that in http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-November/024092.html , but re-reading my answer it may not have been clear enough). Thanks, Thomas From per.liden at oracle.com Mon Jan 7 13:23:54 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 7 Jan 2019 14:23:54 +0100 Subject: RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder In-Reply-To: <40f6501b66db705703c5735360b5ed86f33553b6.camel@oracle.com> References: <3032b16a-1fe5-0381-c2b2-f6ec602ec269@bell-sw.com> <200b91e9-97f2-e8b2-4503-aeb943f75aad@oracle.com> <966f44c0-ae79-8920-fab5-5b0b3134190a@oracle.com> <47232924-ea7e-ea5a-73a9-10b00c02c59e@oracle.com> <9257C756-18C8-4342-91FA-C4CB920B500B@amazon.com> <40f6501b66db705703c5735360b5ed86f33553b6.camel@oracle.com> Message-ID: <36a48a60-de97-f77e-09e2-5cb0b16fd0dd@oracle.com> On 1/7/19 11:01 AM, Thomas Schatzl wrote: > Hi all, > > On Mon, 2018-12-31 at 15:26 +0000, Hohensee, Paul wrote: >> Yes, please proceed with the fix to tlab_alloc_reserve(). The >> original assert was doing its job of detecting a bug. >> >> You're correct, I was looking at >> http://cr.openjdk.java.net/~bulasevich/8214235/webrev.01/. In that, >> chunks less than min_fill_size() could be left unfilled. Unlikely, >> but possible given a bug somewhere else. >> >> In http://cr.openjdk.java.net/~bulasevich/8214235/webrev.00/, if the >> space available between top() and hard_end() is less than >> min_fill_size(), fill_with_dummy_object() should assert. >> > > The .00 patch is the correct and most space-efficient one. > > As described earlier, if the VM can always fit a minimum sized object > in any remainder, we do not need a tlab alloc reserve (i.e. end == > hard_end). > > The suggested change in CollectedHeap::tlab_alloc_reserve() would just > waste some memory in these cases. I agree with what Thomas is saying here and also prefer the .00 patch. cheers, Per > > This is e.g. the case on 32 bit systems with ObjectAlignmentInBytes>=8 > (the default) where the minimum instance size is 8 bytes, or on 64 bit > systems with ObjectAlignmentInBytes>=16 where minimum object instance > is 16 bytes. > > A better check instead of "top() < hard_end()" would be "top() != > hard_end()" - as in this case, if Universe::fill_with_dummy_object() is > still not able to fill in an object (it should if everything has been > done correctly), it would assert for us. Basically in case objects are > not aligned correctly. > > (I already tried to suggest something like that in > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-November/024092.html > , but re-reading my answer it may not have been clear enough). > > Thanks, > Thomas > > From shade at redhat.com Mon Jan 7 18:19:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Jan 2019 19:19:03 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8215724 Fix: http://cr.openjdk.java.net/~shade/8215724/webrev.01/ As mentioned in the bug, Epsilon deliberately reuses the super-class BarrierSet, thus implicitly verifying it does the sane thing. This is one of those cases where super-class BarrierSet does not checkcast, while it should. Testing: Linux x86_64 fastdebug {new test, gc/epsilon, hotspot tier1}, jdk-submit (running) Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From claes.redestad at oracle.com Mon Jan 7 18:30:00 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 19:30:00 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate Message-ID: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> Hi, inlining these trivial methods is beneficial on microbenchmarks while size-neutral w.r.t. compiled binary. Bug: https://bugs.openjdk.java.net/browse/JDK-8216285 Webrev: http://cr.openjdk.java.net/~redestad/8216285/open.00/ Testing: tier1 Thanks! /Claes From kim.barrett at oracle.com Mon Jan 7 20:07:01 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Jan 2019 15:07:01 -0500 Subject: RFR: 8215985: ZGC: Simplify reference processing in light of JDK-8175797 In-Reply-To: References: <08F1197A-120B-44C8-B37C-1215EACDACFB@oracle.com> Message-ID: > On Jan 7, 2019, at 4:28 AM, Per Liden wrote: > > On 1/2/19 8:31 AM, Kim Barrett wrote: >> Please review this change to ZGC reference processing to take >> advantage of the changes made by JDK-8175797, which made >> Reference.enqueue clear the referent and made Reference.enqueue >> unsupported by FinalReference. >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8215985 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8215985/open.00/ > > Looks good. > > After this change I think I'd like to do some (mostly cosmetic) adjustments in this area, but I'll follow up with a separate RFE for this later. Thanks! From hohensee at amazon.com Mon Jan 7 22:32:25 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Jan 2019 22:32:25 +0000 Subject: RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder In-Reply-To: <36a48a60-de97-f77e-09e2-5cb0b16fd0dd@oracle.com> References: <3032b16a-1fe5-0381-c2b2-f6ec602ec269@bell-sw.com> <200b91e9-97f2-e8b2-4503-aeb943f75aad@oracle.com> <966f44c0-ae79-8920-fab5-5b0b3134190a@oracle.com> <47232924-ea7e-ea5a-73a9-10b00c02c59e@oracle.com> <9257C756-18C8-4342-91FA-C4CB920B500B@amazon.com> <40f6501b66db705703c5735360b5ed86f33553b6.camel@oracle.com> <36a48a60-de97-f77e-09e2-5cb0b16fd0dd@oracle.com> Message-ID: <015C401B-4272-4C8C-B9DD-3794B07CD47B@amazon.com> Then lgtm too. Thanks, Paul ?On 1/7/19, 5:24 AM, "Per Liden" wrote: On 1/7/19 11:01 AM, Thomas Schatzl wrote: > Hi all, > > On Mon, 2018-12-31 at 15:26 +0000, Hohensee, Paul wrote: >> Yes, please proceed with the fix to tlab_alloc_reserve(). The >> original assert was doing its job of detecting a bug. >> >> You're correct, I was looking at >> http://cr.openjdk.java.net/~bulasevich/8214235/webrev.01/. In that, >> chunks less than min_fill_size() could be left unfilled. Unlikely, >> but possible given a bug somewhere else. >> >> In http://cr.openjdk.java.net/~bulasevich/8214235/webrev.00/, if the >> space available between top() and hard_end() is less than >> min_fill_size(), fill_with_dummy_object() should assert. >> > > The .00 patch is the correct and most space-efficient one. > > As described earlier, if the VM can always fit a minimum sized object > in any remainder, we do not need a tlab alloc reserve (i.e. end == > hard_end). > > The suggested change in CollectedHeap::tlab_alloc_reserve() would just > waste some memory in these cases. I agree with what Thomas is saying here and also prefer the .00 patch. cheers, Per > > This is e.g. the case on 32 bit systems with ObjectAlignmentInBytes>=8 > (the default) where the minimum instance size is 8 bytes, or on 64 bit > systems with ObjectAlignmentInBytes>=16 where minimum object instance > is 16 bytes. > > A better check instead of "top() < hard_end()" would be "top() != > hard_end()" - as in this case, if Universe::fill_with_dummy_object() is > still not able to fill in an object (it should if everything has been > done correctly), it would assert for us. Basically in case objects are > not aligned correctly. > > (I already tried to suggest something like that in > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-November/024092.html > , but re-reading my answer it may not have been clear enough). > > Thanks, > Thomas > > From kim.barrett at oracle.com Tue Jan 8 00:58:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Jan 2019 19:58:17 -0500 Subject: RFR: 8216258: Make FreeIdSet semaphore-based Message-ID: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> Please review this replacement of the "private" FreeIdSet with G1FreeIdSet, which has a new implementation using a semaphore rather than a monitor. The representation of the set is largely the same, being an array of "next" indices into the array, with a "head" value containing the current first index. However, the manipulation of the set is now done without a lock, using CAS to change the head. To avoid ABA, the head value also contains an update counter which is incremented on each modification of the head. Also generalized to allow the id set to start with a non-zero id, because that looks like it might simplify other changes I'm working on. The entire "free id set" has been moved to new files and names (with the usual G1 prefixing), to permit gtest-based unit testing. CR: https://bugs.openjdk.java.net/browse/JDK-8216258 Webrev: http://cr.openjdk.java.net/~kbarrett/8216258/open.00/ Testing: mach5 tier1-5. I didn't bother to do performance testing because I think our performance tests rarely hit this code, so I don't expect the monitor elimination to have any measureable effect for those tests. From erik.helin at oracle.com Tue Jan 8 09:31:45 2019 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 8 Jan 2019 10:31:45 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> Message-ID: On 1/7/19 7:30 PM, Claes Redestad wrote: > Hi, > > inlining these trivial methods is beneficial on microbenchmarks while > size-neutral w.r.t. compiled binary. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216285 > Webrev: http://cr.openjdk.java.net/~redestad/8216285/open.00/ Looks good and trivial, Reviewed. Thanks, Erik > Testing: tier1 > > Thanks! > > /Claes From claes.redestad at oracle.com Tue Jan 8 09:58:01 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 10:58:01 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> Message-ID: On 2019-01-08 10:31, Erik Helin wrote: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8216285/open.00/ > > Looks good and trivial, Reviewed. Thanks, Erik! /Claes From rkennke at redhat.com Tue Jan 8 11:28:28 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 8 Jan 2019 12:28:28 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> Message-ID: Those methods are virtual. How useful is it to flag them 'inline' ? Roman > On 1/7/19 7:30 PM, Claes Redestad wrote: >> Hi, >> >> inlining these trivial methods is beneficial on microbenchmarks while >> size-neutral w.r.t. compiled binary. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216285 >> Webrev: http://cr.openjdk.java.net/~redestad/8216285/open.00/ > > Looks good and trivial, Reviewed. > > Thanks, > Erik > >> Testing: tier1 >> >> Thanks! >> >> /Claes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From claes.redestad at oracle.com Tue Jan 8 11:38:56 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 12:38:56 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> Message-ID: <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> On 2019-01-08 12:28, Roman Kennke wrote: > Those methods are virtual. How useful is it to flag them 'inline' ? Useful enough to measurably save a few ns/op on Array.newInstance and Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay in the JNI slow path). /Claes From rkennke at redhat.com Tue Jan 8 11:35:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 8 Jan 2019 12:35:56 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> Message-ID: <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> >> Those methods are virtual. How useful is it to flag them 'inline' ? > > Useful enough to measurably save a few ns/op on Array.newInstance and > Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay > in the JNI slow path). If a method is virtual, it cannot be inlined, right? Unless you call it in a funny non-virtual way. Or what am I missing? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From claes.redestad at oracle.com Tue Jan 8 11:47:01 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 12:47:01 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> Message-ID: <948a294e-3d8b-13e5-2db2-c4f415292ae1@oracle.com> On 2019-01-08 12:35, Roman Kennke wrote: >>> Those methods are virtual. How useful is it to flag them 'inline' ? >> >> Useful enough to measurably save a few ns/op on Array.newInstance and >> Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay >> in the JNI slow path). > > If a method is virtual, it cannot be inlined, right? Unless you call it > in a funny non-virtual way. Or what am I missing? Could be these are the only implementations when compiling without shenandoah so gcc realizes the virtual can be ignored? /Claes From rkennke at redhat.com Tue Jan 8 11:44:02 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 8 Jan 2019 12:44:02 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: <948a294e-3d8b-13e5-2db2-c4f415292ae1@oracle.com> References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> <948a294e-3d8b-13e5-2db2-c4f415292ae1@oracle.com> Message-ID: >>>> Those methods are virtual. How useful is it to flag them 'inline' ? >>> >>> Useful enough to measurably save a few ns/op on Array.newInstance and >>> Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay >>> in the JNI slow path). >> >> If a method is virtual, it cannot be inlined, right? Unless you call it >> in a funny non-virtual way. Or what am I missing? > > Could be these are the only implementations when compiling without > shenandoah so gcc realizes the virtual can be ignored? I doubt that gcc can make that call. The linker probably could, but at this point it would be too late. C++ is not Java. I don't think the patch hurts, but I doubt its usefulness ;-) Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From claes.redestad at oracle.com Tue Jan 8 11:55:31 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 12:55:31 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> <948a294e-3d8b-13e5-2db2-c4f415292ae1@oracle.com> Message-ID: <3827d9ac-0825-468b-bf54-3077a678fc92@oracle.com> On 2019-01-08 12:44, Roman Kennke wrote: >>>>> Those methods are virtual. How useful is it to flag them 'inline' ? >>>> >>>> Useful enough to measurably save a few ns/op on Array.newInstance and >>>> Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay >>>> in the JNI slow path). >>> >>> If a method is virtual, it cannot be inlined, right? Unless you call it >>> in a funny non-virtual way. Or what am I missing? >> >> Could be these are the only implementations when compiling without >> shenandoah so gcc realizes the virtual can be ignored? > > I doubt that gcc can make that call. The linker probably could, but at > this point it would be too late. C++ is not Java. I don't think the > patch hurts, but I doubt its usefulness ;-) I only go by what I see in microbenchmarks, and somehow this netted a small improvement. /Claes From erik.osterlund at oracle.com Tue Jan 8 11:50:04 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 8 Jan 2019 12:50:04 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: Message-ID: <2762f177-975f-fae8-543b-a53e7839a6cf@oracle.com> Hi Aleksey, The decision to have GCs be explicit about their choice of check-cast arraycopy was intentional. So I think the implementation should move into an epsilon barrierset inline hpp file. The reason is that every GC seems to want their own optimized version of arraycopy with checkcast, handling the fact that a partial range of writes was committed. For the write barrier GCs (ModRef), they have their own partial card range dirtying mechanism, for ZGC, there is a load barrier per element, Shenandoah has its own interesting looking template thing. So the variation of arraycopy that performs checks covariance but does not apply any GC barriers (i.e. raw loads and stores), will only be used by Epsilon and would most likely be an error if it was used for any other GC. Another variant could be to truly generalize the code and have a shared checkcast arraycopy loop that itself perform Access loads and stores, and let others overriding that apply whatever bulking optimizations they want to have. But I thought the additional template logic for that did not seem to be worth it, as the amount of code is so small, it seemed like that mechanism would introduce more complexity than it tried to generalize. Do you agree? Thanks, /Erik On 2019-01-07 19:19, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215724 > > Fix: > http://cr.openjdk.java.net/~shade/8215724/webrev.01/ > > As mentioned in the bug, Epsilon deliberately reuses the super-class BarrierSet, thus implicitly > verifying it does the sane thing. This is one of those cases where super-class BarrierSet does not > checkcast, while it should. > > Testing: Linux x86_64 fastdebug {new test, gc/epsilon, hotspot tier1}, jdk-submit (running) > > Thanks, > -Aleksey > From rkennke at redhat.com Tue Jan 8 11:56:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 8 Jan 2019 12:56:13 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: <3827d9ac-0825-468b-bf54-3077a678fc92@oracle.com> References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> <948a294e-3d8b-13e5-2db2-c4f415292ae1@oracle.com> <3827d9ac-0825-468b-bf54-3077a678fc92@oracle.com> Message-ID: >>>>>> Those methods are virtual. How useful is it to flag them 'inline' ? >>>>> >>>>> Useful enough to measurably save a few ns/op on Array.newInstance and >>>>> Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay >>>>> in the JNI slow path). >>>> >>>> If a method is virtual, it cannot be inlined, right? Unless you call it >>>> in a funny non-virtual way. Or what am I missing? >>> >>> Could be these are the only implementations when compiling without >>> shenandoah so gcc realizes the virtual can be ignored? >> >> I doubt that gcc can make that call. The linker probably could, but at >> this point it would be too late. C++ is not Java. I don't think the >> patch hurts, but I doubt its usefulness ;-) > > I only go by what I see in microbenchmarks, and somehow this netted a > small improvement. Ok. I'm just curious. ;-) Can you by any chance send me the microbenchmark? Maybe I can figure out what's going on. I suppose there is a chance that if you call one of those methods with an object of known type, e.g. G1CollectedHeap*, and the compiler can prove that it cannot be a subtype, then yeah, it might actually inline it. If the benchmark is using jmh, you can run with and without the patch with perfasm profiler and it should show you what's different in the hot path. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From claes.redestad at oracle.com Tue Jan 8 12:10:52 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 13:10:52 +0100 Subject: RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate In-Reply-To: References: <0ede633c-763c-1ed2-89ec-a26dfb0b5178@oracle.com> <13c77bc3-db65-4d5f-b08e-056ca9452ce0@oracle.com> <404ea570-4a4d-7614-bffe-a26c4cd95717@redhat.com> <948a294e-3d8b-13e5-2db2-c4f415292ae1@oracle.com> <3827d9ac-0825-468b-bf54-3077a678fc92@oracle.com> Message-ID: <5561d21a-6c89-b88b-463a-c76c239efc9b@oracle.com> On 2019-01-08 12:56, Roman Kennke wrote: >>>>>>> Those methods are virtual. How useful is it to flag them 'inline' ? >>>>>> >>>>>> Useful enough to measurably save a few ns/op on Array.newInstance and >>>>>> Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay >>>>>> in the JNI slow path). >>>>> >>>>> If a method is virtual, it cannot be inlined, right? Unless you call it >>>>> in a funny non-virtual way. Or what am I missing? >>>> >>>> Could be these are the only implementations when compiling without >>>> shenandoah so gcc realizes the virtual can be ignored? >>> >>> I doubt that gcc can make that call. The linker probably could, but at >>> this point it would be too late. C++ is not Java. I don't think the >>> patch hurts, but I doubt its usefulness ;-) >> >> I only go by what I see in microbenchmarks, and somehow this netted a >> small improvement. > > Ok. > > I'm just curious. ;-) Can you by any chance send me the microbenchmark? > Maybe I can figure out what's going on. I suppose there is a chance that > if you call one of those methods with an object of known type, e.g. > G1CollectedHeap*, and the compiler can prove that it cannot be a > subtype, then yeah, it might actually inline it. If the benchmark is > using jmh, you can run with and without the patch with perfasm profiler > and it should show you what's different in the hot path. I've run these: import org.openjdk.jmh.annotations.*; import java.util.concurrent.TimeUnit; import java.lang.reflect.Array; @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class ArrayInstantiationBenchmark { @Param({"10", "100", "1000"}) private int length; public Object obj = new Object(); @Benchmark public Object newInstance() { return Array.newInstance(String.class, length); } @Benchmark public Object clone() { return obj.clone(); } } with -XX:TieredStopAtLevel=1 - -prof perfasm doesn't say much since the time is mainly spent in native code, but async-profiler profiles indicates the objArray_allocate method no longer manifests on the stack. /Claes > > Roman > > From thomas.schatzl at oracle.com Tue Jan 8 12:41:47 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 08 Jan 2019 13:41:47 +0100 Subject: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large Message-ID: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> Hi all, can I have reviews for this fix to some test options to make the TestPromotionEventWithG1 test more stable on the platforms we support? In particular, depending on hardware, the minimum TLAB size given in the test was too small to accomodate the prefetching code C2 emits when allocating objects. The fix is to minimize this buffer by twiddling with prefetching amounts, and increasing the minimum tlab size a bit - so that the test still fails with the patch for 8212766 not applied. Thanks go to Goetz from SAP who figured out the values for the prefetching so that most supported systems worked. @Goeth: can you check this fix on your systems too? CR: https://bugs.openjdk.java.net/browse/JDK-8216316 Webrev: http://cr.openjdk.java.net/~tschatzl/8216316/ Testing: Test failing test on various machines in our CI system Thanks, Thomas From goetz.lindenmaier at sap.com Tue Jan 8 12:46:16 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Jan 2019 12:46:16 +0000 Subject: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large In-Reply-To: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> Message-ID: <992f0bed240c4a788055645c4b1dd46e@sap.com> Hi Thomas, the change looks good. It will be tested in our test infrastructure tonight, I'll come back with the results tomorrow... just to make sure. Best regards, Goetz. > -----Original Message----- > From: Thomas Schatzl > Sent: Dienstag, 8. Januar 2019 13:42 > To: hotspot-gc-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RFR (XS): 8216316: > jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to > reserved TLAB area too large > > Hi all, > > can I have reviews for this fix to some test options to make the > TestPromotionEventWithG1 test more stable on the platforms we support? > > In particular, depending on hardware, the minimum TLAB size given in > the test was too small to accomodate the prefetching code C2 emits when > allocating objects. > > The fix is to minimize this buffer by twiddling with prefetching > amounts, and increasing the minimum tlab size a bit - so that the test > still fails with the patch for 8212766 not applied. > > Thanks go to Goetz from SAP who figured out the values for the > prefetching so that most supported systems worked. > > @Goeth: can you check this fix on your systems too? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8216316 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8216316/ > Testing: > Test failing test on various machines in our CI system > > Thanks, > Thomas > From thomas.schatzl at oracle.com Tue Jan 8 14:21:51 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 08 Jan 2019 15:21:51 +0100 Subject: RFR: 8216258: Make FreeIdSet semaphore-based In-Reply-To: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> References: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> Message-ID: Hi, On Mon, 2019-01-07 at 19:58 -0500, Kim Barrett wrote: > Please review this replacement of the "private" FreeIdSet with > G1FreeIdSet, which has a new implementation using a semaphore rather > than a monitor. > > The representation of the set is largely the same, being an array of > "next" indices into the array, with a "head" value containing the > current first index. However, the manipulation of the set is now > done > without a lock, using CAS to change the head. To avoid ABA, the head > value also contains an update counter which is incremented on each > modification of the head. > > Also generalized to allow the id set to start with a non-zero id, > because that looks like it might simplify other changes I'm working > on. > > The entire "free id set" has been moved to new files and names (with > the usual G1 prefixing), to permit gtest-based unit testing. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8216258 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8216258/open.00/ > > Testing: > mach5 tier1-5. thanks for the cleanup. Some notes: - is it possible to add a destructor that deletes the G1FreeIdSet instance? I am aware that currently the destructor of DirtyCardQueueSet is never called, but still it would be nice to clean up afterwards. - not sure exactly why uintx is used for G1FreeIdSet::_head_index_mask and _head: uintx are 32 bit on 32 bit machines, so the update counter will be constrained by 32 bit - bits(size) there anyway. On 64 bit uintx is 64 bit, so the update counter does have the full 32 bit range available, which is probably why uintx has been chosen anyway? I do think that even on 32 bits the remaining range should be sufficient so it seems okay. - maybe the cmpxchg loops in G1FreeIdSet::claim_par_id() and release_par_id() could be factored out into a helper somehow. - I would prefer if the "claimed" constant were camel cased like static consts should be to make it more distinguishable to regular local variables. - pre-existing: I have no idea what the documentation of G1FreeIdSet "// Represents a set of free small integer ids" is supposed to mean. Could you fix that comment for the G1FreeIdSet class please? Thanks, Thomas From shade at redhat.com Tue Jan 8 15:22:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 16:22:37 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: <2762f177-975f-fae8-543b-a53e7839a6cf@oracle.com> References: <2762f177-975f-fae8-543b-a53e7839a6cf@oracle.com> Message-ID: <74d67361-91fd-c957-9d11-eac88600100c@redhat.com> Hi Erik, On 1/8/19 12:50 PM, Erik ?sterlund wrote: > The decision to have GCs be explicit about their choice of check-cast arraycopy was intentional. Mmm. That intent is entirely not clear. If the intent was to force GC implementation to come up with its own arraycopy handling, then BarrierSet::oop_arraycopy_in_heap had to be Unimplemented(). That would make the choice "explicit". Instead, the default implementation silently/implicitly calls to Raw::oop_arraycopy -- that is a bug, and that is the reason Epsilon broke the Java semantics. > So I think the implementation should move into an epsilon barrierset inline hpp file. I remember when I was doing the EpsilonBarrierSet an year ago, you told me to delegate stuff to superclass, because no-op GC can use whatever the default implementation is doing. At the time, I thought it is a mere development convenience, but today I think this is actually a good GC API design: the default implementation does the minimal+correct thing, and does not break Java semantics. So if GC does not need anything special, it can use all the defaults. Which means, among other things, that one of the sanity tests for the GC API is having empty EpsilonBarrierSet. > The reason is that every GC seems to want their own optimized version of arraycopy with checkcast, > handling the fact that a partial range of writes was committed. For the write barrier GCs (ModRef), > they have their own partial card range dirtying mechanism, for ZGC, there is a load barrier per > element, Shenandoah has its own interesting looking template thing. So the variation of arraycopy > that performs checks covariance but does not apply any GC barriers (i.e. raw loads and stores), will > only be used by Epsilon and would most likely be an error if it was used for any other GC. True. If GC needs something special w.r.t. barriers and some such, it has to override BS methods. If GC does not need special handling, the default implementation has to do the right thing. The super-class implementation also serves as the basis what should a concrete GC implementation minimally do to maintain Java semantics. It is actually the same way with other methods in BarrierSet, as far as I see it (for example, xchg does atomics/locking, stores actually store, loads actually load) and I don't see the reason why arraycopy should be special and not do what is expected by Java rules (copying with checking casts). > Do you agree? I have to disagree. I still think default BarrierSet should maintain Java semantics by providing the minimal, but still correct code. We can implement the fix in EpsilonBarrierSet, but it just works around the awkward special case in GC interface, diluting the GC interface itself, and I see no compelling reason to accept that. Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Tue Jan 8 16:24:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 8 Jan 2019 17:24:40 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: <74d67361-91fd-c957-9d11-eac88600100c@redhat.com> References: <2762f177-975f-fae8-543b-a53e7839a6cf@oracle.com> <74d67361-91fd-c957-9d11-eac88600100c@redhat.com> Message-ID: FWIW, I have to agree with Aleksey here. Either make superclass abstract or provide a usable implementation for GCs that don't need anything special (e.g. Epsilon). Roman > Hi Erik, > > On 1/8/19 12:50 PM, Erik ?sterlund wrote: >> The decision to have GCs be explicit about their choice of check-cast arraycopy was intentional. > > Mmm. That intent is entirely not clear. If the intent was to force GC implementation to come up with > its own arraycopy handling, then BarrierSet::oop_arraycopy_in_heap had to be Unimplemented(). That > would make the choice "explicit". Instead, the default implementation silently/implicitly calls to > Raw::oop_arraycopy -- that is a bug, and that is the reason Epsilon broke the Java semantics. > >> So I think the implementation should move into an epsilon barrierset inline hpp file. > > I remember when I was doing the EpsilonBarrierSet an year ago, you told me to delegate stuff to > superclass, because no-op GC can use whatever the default implementation is doing. At the time, I > thought it is a mere development convenience, but today I think this is actually a good GC API > design: the default implementation does the minimal+correct thing, and does not break Java > semantics. So if GC does not need anything special, it can use all the defaults. Which means, among > other things, that one of the sanity tests for the GC API is having empty EpsilonBarrierSet. > > >> The reason is that every GC seems to want their own optimized version of arraycopy with checkcast, >> handling the fact that a partial range of writes was committed. For the write barrier GCs (ModRef), >> they have their own partial card range dirtying mechanism, for ZGC, there is a load barrier per >> element, Shenandoah has its own interesting looking template thing. So the variation of arraycopy >> that performs checks covariance but does not apply any GC barriers (i.e. raw loads and stores), will >> only be used by Epsilon and would most likely be an error if it was used for any other GC. > > True. If GC needs something special w.r.t. barriers and some such, it has to override BS methods. If > GC does not need special handling, the default implementation has to do the right thing. The > super-class implementation also serves as the basis what should a concrete GC implementation > minimally do to maintain Java semantics. It is actually the same way with other methods in > BarrierSet, as far as I see it (for example, xchg does atomics/locking, stores actually store, loads > actually load) and I don't see the reason why arraycopy should be special and not do what is > expected by Java rules (copying with checking casts). > >> Do you agree? > > I have to disagree. I still think default BarrierSet should maintain Java semantics by providing the > minimal, but still correct code. We can implement the fix in EpsilonBarrierSet, but it just works > around the awkward special case in GC interface, diluting the GC interface itself, and I see no > compelling reason to accept that. > > Cheers, > -Aleksey > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From leo.korinth at oracle.com Tue Jan 8 17:30:52 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 8 Jan 2019 18:30:52 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: Message-ID: Hi Aleksey! I guess you tried to use the already existing test (ArrayStoreExceptionTest.java) before you created the new test. What was the reason for not using it in the end? I would rather like that you tried to use the old test case, I believe it would improve overall testing and maintainability. Also, there is a slight misleading comment on the #endif in barrierSet.inline.hpp, maybe instead use the style #endif // pragma once ;-) 24 #ifndef SHARE_VM_GC_SHARED_BARRIERSET_INLINE_HPP 25 #define SHARE_VM_GC_SHARED_BARRIERSET_INLINE_HPP 60 #endif // SHARE_VM_GC_SHARED_BARRIERSET_HPP Thanks, Leo Instead of using the existing On 07/01/2019 19:19, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215724 > > Fix: > http://cr.openjdk.java.net/~shade/8215724/webrev.01/ > > As mentioned in the bug, Epsilon deliberately reuses the super-class BarrierSet, thus implicitly > verifying it does the sane thing. This is one of those cases where super-class BarrierSet does not > checkcast, while it should. > > Testing: Linux x86_64 fastdebug {new test, gc/epsilon, hotspot tier1}, jdk-submit (running) > > Thanks, > -Aleksey > From erik.osterlund at oracle.com Tue Jan 8 18:00:15 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 8 Jan 2019 19:00:15 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: <2762f177-975f-fae8-543b-a53e7839a6cf@oracle.com> <74d67361-91fd-c957-9d11-eac88600100c@redhat.com> Message-ID: <4597b815-39ef-3c26-f3bc-9085328ca9d7@oracle.com> Hi Roman and Aleksey, I suppose I can see both points of view. I have reconsidered, and am okay with adding this to BarrierSet instead, given Aleksey's rationale. Looks good. Thanks, /Erik On 2019-01-08 17:24, Roman Kennke wrote: > FWIW, I have to agree with Aleksey here. Either make superclass abstract > or provide a usable implementation for GCs that don't need anything > special (e.g. Epsilon). > > Roman > >> Hi Erik, >> >> On 1/8/19 12:50 PM, Erik ?sterlund wrote: >>> The decision to have GCs be explicit about their choice of check-cast arraycopy was intentional. >> >> Mmm. That intent is entirely not clear. If the intent was to force GC implementation to come up with >> its own arraycopy handling, then BarrierSet::oop_arraycopy_in_heap had to be Unimplemented(). That >> would make the choice "explicit". Instead, the default implementation silently/implicitly calls to >> Raw::oop_arraycopy -- that is a bug, and that is the reason Epsilon broke the Java semantics. >> >>> So I think the implementation should move into an epsilon barrierset inline hpp file. >> >> I remember when I was doing the EpsilonBarrierSet an year ago, you told me to delegate stuff to >> superclass, because no-op GC can use whatever the default implementation is doing. At the time, I >> thought it is a mere development convenience, but today I think this is actually a good GC API >> design: the default implementation does the minimal+correct thing, and does not break Java >> semantics. So if GC does not need anything special, it can use all the defaults. Which means, among >> other things, that one of the sanity tests for the GC API is having empty EpsilonBarrierSet. >> >> >>> The reason is that every GC seems to want their own optimized version of arraycopy with checkcast, >>> handling the fact that a partial range of writes was committed. For the write barrier GCs (ModRef), >>> they have their own partial card range dirtying mechanism, for ZGC, there is a load barrier per >>> element, Shenandoah has its own interesting looking template thing. So the variation of arraycopy >>> that performs checks covariance but does not apply any GC barriers (i.e. raw loads and stores), will >>> only be used by Epsilon and would most likely be an error if it was used for any other GC. >> >> True. If GC needs something special w.r.t. barriers and some such, it has to override BS methods. If >> GC does not need special handling, the default implementation has to do the right thing. The >> super-class implementation also serves as the basis what should a concrete GC implementation >> minimally do to maintain Java semantics. It is actually the same way with other methods in >> BarrierSet, as far as I see it (for example, xchg does atomics/locking, stores actually store, loads >> actually load) and I don't see the reason why arraycopy should be special and not do what is >> expected by Java rules (copying with checking casts). >> >>> Do you agree? >> >> I have to disagree. I still think default BarrierSet should maintain Java semantics by providing the >> minimal, but still correct code. We can implement the fix in EpsilonBarrierSet, but it just works >> around the awkward special case in GC interface, diluting the GC interface itself, and I see no >> compelling reason to accept that. >> >> Cheers, >> -Aleksey >> > From shade at redhat.com Tue Jan 8 18:48:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 19:48:58 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: Message-ID: On 1/8/19 6:30 PM, Leo Korinth wrote: > I guess you tried to use the already existing test (ArrayStoreExceptionTest.java) before you created > the new test. What was the reason for not using it in the end? I would rather like that you tried to > use the old test case, I believe it would improve overall testing and maintainability. I prefer to have a targeted test that would test check-casted arraycopy for interpreter, C1 and C2 barrier sets, see the @run clauses there. It is in line with other Epsilon tests. It is also specially crafted to work with Epsilon, e.g. it does not allocate all that much. Plus it would run in tier1 without any additional testing options. ArrayStoreExceptionTest would require running with TEST_VM_OPTS or such. > Also, there is a slight misleading comment on the #endif in barrierSet.inline.hpp, maybe instead use > the style #endif // pragma once ;-) > > ? 24 #ifndef SHARE_VM_GC_SHARED_BARRIERSET_INLINE_HPP > ? 25 #define SHARE_VM_GC_SHARED_BARRIERSET_INLINE_HPP > ? 60 #endif // SHARE_VM_GC_SHARED_BARRIERSET_HPP I read the entire discussion about #pragma once (JDK-8216022), and it seems there is no consensus yet about using it, and also there are reports that some compilers people use are not supporting it. So, I fixed the comment instead. I hope Coleen has the script that does #pragma-once-ing, so it can catch the new file! Updated webrev: http://cr.openjdk.java.net/~shade/8215724/webrev.02/ webrev.01 passed jdk-submit, and there are no code changes in webrev.02, only fixed comment. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Tue Jan 8 18:50:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 19:50:14 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: <4597b815-39ef-3c26-f3bc-9085328ca9d7@oracle.com> References: <2762f177-975f-fae8-543b-a53e7839a6cf@oracle.com> <74d67361-91fd-c957-9d11-eac88600100c@redhat.com> <4597b815-39ef-3c26-f3bc-9085328ca9d7@oracle.com> Message-ID: <834a8f35-adf3-87b2-65b8-b685bc0c2e3f@redhat.com> On 1/8/19 7:00 PM, Erik ?sterlund wrote: > I suppose I can see both points of view. I have reconsidered, and am okay with adding this to > BarrierSet instead, given Aleksey's rationale. Noted, thanks! See another branch for final webrev. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sangheon.kim at oracle.com Tue Jan 8 19:19:48 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Tue, 8 Jan 2019 11:19:48 -0800 Subject: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large In-Reply-To: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> Message-ID: Hi Thomas, On 1/8/19 4:41 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this fix to some test options to make the > TestPromotionEventWithG1 test more stable on the platforms we support? > > In particular, depending on hardware, the minimum TLAB size given in > the test was too small to accomodate the prefetching code C2 emits when > allocating objects. > > The fix is to minimize this buffer by twiddling with prefetching > amounts, and increasing the minimum tlab size a bit - so that the test > still fails with the patch for 8212766 not applied. > > Thanks go to Goetz from SAP who figured out the values for the > prefetching so that most supported systems worked. > > @Goeth: can you check this fix on your systems too? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8216316 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8216316/ Looks good. Thanks, Sangheon > Testing: > Test failing test on various machines in our CI system > > Thanks, > Thomas > > From per.liden at oracle.com Tue Jan 8 20:14:20 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 8 Jan 2019 21:14:20 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 Message-ID: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 /Per From shade at redhat.com Tue Jan 8 20:17:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 21:17:11 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> Message-ID: <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> On 1/8/19 9:14 PM, Per Liden wrote: > Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced > unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 > Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 Looks fine and trivial. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From per.liden at oracle.com Tue Jan 8 20:20:09 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 8 Jan 2019 21:20:09 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> Message-ID: Thanks Aleksey! /Per On 01/08/2019 09:17 PM, Aleksey Shipilev wrote: > On 1/8/19 9:14 PM, Per Liden wrote: >> Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced >> unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 >> Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 > > Looks fine and trivial. > > -Aleksey > From shade at redhat.com Tue Jan 8 20:22:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 21:22:00 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> Message-ID: One nit: util/macro.hpp should be included to gain access to COMPILER2, try without PCH? -Aleksey On 1/8/19 9:20 PM, Per Liden wrote: > Thanks Aleksey! > > /Per > > On 01/08/2019 09:17 PM, Aleksey Shipilev wrote: >> On 1/8/19 9:14 PM, Per Liden wrote: >>> Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced >>> unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 >>> Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 >> >> Looks fine and trivial. >> >> -Aleksey >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From erik.osterlund at oracle.com Tue Jan 8 20:21:04 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 8 Jan 2019 21:21:04 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> Message-ID: +1 /Erik > On 8 Jan 2019, at 21:14, Per Liden wrote: > > Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 > Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 > > /Per From per.liden at oracle.com Tue Jan 8 20:24:27 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 8 Jan 2019 21:24:27 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> Message-ID: Thanks Erik! Will push under the trivial rule once it has passed tier1. /Per On 01/08/2019 09:21 PM, Erik Osterlund wrote: > +1 > > /Erik > >> On 8 Jan 2019, at 21:14, Per Liden wrote: >> >> Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 >> Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 >> >> /Per > From per.liden at oracle.com Tue Jan 8 20:27:04 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 8 Jan 2019 21:27:04 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> Message-ID: <02797f85-0b3b-e900-af87-489c7faec2f9@oracle.com> Ah, good point. It works anyway, but I will add that. I never use PCH. Thanks! /Per On 01/08/2019 09:22 PM, Aleksey Shipilev wrote: > One nit: util/macro.hpp should be included to gain access to COMPILER2, try without PCH? > > -Aleksey > > On 1/8/19 9:20 PM, Per Liden wrote: >> Thanks Aleksey! >> >> /Per >> >> On 01/08/2019 09:17 PM, Aleksey Shipilev wrote: >>> On 1/8/19 9:14 PM, Per Liden wrote: >>>> Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced >>>> unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 >>> >>> Looks fine and trivial. >>> >>> -Aleksey >>> > > From boris.ulasevich at bell-sw.com Tue Jan 8 20:33:10 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 8 Jan 2019 23:33:10 +0300 Subject: RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder In-Reply-To: <015C401B-4272-4C8C-B9DD-3794B07CD47B@amazon.com> References: <3032b16a-1fe5-0381-c2b2-f6ec602ec269@bell-sw.com> <200b91e9-97f2-e8b2-4503-aeb943f75aad@oracle.com> <966f44c0-ae79-8920-fab5-5b0b3134190a@oracle.com> <47232924-ea7e-ea5a-73a9-10b00c02c59e@oracle.com> <9257C756-18C8-4342-91FA-C4CB920B500B@amazon.com> <40f6501b66db705703c5735360b5ed86f33553b6.camel@oracle.com> <36a48a60-de97-f77e-09e2-5cb0b16fd0dd@oracle.com> <015C401B-4272-4C8C-B9DD-3794B07CD47B@amazon.com> Message-ID: Thank you all! 08.01.2019 1:32, Hohensee, Paul ?????: > Then lgtm too. > > Thanks, > > Paul > > ?On 1/7/19, 5:24 AM, "Per Liden" wrote: > > On 1/7/19 11:01 AM, Thomas Schatzl wrote: > > Hi all, > > > > On Mon, 2018-12-31 at 15:26 +0000, Hohensee, Paul wrote: > >> Yes, please proceed with the fix to tlab_alloc_reserve(). The > >> original assert was doing its job of detecting a bug. > >> > >> You're correct, I was looking at > >> http://cr.openjdk.java.net/~bulasevich/8214235/webrev.01/. In that, > >> chunks less than min_fill_size() could be left unfilled. Unlikely, > >> but possible given a bug somewhere else. > >> > >> In http://cr.openjdk.java.net/~bulasevich/8214235/webrev.00/, if the > >> space available between top() and hard_end() is less than > >> min_fill_size(), fill_with_dummy_object() should assert. > >> > > > > The .00 patch is the correct and most space-efficient one. > > > > As described earlier, if the VM can always fit a minimum sized object > > in any remainder, we do not need a tlab alloc reserve (i.e. end == > > hard_end). > > > > The suggested change in CollectedHeap::tlab_alloc_reserve() would just > > waste some memory in these cases. > > I agree with what Thomas is saying here and also prefer the .00 patch. > > cheers, > Per > > > > > This is e.g. the case on 32 bit systems with ObjectAlignmentInBytes>=8 > > (the default) where the minimum instance size is 8 bytes, or on 64 bit > > systems with ObjectAlignmentInBytes>=16 where minimum object instance > > is 16 bytes. > > > > A better check instead of "top() < hard_end()" would be "top() != > > hard_end()" - as in this case, if Universe::fill_with_dummy_object() is > > still not able to fill in an object (it should if everything has been > > done correctly), it would assert for us. Basically in case objects are > > not aligned correctly. > > > > (I already tried to suggest something like that in > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-November/024092.html > > , but re-reading my answer it may not have been clear enough). > > > > Thanks, > > Thomas > > > > From shade at redhat.com Tue Jan 8 20:40:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 21:40:56 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: <02797f85-0b3b-e900-af87-489c7faec2f9@oracle.com> References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> <02797f85-0b3b-e900-af87-489c7faec2f9@oracle.com> Message-ID: Just built it with "--with-debug-level=fastdebug --disable-precompiled-headers --with-jvm-features=-compiler2", and it breaks: /home/shade/jdk-jdk/src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp:31:5: error: "COMPILER2" is not defined [-Werror=undef] #if COMPILER2 ^~~~~~~~~ It should be #ifdef, not #if... -Aleksey On 1/8/19 9:27 PM, Per Liden wrote: > Ah, good point. It works anyway, but I will add that. I never use PCH. > > Thanks! > /Per > > On 01/08/2019 09:22 PM, Aleksey Shipilev wrote: >> One nit: util/macro.hpp should be included to gain access to COMPILER2, try without PCH? >> >> -Aleksey >> >> On 1/8/19 9:20 PM, Per Liden wrote: >>> Thanks Aleksey! >>> >>> /Per >>> >>> On 01/08/2019 09:17 PM, Aleksey Shipilev wrote: >>>> On 1/8/19 9:14 PM, Per Liden wrote: >>>>> Building without C2 enabled (e.g. a client VM variant) fails after JDK-8215547, which introduced >>>>> unconditional uses of "MaxVectorSize", a symbol only available when C2 is enabled. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216385 >>>>> Webrev: http://cr.openjdk.java.net/~pliden/8216385/webrev.0 >>>> >>>> Looks fine and trivial. >>>> >>>> -Aleksey >>>> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Tue Jan 8 20:43:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 21:43:05 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> <02797f85-0b3b-e900-af87-489c7faec2f9@oracle.com> Message-ID: On 1/8/19 9:40 PM, Aleksey Shipilev wrote: > Just built it with "--with-debug-level=fastdebug --disable-precompiled-headers > --with-jvm-features=-compiler2", and it breaks: > > /home/shade/jdk-jdk/src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp:31:5: error: > "COMPILER2" is not defined [-Werror=undef] > #if COMPILER2 > ^~~~~~~~~ > > It should be #ifdef, not #if... ...and no need for additional #include, it seems to get there through build flags, not through utilities/macros.hpp. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From per.liden at oracle.com Tue Jan 8 21:01:48 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 8 Jan 2019 22:01:48 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> <02797f85-0b3b-e900-af87-489c7faec2f9@oracle.com> Message-ID: <3b5ece67-51fe-3033-e577-1192a5c0aa3f@oracle.com> On 01/08/2019 09:43 PM, Aleksey Shipilev wrote: > On 1/8/19 9:40 PM, Aleksey Shipilev wrote: >> Just built it with "--with-debug-level=fastdebug --disable-precompiled-headers >> --with-jvm-features=-compiler2", and it breaks: >> >> /home/shade/jdk-jdk/src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp:31:5: error: >> "COMPILER2" is not defined [-Werror=undef] >> #if COMPILER2 >> ^~~~~~~~~ >> >> It should be #ifdef, not #if... > > ...and no need for additional #include, it seems to get there through build flags, not through > utilities/macros.hpp. Doh! You're right of course. http://cr.openjdk.java.net/~pliden/8216385/webrev.1 /Per > > -Aleksey > From shade at redhat.com Tue Jan 8 21:28:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 22:28:38 +0100 Subject: RFR: 8216385: ZGC: Fix building without C2 In-Reply-To: <3b5ece67-51fe-3033-e577-1192a5c0aa3f@oracle.com> References: <508aa451-c337-330d-8675-011c4a2fbab3@oracle.com> <5cc29299-8034-45e4-e7a0-cbe2bd90be08@redhat.com> <02797f85-0b3b-e900-af87-489c7faec2f9@oracle.com> <3b5ece67-51fe-3033-e577-1192a5c0aa3f@oracle.com> Message-ID: <9322f68b-78e6-2fb2-041a-94718ab1968c@redhat.com> On 1/8/19 10:01 PM, Per Liden wrote: > http://cr.openjdk.java.net/~pliden/8216385/webrev.1 Yeah, this compiles fine with: *) "--with-debug-level=fastdebug --disable-precompiled-headers --with-jvm-features=-compiler2" *) "--with-debug-level=fastdebug --disable-precompiled-headers" -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From kim.barrett at oracle.com Wed Jan 9 01:25:37 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Jan 2019 20:25:37 -0500 Subject: RFR: 8216258: Make FreeIdSet semaphore-based In-Reply-To: References: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> Message-ID: > On Jan 8, 2019, at 9:21 AM, Thomas Schatzl wrote: > On Mon, 2019-01-07 at 19:58 -0500, Kim Barrett wrote: >> Please review this replacement of the "private" FreeIdSet with >> G1FreeIdSet, which has a new implementation using a semaphore rather >> than a monitor. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8216258 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8216258/open.00/ >> >> Testing: >> mach5 tier1-5. > > thanks for the cleanup. Thanks for looking at it. > Some notes: > > - is it possible to add a destructor that deletes the G1FreeIdSet > instance? I am aware that currently the destructor of DirtyCardQueueSet > is never called, but still it would be nice to clean up afterwards. I was going to say "but it's right there", but then realized what you were complaining about was the pre-existing lack of a delete of the freeidset by the non-existent ~DirtyCardQueueSet. > - not sure exactly why uintx is used for G1FreeIdSet::_head_index_mask > and _head: uintx are 32 bit on 32 bit machines, so the update counter > will be constrained by 32 bit - bits(size) there anyway. > > On 64 bit uintx is 64 bit, so the update counter does have the full 32 > bit range available, which is probably why uintx has been chosen > anyway? > > I do think that even on 32 bits the remaining range should be > sufficient so it seems okay. uintx is used as the type for _head (which affects others, like _head_index_mask) in order to maximize the size of the update counter. There's also a check that the size of that counter is not "too small", e.g. it must be at least BitsPerWord/2. Because the size is a thread count (and currently derived from the number of processors), the assumption is that on a 32bit platform it will be relatively small compared to a 32bit uintx, and on a 64bit platform it will be relatively small compared to a 64bit uintx (though possibly "largish" compared to a 32bit uint). > - maybe the cmpxchg loops in G1FreeIdSet::claim_par_id() and > release_par_id() could be factored out into a helper somehow. While the cmpxchg loops look structurally fairly similar (don't most CAS loops look more or less like this?), they really are pretty different in detail. I couldn't think of a way to produce a non-ugly, non-obfuscating, common helper. > - I would prefer if the "claimed" constant were camel cased like static > consts should be to make it more distinguishable to regular local > variables. Done. > - pre-existing: I have no idea what the documentation of G1FreeIdSet > "// Represents a set of free small integer ids" is supposed to mean. > Could you fix that comment for the G1FreeIdSet class please? Changed it to: // Represents a set of small integer ids, from which elements can be // temporarily allocated for exclusive use. The ids are in a // contiguous range from 'start' to 'start + size'. Used to obtain a // distinct worker_id value for a mutator thread that doesn't normally // have such an id. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8216258/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8216258/open.01.inc/ From goetz.lindenmaier at sap.com Wed Jan 9 08:04:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Jan 2019 08:04:08 +0000 Subject: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large In-Reply-To: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> Message-ID: Hi Thomas, all our test passed with your patch. But I found a similar issue: TestVerifyStackAfterDeopt.java says: MinTLABSize (1024) must be greater than or equal to reserved area in TLAB (1280) and the fix is: --- a/test/hotspot/jtreg/compiler/interpreter/TestVerifyStackAfterDeopt.java Mon Jan 07 15:49:31 2019 +0100 +++ b/test/hotspot/jtreg/compiler/interpreter/TestVerifyStackAfterDeopt.java Tue Jan 08 17:03:19 2019 +0100 @@ -28,6 +28,7 @@ * @bug 8209825 * @summary Checks VerifyStack after deoptimization of array allocation slow call * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:TieredStopAtLevel=1 + * -XX:AllocatePrefetchLines=1 -XX:AllocateInstancePrefetchLines=1 -XX:AllocatePrefetchStepSize=16 -XX:AllocatePrefetchDistance=1 * -XX:MinTLABSize=1k -XX:TLABSize=1k * -XX:+DeoptimizeALot -XX:+VerifyStack * compiler.interpreter.TestVerifyStackAfterDeopt Do you think this should be included in your fix right away? Else I would make an extra bug. Best regards, Goetz. > -----Original Message----- > From: Thomas Schatzl > Sent: Dienstag, 8. Januar 2019 13:42 > To: hotspot-gc-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RFR (XS): 8216316: > jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to > reserved TLAB area too large > > Hi all, > > can I have reviews for this fix to some test options to make the > TestPromotionEventWithG1 test more stable on the platforms we support? > > In particular, depending on hardware, the minimum TLAB size given in > the test was too small to accomodate the prefetching code C2 emits when > allocating objects. > > The fix is to minimize this buffer by twiddling with prefetching > amounts, and increasing the minimum tlab size a bit - so that the test > still fails with the patch for 8212766 not applied. > > Thanks go to Goetz from SAP who figured out the values for the > prefetching so that most supported systems worked. > > @Goeth: can you check this fix on your systems too? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8216316 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8216316/ > Testing: > Test failing test on various machines in our CI system > > Thanks, > Thomas > From thomas.schatzl at oracle.com Wed Jan 9 08:28:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Jan 2019 09:28:20 +0100 Subject: RFR: 8216258: Make FreeIdSet semaphore-based In-Reply-To: References: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> Message-ID: Hi Kim, On Tue, 2019-01-08 at 20:25 -0500, Kim Barrett wrote: > > On Jan 8, 2019, at 9:21 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > On Mon, 2019-01-07 at 19:58 -0500, Kim Barrett wrote: > > > Please review this replacement of the "private" FreeIdSet with > > > G1FreeIdSet, which has a new implementation using a semaphore > > > rather > > > than a monitor. > > > > > > [?] > > > CR: > > > https://bugs.openjdk.java.net/browse/JDK-8216258 > > > > > > Webrev: > > > http://cr.openjdk.java.net/~kbarrett/8216258/open.00/ > > > > > > Testing: > > > mach5 tier1-5. > > > > thanks for the cleanup. > > Thanks for looking at it. > > > Some notes: > > > > - is it possible to add a destructor that deletes the G1FreeIdSet > > instance? I am aware that currently the destructor of > > DirtyCardQueueSet > > is never called, but still it would be nice to clean up afterwards. > > I was going to say "but it's right there", but then realized what you > were complaining about was the pre-existing lack of a delete of the > freeidset by the non-existent ~DirtyCardQueueSet. Yes, sorry, this was a pre-existing issue. > > - not sure exactly why uintx is used for > > G1FreeIdSet::_head_index_mask and _head: uintx are 32 bit on 32 bit > > machines, so the update counter will be constrained by 32 bit - > > bits(size) there anyway. > > > > On 64 bit uintx is 64 bit, so the update counter does have the full > > 32 bit range available, which is probably why uintx has been chosen > > anyway? > > > > I do think that even on 32 bits the remaining range should be > > sufficient so it seems okay. > > uintx is used as the type for _head (which affects others, like > _head_index_mask) in order to maximize the size of the update > counter. There's also a check that the size of that counter is not > "too small", e.g. it must be at least BitsPerWord/2. > > Because the size is a thread count (and currently derived from the > number of processors), the assumption is that on a 32bit platform it > will be relatively small compared to a 32bit uintx, and on a 64bit > platform it will be relatively small compared to a 64bit uintx > (though possibly "largish" compared to a 32bit uint). I fully agree with that assessment. Just a comment. > > > - maybe the cmpxchg loops in G1FreeIdSet::claim_par_id() and > > release_par_id() could be factored out into a helper somehow. > > While the cmpxchg loops look structurally fairly similar (don't most > CAS loops look more or less like this?), they really are pretty > different in detail. I couldn't think of a way to produce a non-ugly, > non-obfuscating, common helper. > Okay, I know... > > - I would prefer if the "claimed" constant were camel cased like > > static consts should be to make it more distinguishable to regular > > local variables. > > Done. Thanks. > > > - pre-existing: I have no idea what the documentation of > > G1FreeIdSet "// Represents a set of free small integer ids" is > > supposed to mean. Could you fix that comment for the G1FreeIdSet > > class please? > > Changed it to: > > // Represents a set of small integer ids, from which elements can be > // temporarily allocated for exclusive use. The ids are in a > // contiguous range from 'start' to 'start + size'. Used to obtain a > // distinct worker_id value for a mutator thread that doesn't > // normally have such an id. Perfect. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8216258/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8216258/open.01.inc/ > > Looks good. Thomas From leo.korinth at oracle.com Wed Jan 9 09:31:30 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 9 Jan 2019 10:31:30 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: Message-ID: <17d793ff-6b54-586f-8551-fbcc98bf2a23@oracle.com> Hi! On 08/01/2019 19:48, Aleksey Shipilev wrote: > On 1/8/19 6:30 PM, Leo Korinth wrote: >> I guess you tried to use the already existing test (ArrayStoreExceptionTest.java) before you created >> the new test. What was the reason for not using it in the end? I would rather like that you tried to >> use the old test case, I believe it would improve overall testing and maintainability. > > I prefer to have a targeted test that would test check-casted arraycopy for interpreter, C1 and C2 > barrier sets, see the @run clauses there. It is in line with other Epsilon tests. It is also > specially crafted to work with Epsilon, e.g. it does not allocate all that much. I see, having the old test separate will give more head room for allocation heavy changes in the old, common test cases. I do agree; that is more important than common test code. > Plus it would run in tier1 without any additional testing options. ArrayStoreExceptionTest would > require running with TEST_VM_OPTS or such. > >> Also, there is a slight misleading comment on the #endif in barrierSet.inline.hpp, maybe instead use >> the style #endif // pragma once ;-) >> >> ? 24 #ifndef SHARE_VM_GC_SHARED_BARRIERSET_INLINE_HPP >> ? 25 #define SHARE_VM_GC_SHARED_BARRIERSET_INLINE_HPP >> ? 60 #endif // SHARE_VM_GC_SHARED_BARRIERSET_HPP > > I read the entire discussion about #pragma once (JDK-8216022), and it seems there is no consensus > yet about using it, and also there are reports that some compilers people use are not supporting it. > So, I fixed the comment instead. I hope Coleen has the script that does #pragma-once-ing, so it can > catch the new file! Thanks for updating the comment, I have not looked at Coleen's script, but I guess your change might help. > Updated webrev: > http://cr.openjdk.java.net/~shade/8215724/webrev.02/ > Looks good to me! Thanks, Leo > webrev.01 passed jdk-submit, and there are no code changes in webrev.02, only fixed comment. > > -Aleksey > From thomas.schatzl at oracle.com Wed Jan 9 11:43:59 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Jan 2019 12:43:59 +0100 Subject: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large In-Reply-To: References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> Message-ID: <6e27c0da2fd64e4a25ef94e6c5a258d010a2d1fe.camel@oracle.com> Hi Sangheon, On Tue, 2019-01-08 at 11:19 -0800, sangheon.kim at oracle.com wrote: > Hi Thomas, > > On 1/8/19 4:41 AM, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for this fix to some test options to make the > > TestPromotionEventWithG1 test more stable on the platforms we > > support? > > [...] > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8216316 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8216316/ > > Looks good. Thanks for your review. Thomas From thomas.schatzl at oracle.com Wed Jan 9 11:43:25 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Jan 2019 12:43:25 +0100 Subject: RFR (XS): 8216316: Tests fail due to too low specified TLAB size [Was: Re: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large] In-Reply-To: References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> Message-ID: <7047e8ff67f844d89e0bf3cfc851906fd35b4374.camel@oracle.com> Hi Goetz, On Wed, 2019-01-09 at 08:04 +0000, Lindenmaier, Goetz wrote: > Hi Thomas, > > all our test passed with your patch. > > But I found a similar issue: > TestVerifyStackAfterDeopt.java says: > MinTLABSize (1024) must be greater than or equal to reserved area in > TLAB (1280) > I added the fix to the test to this webrev. New webrev: http://cr.openjdk.java.net/~tschatzl/8216316/webrev.1/ Thanks, Thomas From goetz.lindenmaier at sap.com Wed Jan 9 11:49:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Jan 2019 11:49:17 +0000 Subject: RFR (XS): 8216316: Tests fail due to too low specified TLAB size [Was: Re: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large] In-Reply-To: <7047e8ff67f844d89e0bf3cfc851906fd35b4374.camel@oracle.com> References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> <7047e8ff67f844d89e0bf3cfc851906fd35b4374.camel@oracle.com> Message-ID: <1284361fac6a487c94a641a1c637ddd7@sap.com> Looks good, thanks for including this!! The G1 test needs the copyright adapted. Don't need a new webrev for this. Will you push this to 12 or 13? I see both bugs in 12, too. Best regards, Goetz. > -----Original Message----- > From: Thomas Schatzl > Sent: Mittwoch, 9. Januar 2019 12:43 > To: Lindenmaier, Goetz ; hotspot-gc- > dev at openjdk.java.net > Subject: Re: RFR (XS): 8216316: Tests fail due to too low specified TLAB size > [Was: Re: RFR (XS): 8216316: > jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to > reserved TLAB area too large] > > Hi Goetz, > > On Wed, 2019-01-09 at 08:04 +0000, Lindenmaier, Goetz wrote: > > Hi Thomas, > > > > all our test passed with your patch. > > > > But I found a similar issue: > > TestVerifyStackAfterDeopt.java says: > > MinTLABSize (1024) must be greater than or equal to reserved area in > > TLAB (1280) > > > > I added the fix to the test to this webrev. > > New webrev: > http://cr.openjdk.java.net/~tschatzl/8216316/webrev.1/ > > Thanks, > Thomas > From thomas.schatzl at oracle.com Wed Jan 9 12:02:14 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Jan 2019 13:02:14 +0100 Subject: RFR (XS): 8216316: Tests fail due to too low specified TLAB size [Was: Re: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large] In-Reply-To: <1284361fac6a487c94a641a1c637ddd7@sap.com> References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> <7047e8ff67f844d89e0bf3cfc851906fd35b4374.camel@oracle.com> <1284361fac6a487c94a641a1c637ddd7@sap.com> Message-ID: <025c5aceeacbf16181ff0d44933d3fadb6ed1f10.camel@oracle.com> Hi, On Wed, 2019-01-09 at 11:49 +0000, Lindenmaier, Goetz wrote: > Looks good, thanks for including this!! > > The G1 test needs the copyright adapted. Don't need a new webrev for > this. Updated in place. > > Will you push this to 12 or 13? I see both bugs in 12, too. I think this change will be pushed to 12 since these are just test fixes and we are only in rdp1, i.e. no particular approval required. Thanks, Thomas From goetz.lindenmaier at sap.com Wed Jan 9 12:52:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Jan 2019 12:52:28 +0000 Subject: RFR (XS): 8216316: Tests fail due to too low specified TLAB size [Was: Re: RFR (XS): 8216316: jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to reserved TLAB area too large] In-Reply-To: <025c5aceeacbf16181ff0d44933d3fadb6ed1f10.camel@oracle.com> References: <7fd7686b4eae170e24b57b683615e3bca0bcdb48.camel@oracle.com> <7047e8ff67f844d89e0bf3cfc851906fd35b4374.camel@oracle.com> <1284361fac6a487c94a641a1c637ddd7@sap.com> <025c5aceeacbf16181ff0d44933d3fadb6ed1f10.camel@oracle.com> Message-ID: <82db840770d744c0ae88d38a32614c57@sap.com> Yes, the change qualifies for jdk12. Best regards, Goetz. > -----Original Message----- > From: Thomas Schatzl > Sent: Mittwoch, 9. Januar 2019 13:02 > To: Lindenmaier, Goetz ; hotspot-gc- > dev at openjdk.java.net > Subject: Re: RFR (XS): 8216316: Tests fail due to too low specified TLAB size > [Was: Re: RFR (XS): 8216316: > jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java fails due to > reserved TLAB area too large] > > Hi, > > On Wed, 2019-01-09 at 11:49 +0000, Lindenmaier, Goetz wrote: > > Looks good, thanks for including this!! > > > > The G1 test needs the copyright adapted. Don't need a new webrev for > > this. > > Updated in place. > > > > > Will you push this to 12 or 13? I see both bugs in 12, too. > > I think this change will be pushed to 12 since these are just test > fixes and we are only in rdp1, i.e. no particular approval required. > > Thanks, > Thomas > From zgu at redhat.com Wed Jan 9 13:28:15 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 09 Jan 2019 08:28:15 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: <1546451358.3477.18.camel@redhat.com> References: <1546451358.3477.18.camel@redhat.com> Message-ID: <1547040495.3477.54.camel@redhat.com> Ping! Could I have reviews for this RFR? New webrev updated copyright year: http://cr.openjdk.java.net/~zgu/JDK-8215299/webrev.01/ It also passed submit tests. Thanks, -Zhengyu On Wed, 2019-01-02 at 12:49 -0500, zgu at redhat.com wrote: > TerminatorTerminator::should_exit_termination() might return true to > abort ongoing termination, due to external events. However, it should > not introduce side-effect that may conflict with termination result, > because the current termination may have completed, even > TerminatorTerminator::should_exit_termination() returns true. > > This undesirable side-effect is a blocker of JDK-8215047. With JDK- > 8215047, termination protocol should complete in one of two > consistent > state. The side-effect of setting abort flag in this particular case, > G1CMTask may re-enter termination protocol with completed terminator. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215299 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215299/webrev.00/ > > Test: > > hotspot_gc on Linux 64 (fastdebug and releas) > > Thanks, > > -Zhengyu From shade at redhat.com Wed Jan 9 15:09:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 9 Jan 2019 16:09:13 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: Message-ID: On 1/7/19 7:19 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215724 > > Fix: > http://cr.openjdk.java.net/~shade/8215724/webrev.01/ Ugh. I haven't noticed the bug has "Fix Version: 12", and I pushed the fix to jdk/jdk. Which created the "backport to 13". What should I do at this point? Should I also push the fix to jdk/jdk12 now? Would that cause duplicate bug ids when jdk/jdk12 -> jdk/jdk merge happens? Alternatively, I can wait for 12u to fork to jdk-updates/jdk12u and do the proper backport. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From erik.osterlund at oracle.com Wed Jan 9 15:51:00 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 9 Jan 2019 16:51:00 +0100 Subject: RFR: 8215754: ZGC: nmethod is not unlinked from Method before rendezvous handshake Message-ID: Hi, During concurrent class unloading in ZGC, the nmethod unloading goes through 3 phases: 1) Unlink all references to nmethods 2) Rendezvous handshake, to make sure all JavaThreads are in the new epoch where unlinking is done 3) Purge nmethods (by making them unloaded). However, we unfortunately unliked the code from the Method to the nmethod during #3 inside of the nmethod entry barrier instead of #1, causing JavaThreads to still observe these nmethods during phase #3, racing with make_unloaded(), and causing crashes in the nmethod entry barrier. The fix for this is to unlink the nmethod from the method during the first phase. I additionally eagerly unlink it in the nmethod barrier, to allow calls into unloading nmethods to not get stuck until the GC comes around to do it. Bug: https://bugs.openjdk.java.net/browse/JDK-8215754 Webrev: http://cr.openjdk.java.net/~eosterlund/8215754/webrev.00/ Thanks, /Erik From kim.barrett at oracle.com Wed Jan 9 16:20:42 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Jan 2019 11:20:42 -0500 Subject: RFR: 8216258: Make FreeIdSet semaphore-based In-Reply-To: References: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> Message-ID: <2FF76374-D568-4721-BA39-734AB94EDC30@oracle.com> > On Jan 9, 2019, at 3:28 AM, Thomas Schatzl wrote: >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8216258/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8216258/open.01.inc/ >> >> > > Looks good. > > Thomas Thanks. From hohensee at amazon.com Wed Jan 9 20:41:51 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 9 Jan 2019 20:41:51 +0000 Subject: RFR(S): 8215934: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <9CE87A68-7C22-4254-8D3F-4DA53A38D160@amazon.com> Thomas reviewed the CSR, so I?ve put it into Finalized state. Thanks Thomas. Please review the backport. Bug: https://bugs.openjdk.java.net/browse/JDK-8215934 Webrev: http://cr.openjdk.java.net/~phh/8215934/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Original webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.04/ Original review threads: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-February/021213.html https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Thanks, Paul From: hotspot-gc-dev on behalf of "Hohensee, Paul" Date: Thursday, December 27, 2018 at 10:23 AM To: "hotspot-gc-dev at openjdk.java.net" Subject: RFR(S): 8215935: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Hi, Please review CSR JDK-8215935. This is the CSR for JDK-8215934, which is the jdk8u backport issue for JDK-8195115, which latter was fixed in jdk11. The corresponding jdk11 CSR is JDK-8196719. Once/If approved, I?ll post a backport webrev for review. The backport is a bit different from the original patch. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Jan 9 21:48:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Jan 2019 16:48:35 -0500 Subject: RFR: 8212826: Make PtrQueue free list lock-free Message-ID: Please review this change to BufferNode::Allocator to eliminate the Mutex protecting the free-list, instead using a lock-free free-list. This eliminates the need for the (access rank) free list lock for the SATB and DirtyCard buffer allocator. Part of this change is the introduction of a LockFreeStack utility class template. This class doesn't attempt to solve the ABA problem, instead leaving that to the client. The Allocator uses GlobalCounter to solve the problem. (Other existing potential uses cases have separate phases for push and pop, don't recycle objects, or have other solutions.) Popping a buffer from the free list is done within a read critical section. A buffer is added to the free list only after an associated write synchronization is performed. Unfortunately, the API for LockFreeStack<> isn't quite what we would prefer. We would like this class's signature to be template class LockFreeStack; but it is instead template class LockFreeStack; This is due to a bug in Solaris Studio's handling of pointer to data member references within the class declaration (where the class is incomplete). (Visual Studio 2013 (not before or after) had a similar bug.) CR: https://bugs.openjdk.java.net/browse/JDK-8212826 Webrev: http://cr.openjdk.java.net/~kbarrett/8212826/open.00/ Testing: mach5 tier1-5. Performance testing found no significant difference. That's expected, since any previous contention on the buffer allocator free list lock will be closely associated with contention on the completed buffer list lock. (I'm looking at ways to do something about the latter.) However, on the new stress test, buffers cycle through more than twice as fast with the lock-free allocator than with a locking allocator. Note: This is a build breaking change for Shenandoah; its buffer allocator construction will need to be updated. From kim.barrett at oracle.com Wed Jan 9 22:09:05 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Jan 2019 17:09:05 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: <1547040495.3477.54.camel@redhat.com> References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> Message-ID: > On Jan 9, 2019, at 8:28 AM, zgu at redhat.com wrote: > > Ping! Could I have reviews for this RFR? > > New webrev updated copyright year: > http://cr.openjdk.java.net/~zgu/JDK-8215299/webrev.01/ > > It also passed submit tests. Looks good, but I?d like to see more testing of something this ?core?, especially a bit of stress testing. The submit tests are more at the level of ?smoke? tests. Given that most callers of regular_clock_call now conditionally call set_has_aborted, a helper function to encapsulate that might be nice. From suenaga.yasumasa at nttcom.co.jp Thu Jan 10 09:02:32 2019 From: suenaga.yasumasa at nttcom.co.jp (Yasumasa Suenaga) Date: Thu, 10 Jan 2019 18:02:32 +0900 Subject: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize Message-ID: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> Hi all, I'm Yasumasa Suenaga (OpenJDK reviewer: ysuenaga) My customer uses OpenJDK 8u131 with following commandline arguments: -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:CompressedClassSpaceSize=128m -Xms4500m -Xmx4500m -XX:MaxMetaspaceSize=256m -Xmn=768m -XX:MaxTenuringThreshold=15 -XX:OnOutOfMemoryError="/bin/kill -ABRT %p" -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC Their system has encountered OutOfMemoryError which is caused by Metaspace. I checked core image which was collected by OnOutOfMemoryError, and I saw strange values in it as below: ------------------- (gdb) p Metaspace::_space_list->_reserved_words $67 = 31195136 (gdb) p Metaspace::_class_space_list->_reserved_words $68 = 16777216 (gdb) p MetaspaceGC::_capacity_until_GC $75 = 448045056 ------------------- MaxMetaspaceSize and CompressedClassSpaceSize seem to affect Metaspace. However, MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize. Is it correct? I checked used and committed memory from the core, they seem to be enough to allocate new objects as below: ------------------- (gdb) p MetaspaceAux::_used_words $62 = {1742673, 17905981} (gdb) p Metaspace::_space_list->_committed_words $64 = 30932992 (gdb) p Metaspace::_class_space_list->_committed_words $65 = 2621440 ------------------- I guess the cause of OOME is invalid value in _capacity_until_GC. _capacity_until_GC is used for expanding / shrinking Metaspace. However it is not checked when it changes. So I think we need to add the code to check it as below: (The change is for jdk/jdk) ------------------- diff -r 32c6cc430526 src/hotspot/share/memory/metaspace.cpp --- a/src/hotspot/share/memory/metaspace.cpp Wed Jan 09 22:59:49 2019 +0100 +++ b/src/hotspot/share/memory/metaspace.cpp Thu Jan 10 17:56:55 2019 +0900 @@ -143,6 +143,10 @@ new_value = align_down(max_uintx, Metaspace::commit_alignment()); } + if (new_value > MaxMetaspaceSize) { + return false; + } + size_t prev_value = Atomic::cmpxchg(new_value, &_capacity_until_GC, old_capacity_until_GC); if (old_capacity_until_GC != prev_value) { ------------------- _capacity_until_GC is set to MaxMetaspaceSize at MetaspaceGC::initialize(), and it set to committed size or MetaspaceSize at MetaspaceGC::post_initialize(). So I guess max value of it is MaxMetaspaceSize. What do you think? If it is a bug, I will file JBS and send review request. Thanks, Yasumasa From leo.korinth at oracle.com Thu Jan 10 13:44:44 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 10 Jan 2019 14:44:44 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: References: Message-ID: <27da51af-2ef8-a547-fd9f-7f77c0149eb4@oracle.com> Hi Aleksey and Jesper, On 09/01/2019 16:09, Aleksey Shipilev wrote: > On 1/7/19 7:19 PM, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215724 >> >> Fix: >> http://cr.openjdk.java.net/~shade/8215724/webrev.01/ > > Ugh. I haven't noticed the bug has "Fix Version: 12", and I pushed the fix to jdk/jdk. Which created > the "backport to 13". What should I do at this point? Should I also push the fix to jdk/jdk12 now? > Would that cause duplicate bug ids when jdk/jdk12 -> jdk/jdk merge happens? I believe that when you checked in 8215724 on 13, the system thought you fixed 12. In the process it created a "backport" bug (8216425) to 13 (actually forward merge, bad naming), when the bug was created it could see that it was already fixed in 13, and the 8216425 was directly resolved. I hope my description is kind of right. I guess that if you apply the fix to 12, 8215724 will be resolved as well. I will CC this mail to Jesper so that he will not be surprised when doing the merge of bug fixes to 13. Also, Could you arrange so that the fix is incorporated into 11. Thanks, Leo > > Alternatively, I can wait for 12u to fork to jdk-updates/jdk12u and do the proper backport. > > -Aleksey > > From shade at redhat.com Thu Jan 10 14:00:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 10 Jan 2019 15:00:20 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: <27da51af-2ef8-a547-fd9f-7f77c0149eb4@oracle.com> References: <27da51af-2ef8-a547-fd9f-7f77c0149eb4@oracle.com> Message-ID: <07b09d95-9970-7eb1-86ce-8e2c556611e8@redhat.com> On 1/10/19 2:44 PM, Leo Korinth wrote: > Hi Aleksey and Jesper, > > On 09/01/2019 16:09, Aleksey Shipilev wrote: >> On 1/7/19 7:19 PM, Aleksey Shipilev wrote: >>> Bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8215724 >>> >>> Fix: >>> ?? http://cr.openjdk.java.net/~shade/8215724/webrev.01/ >> >> Ugh. I haven't noticed the bug has "Fix Version: 12", and I pushed the fix to jdk/jdk. Which created >> the "backport to 13". What should I do at this point? Should I also push the fix to jdk/jdk12 now? >> Would that cause duplicate bug ids when jdk/jdk12 -> jdk/jdk merge happens? > > I believe that when you checked in 8215724 on 13, the system thought you fixed 12. In the process it > created a "backport" bug (8216425) to 13 (actually forward merge, bad naming), when the bug was > created it could see that it was already fixed in 13, and the 8216425 was directly resolved. > > I hope my description is kind of right. I guess that if you apply the fix to 12, 8215724 will be > resolved as well. I will CC this mail to Jesper so that he will not be surprised when doing the > merge of bug fixes to 13. AFAIU, if I push the same thing to jdk/jdk12, then jdk/jdk would end up with two changesets that mention 8215724, which is what we are trying to avoid. I know jcheck has the exception list that allows duplicate bug ids, but I'd desist from duplicating bugids deliberately. Maybe waiting for jdk-updates/jdk12u to appear and do the normal backport is better all around, and it is not as painful with the faster release cadence. I think gatekeepers should decide what to do. Jesper? > Also, Could you arrange so that the fix is incorporated into 11. I would, it is on our list to backport. But we need to figure out jdk12 first. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From per.liden at oracle.com Thu Jan 10 13:59:14 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 10 Jan 2019 14:59:14 +0100 Subject: RFR: 8215754: ZGC: nmethod is not unlinked from Method before rendezvous handshake In-Reply-To: References: Message-ID: <5bb96fd5-c5d5-5424-10fe-105dcc989956@oracle.com> On 1/9/19 4:51 PM, Erik ?sterlund wrote: > Hi, > > During concurrent class unloading in ZGC, the nmethod unloading goes > through 3 phases: > > 1) Unlink all references to nmethods > 2) Rendezvous handshake, to make sure all JavaThreads are in the new > epoch where unlinking is done > 3) Purge nmethods (by making them unloaded). > > However, we unfortunately unliked the code from the Method to the > nmethod during #3 inside of the nmethod entry barrier instead of #1, > causing JavaThreads to still observe these nmethods during phase #3, > racing with make_unloaded(), and causing crashes in the nmethod entry > barrier. > > The fix for this is to unlink the nmethod from the method during the > first phase. I additionally eagerly unlink it in the nmethod barrier, to > allow calls into unloading nmethods to not get stuck until the GC comes > around to do it. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215754 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8215754/webrev.00/ Looks good! I also ran a slightly easier version of this patch, which had the same effect, through tier{1-7} without seeing any issues. /Per > > Thanks, > /Erik From erik.osterlund at oracle.com Thu Jan 10 14:35:50 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 10 Jan 2019 15:35:50 +0100 Subject: RFR: 8215754: ZGC: nmethod is not unlinked from Method before rendezvous handshake In-Reply-To: <5bb96fd5-c5d5-5424-10fe-105dcc989956@oracle.com> References: <5bb96fd5-c5d5-5424-10fe-105dcc989956@oracle.com> Message-ID: <08b4e17a-4d88-b64d-6105-061fa4646159@oracle.com> Hi Per, Thanks for the review. /Erik On 2019-01-10 14:59, Per Liden wrote: > On 1/9/19 4:51 PM, Erik ?sterlund wrote: >> Hi, >> >> During concurrent class unloading in ZGC, the nmethod unloading goes >> through 3 phases: >> >> 1) Unlink all references to nmethods >> 2) Rendezvous handshake, to make sure all JavaThreads are in the new >> epoch where unlinking is done >> 3) Purge nmethods (by making them unloaded). >> >> However, we unfortunately unliked the code from the Method to the >> nmethod during #3 inside of the nmethod entry barrier instead of #1, >> causing JavaThreads to still observe these nmethods during phase #3, >> racing with make_unloaded(), and causing crashes in the nmethod entry >> barrier. >> >> The fix for this is to unlink the nmethod from the method during the >> first phase. I additionally eagerly unlink it in the nmethod barrier, >> to allow calls into unloading nmethods to not get stuck until the GC >> comes around to do it. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215754 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8215754/webrev.00/ > > Looks good! > > I also ran a slightly easier version of this patch, which had the same > effect, through tier{1-7} without seeing any issues. > > /Per > >> >> Thanks, >> /Erik From jesper.wilhelmsson at oracle.com Thu Jan 10 15:14:14 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 10 Jan 2019 16:14:14 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: <07b09d95-9970-7eb1-86ce-8e2c556611e8@redhat.com> References: <27da51af-2ef8-a547-fd9f-7f77c0149eb4@oracle.com> <07b09d95-9970-7eb1-86ce-8e2c556611e8@redhat.com> Message-ID: <7906BD92-E3BE-4A48-BAEE-AC0870A0EA6B@oracle.com> > On 10 Jan 2019, at 15:00, Aleksey Shipilev wrote: > > On 1/10/19 2:44 PM, Leo Korinth wrote: >> Hi Aleksey and Jesper, >> >> On 09/01/2019 16:09, Aleksey Shipilev wrote: >>> On 1/7/19 7:19 PM, Aleksey Shipilev wrote: >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8215724 >>>> >>>> Fix: >>>> http://cr.openjdk.java.net/~shade/8215724/webrev.01/ >>> >>> Ugh. I haven't noticed the bug has "Fix Version: 12", and I pushed the fix to jdk/jdk. Which created >>> the "backport to 13". What should I do at this point? Should I also push the fix to jdk/jdk12 now? >>> Would that cause duplicate bug ids when jdk/jdk12 -> jdk/jdk merge happens? >> >> I believe that when you checked in 8215724 on 13, the system thought you fixed 12. In the process it >> created a "backport" bug (8216425) to 13 (actually forward merge, bad naming), when the bug was >> created it could see that it was already fixed in 13, and the 8216425 was directly resolved. >> >> I hope my description is kind of right. I guess that if you apply the fix to 12, 8215724 will be >> resolved as well. I will CC this mail to Jesper so that he will not be surprised when doing the >> merge of bug fixes to 13. > > AFAIU, if I push the same thing to jdk/jdk12, then jdk/jdk would end up with two changesets that > mention 8215724, which is what we are trying to avoid. I know jcheck has the exception list that > allows duplicate bug ids, but I'd desist from duplicating bugids deliberately. Maybe waiting for > jdk-updates/jdk12u to appear and do the normal backport is better all around, and it is not as > painful with the faster release cadence. > > I think gatekeepers should decide what to do. Jesper? Duplicate changes with the same bug id is no longer an issue. You can (and should) safely push the fix to 12 as well. /Jesper > >> Also, Could you arrange so that the fix is incorporated into 11. > > I would, it is on our list to backport. But we need to figure out jdk12 first. > > -Aleksey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From shade at redhat.com Thu Jan 10 15:25:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 10 Jan 2019 16:25:11 +0100 Subject: RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check In-Reply-To: <7906BD92-E3BE-4A48-BAEE-AC0870A0EA6B@oracle.com> References: <27da51af-2ef8-a547-fd9f-7f77c0149eb4@oracle.com> <07b09d95-9970-7eb1-86ce-8e2c556611e8@redhat.com> <7906BD92-E3BE-4A48-BAEE-AC0870A0EA6B@oracle.com> Message-ID: On 1/10/19 4:14 PM, jesper.wilhelmsson at oracle.com wrote: >>>> Ugh. I haven't noticed the bug has "Fix Version: 12", and I pushed the fix to jdk/jdk. Which created >>>> the "backport to 13". What should I do at this point? Should I also push the fix to jdk/jdk12 now? >>>> Would that cause duplicate bug ids when jdk/jdk12 -> jdk/jdk merge happens? >>> >>> I believe that when you checked in 8215724 on 13, the system thought you fixed 12. In the process it >>> created a "backport" bug (8216425) to 13 (actually forward merge, bad naming), when the bug was >>> created it could see that it was already fixed in 13, and the 8216425 was directly resolved. >>> >>> I hope my description is kind of right. I guess that if you apply the fix to 12, 8215724 will be >>> resolved as well. I will CC this mail to Jesper so that he will not be surprised when doing the >>> merge of bug fixes to 13. >> >> AFAIU, if I push the same thing to jdk/jdk12, then jdk/jdk would end up with two changesets that >> mention 8215724, which is what we are trying to avoid. I know jcheck has the exception list that >> allows duplicate bug ids, but I'd desist from duplicating bugids deliberately. Maybe waiting for >> jdk-updates/jdk12u to appear and do the normal backport is better all around, and it is not as >> painful with the faster release cadence. >> >> I think gatekeepers should decide what to do. Jesper? > > Duplicate changes with the same bug id is no longer an issue. You can (and should) safely push the > fix to 12 as well. Good to know! Let me test and push the fix to jdk/jdk12 too then. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Thu Jan 10 17:22:50 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 10 Jan 2019 12:22:50 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> Message-ID: <1547140970.13989.6.camel@redhat.com> Hi Kim, Thanks for the review. Please see updated webrev based on your suggestion: http://cr.openjdk.java.net/~zgu/JDK-8215299/webrev.03/index.html > Looks good, but I?d like to see more testing of something this > ?core?, especially a bit of stress testing. > The submit tests are more at the level of ?smoke? tests. Besides submit tests, I also ran hotspot_gc tests on Linux 64, which contains stress tests. This cycle, I also ran vmTestbase_vm_gc tests on Linux 64. Thanks, -Zhengyu > > Given that most callers of regular_clock_call now conditionally call > set_has_aborted, a helper function to encapsulate that might be nice. > From per.liden at oracle.com Thu Jan 10 18:49:55 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 10 Jan 2019 19:49:55 +0100 Subject: RFR: 8215754: ZGC: nmethod is not unlinked from Method before rendezvous handshake In-Reply-To: <5bb96fd5-c5d5-5424-10fe-105dcc989956@oracle.com> References: <5bb96fd5-c5d5-5424-10fe-105dcc989956@oracle.com> Message-ID: <0de5eafd-0ce7-a3df-25d5-748f222abca8@oracle.com> On 01/10/2019 02:59 PM, Per Liden wrote: > On 1/9/19 4:51 PM, Erik ?sterlund wrote: >> Hi, >> >> During concurrent class unloading in ZGC, the nmethod unloading goes >> through 3 phases: >> >> 1) Unlink all references to nmethods >> 2) Rendezvous handshake, to make sure all JavaThreads are in the new >> epoch where unlinking is done >> 3) Purge nmethods (by making them unloaded). >> >> However, we unfortunately unliked the code from the Method to the >> nmethod during #3 inside of the nmethod entry barrier instead of #1, >> causing JavaThreads to still observe these nmethods during phase #3, >> racing with make_unloaded(), and causing crashes in the nmethod entry >> barrier. >> >> The fix for this is to unlink the nmethod from the method during the >> first phase. I additionally eagerly unlink it in the nmethod barrier, >> to allow calls into unloading nmethods to not get stuck until the GC >> comes around to do it. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215754 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8215754/webrev.00/ > > Looks good! > > I also ran a slightly easier version of this patch, which had the same > effect, through tier{1-7} without seeing any issues. s/easier/earlier/ > > /Per > >> >> Thanks, >> /Erik From thomas.schatzl at oracle.com Thu Jan 10 20:46:27 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 10 Jan 2019 21:46:27 +0100 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections Message-ID: Hi all, please review this change that moves string table processing in all collectors that use the WeakProcessor (all but ZGC and Epsilon) into the WeakProcessor. This means that string table entries will be treated as weak in young collections always for all these collectors. This is kind of inevitable as the StringTable contents are now handled the same as other weak references processed there. Overall it's mostly removing code, which is nice :) Notes: - the original code had some test that checked some log message that printed how many string table entries were processed/cleaned out during string table processing. This test has been removed (TestStringTableStats.java). I filed a CR to add some facility in the WeakProcessor to be able to get more information from the various sources of weak references as it would be nice to have statistics on them too (JDK-8215709). - I modified the Shenandoah code to compile, and it seem to work. While at it I noticed that Shenandoah deduplicates strings twice for some reason (JDK-8215549) even before this change. I left it as is. - I also just noticed that the copyright notices for all touched files need updating, I will do that in place later... CR: https://bugs.openjdk.java.net/browse/JDK-8213229 Webrev: http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ Testing: hs-tier1-6, performance checking with our performance suite showed no particular performance differences before/after Thanks, Thomas From nils.eliasson at oracle.com Fri Jan 11 12:59:23 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 11 Jan 2019 13:59:23 +0100 Subject: RFR: 8215754: ZGC: nmethod is not unlinked from Method before rendezvous handshake In-Reply-To: References: Message-ID: <64dcb4cb-5df6-c16a-eed2-3f8107f0f627@oracle.com> Looks great! // Nils On 2019-01-09 16:51, Erik ?sterlund wrote: > Hi, > > During concurrent class unloading in ZGC, the nmethod unloading goes > through 3 phases: > > 1) Unlink all references to nmethods > 2) Rendezvous handshake, to make sure all JavaThreads are in the new > epoch where unlinking is done > 3) Purge nmethods (by making them unloaded). > > However, we unfortunately unliked the code from the Method to the > nmethod during #3 inside of the nmethod entry barrier instead of #1, > causing JavaThreads to still observe these nmethods during phase #3, > racing with make_unloaded(), and causing crashes in the nmethod entry > barrier. > > The fix for this is to unlink the nmethod from the method during the > first phase. I additionally eagerly unlink it in the nmethod barrier, > to allow calls into unloading nmethods to not get stuck until the GC > comes around to do it. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215754 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8215754/webrev.00/ > > Thanks, > /Erik From erik.osterlund at oracle.com Fri Jan 11 13:10:45 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 11 Jan 2019 14:10:45 +0100 Subject: RFR: 8215754: ZGC: nmethod is not unlinked from Method before rendezvous handshake In-Reply-To: <64dcb4cb-5df6-c16a-eed2-3f8107f0f627@oracle.com> References: <64dcb4cb-5df6-c16a-eed2-3f8107f0f627@oracle.com> Message-ID: <0eed784e-4dfd-9abd-b626-87897ca8b1d3@oracle.com> Hi Nils, Thanks for the review! /Erik On 2019-01-11 13:59, Nils Eliasson wrote: > Looks great! > > // Nils > > On 2019-01-09 16:51, Erik ?sterlund wrote: >> Hi, >> >> During concurrent class unloading in ZGC, the nmethod unloading goes >> through 3 phases: >> >> 1) Unlink all references to nmethods >> 2) Rendezvous handshake, to make sure all JavaThreads are in the new >> epoch where unlinking is done >> 3) Purge nmethods (by making them unloaded). >> >> However, we unfortunately unliked the code from the Method to the >> nmethod during #3 inside of the nmethod entry barrier instead of #1, >> causing JavaThreads to still observe these nmethods during phase #3, >> racing with make_unloaded(), and causing crashes in the nmethod entry >> barrier. >> >> The fix for this is to unlink the nmethod from the method during the >> first phase. I additionally eagerly unlink it in the nmethod barrier, >> to allow calls into unloading nmethods to not get stuck until the GC >> comes around to do it. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215754 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8215754/webrev.00/ >> >> Thanks, >> /Erik From thomas.schatzl at oracle.com Fri Jan 11 14:14:36 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 11 Jan 2019 15:14:36 +0100 Subject: RFR (S): 8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled Message-ID: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> Hi all, can I have reviews for this small change that fixes somewhat spammy log messages for the periodic garbage collections feature if it is *disabled*? So at the moment, if you somehow enable gc+periodic debug level log messages (e.g. via gc*=debug), you will get a message that the current periodic gc is being skipped because of the wrong reason basically, also containing some random number due to an uninitialized variable. This change fixes that by: - at the start of the VM g1 will now print whether periodic gcs are enabled or disabled (with the selected interval if enabled) once - only if enabled, the periodic gc checking log messages are printed as usual, and without the problem with the uninitialized variable. CR: https://bugs.openjdk.java.net/browse/JDK-8216490 Webrev: http://cr.openjdk.java.net/~tschatzl/8216490/webrev/ Testing: new test Thanks, Thomas From leo.korinth at oracle.com Fri Jan 11 16:54:48 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 11 Jan 2019 17:54:48 +0100 Subject: RFR: 8214799: Add package declaration to each JTREG test case in the gc folder In-Reply-To: <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> References: <19bae948-ec2b-257e-d0fc-69ff95093642@oracle.com> <3899785E-F88A-4F4B-8DE7-9002F7835AD3@oracle.com> <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> Message-ID: <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> Hi again! New webrev, no incremental this time either as I have changed all copyright years, all library annotations, and several new tests have been rebased. Changes since last time: 1) The bad rebase artifact (bad rebase of moved file) CriticalNativeStress.java is now removed. I still left the small refactoring to a Java JNI "mirror" class as I think it is nicer than the old solution with several Java files in different packages mapping to the same JNI file. 2) All relative @library lines now uses the absolute "/" that will improve future refactoring. I still have them on separate lines if several paths are used -- my reason is that they diff better. 3) All new test cases in the new directory nvdimm have been fixed 4) A new test in directory epsilon has been fixed 5) All (Oracle) copyright years have been updated to 2019, I did not bother to add Oracle copyrights to the Epsilon/Shenandoah sources as my contribution is insignificant. 6) Shenandoah has landed, but I will not update all those test cases, I made this webrev too large already. I have tried to update all Shenandoah test cases that are located outside the shenendoah folder though. (New) Webrev: http://cr.openjdk.java.net/~lkorinth/8214799/02/ Testing: open/test/hotspot/jtreg/:hotspot_gc Thanks, Leo On 22/12/2018 12:10, Leo Korinth wrote: > Hi! > > On 21/12/2018 21:50, Leonid Mesnik wrote: >> Hi >> >> Great change. The only a couple of comments >> >> 1) I see that you added a lot of relative links to include test-root >> as library like: >> >> 32? * @library ../../.. >> >> >> I think you might want to use >> ??@library? > or add to existing library test/lib like >> @library /test/lib / >> >> instead. You might find a lot of examples in existing compiler and gc >> tests. >> >> It is the more common an unified approach ?rather then using relative >> paths. Also it allows you to don't care when you move tests in >> different packages. >> > I will try that, it is certainly better. I think I will use a new > @library line though, it is easier to see the change. >> >> 2) New test in >> http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.new.java.html >> >> looks confusing to me. It is copied from >> http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/stress/CriticalNativeStress.new.java.html >> >> >> So now we have test CriticalNativeStress >> gc/epsilon/CriticalNativeStress.java and CriticalNativeStressEpsilon >> in gc/stress/CriticalNativeStress.java >> The code in both files and jtreg tags looks pretty similar. Have you >> added it intentionally? Could you please explain a little bit purpose >> of this. > > Many thanks for finding this fault of mine. The file was moved with the > Shenandoah push, and I must have rebased it badly although the move of > the corresponding c-file went through, strange... > >> Other changes looks good. >> > > Thanks for taking a look at it! > I will create a new webrev after the holiday. > > /Leo > >> Leonid > > >>> On Dec 21, 2018, at 11:32 AM, Leo Korinth >> > wrote: >>> >>> Hi again! >>> >>> I am adding Leonid and Erik to the discussion to see if my package >>> additions are in any way troublesome to the bigger picture. I believe >>> they are not. We are already using Java packages in some tests; this >>> change will just add them to more tests so that one can easily use an >>> IDE. >>> >>> Please ignore the old webrev as I had to rebase against the resent >>> Shenandoah push. It is easier to just read this version >>> (http://cr.openjdk.java.net/~lkorinth/8214799/01/). Unfortunately no >>> incremental version is given as this is a rebase. >>> >>> I have not had the time to update the test cases under the >>> gc/shenandoah folder (I am also afraid to make this change any >>> bigger), but I have tried to update the test cases that changed or >>> was added by the Shenandoah push (some Epsilon and Shenandoah tests >>> outside the gc/shenandoah folder). >>> >>> This rebase basically applies the same kind of changes to the added >>> test cases. One change that I would like you to look more carefully >>> at is the addition of a helper class CriticalNative.java that uses >>> JNI. Without this refactoring I could not have used the same c-file >>> as it was used in different packages (it is used from three different >>> test cases, and the package is part of the JNI export name). Please >>> take an extra look at that change. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~lkorinth/8214799/01/ >>> >>> Testing: >>> I have run jtreg tests under gc/epsilon and I have run :hotspot_gc >>> with Shenandoah in order not to break those test cases. >>> >>> Also started new run of tier1-3 and :hotspot_gc >>> >>> Thanks, >>> Leo >>> >>> On 05/12/2018 14:44, Leo Korinth wrote: >>>> Hi, >>>> I have added package declarations to all jtreg tests in the gc >>>> folder (and sub folders). Previously most tests were not in a >>>> package (though some where), making it extremely hard to work with >>>> jtreg tests in an IDE. >>>> The main change consists of adding a package declaration that >>>> corresponds to the directory the test is located in. This also makes >>>> it necessary to change @run annotations. Some test cases uses >>>> "common" code that is not located in the test lib. Those test cases >>>> now need to have a @library annotation that references the jtreg >>>> test root. >>>> A few test cases had package visible classes with the same name in >>>> the same directory. That did work before, but does not work anymore, >>>> so I have prefixed those package visible classes with the public >>>> class name. >>>> class TestVerifySilentlyRunSystemGC >>>> class TestVerifySubSetRunSystemGC >>>> class TestEagerReclaimHumongousRegionsReclaimRegionFast >>>> class TestEagerReclaimHumongousRegionsClearMarkBitsReclaimRegionFast >>>> class TestEagerReclaimHumongousRegionsWithRefsReclaimRegionFast >>>> Where classes have been referenced using string literals, I have >>>> tried to use a .class.getName() instead (where possible). >>>> I have tried to update copyrights to all files (also adding a >>>> missing comma after the second year in some files), and I did add >>>> missing copyright to TestFromCardCacheIndex. >>>> known cons: >>>> - needs a package line in each java file >>>> - needs an extra library line in the test if the test is using other >>>> files. >>>> - sometimes needs a run tag >>>> improvements: >>>> + can use eclipse or other IDEs without creating a workspace per >>>> test (I guess it will be a significant improvement for users of >>>> emacs and vi as well) >>>> + can use test files located in other directories >>>> After this change, I have several big cleanups that are easy to do >>>> with a working IDE. >>>> Enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8214799 >>>> Webrev: >>>> http://cr.openjdk.java.net/~lkorinth/8214799/00/ >>>> Testing: >>>> passed: >>>> mach5 remote-build-and-test --build-profiles >>>> linux-x64,linux-x64-debug,macosx-x64,solaris-sparcv9,windows-x64 >>>> --test open/test/hotspot/jtreg/:hotspot_gc >>>> now running: >>>> mach5 remote-test --build-id 2018-12-05-1132377.leo.korinth.hs >>>> --build-profiles linux-x64-debug -j tier1,tier2,tier3 >>>> Thanks, >>>> Leo >> From leonid.mesnik at oracle.com Fri Jan 11 17:30:17 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 11 Jan 2019 09:30:17 -0800 Subject: RFR: 8214799: Add package declaration to each JTREG test case in the gc folder In-Reply-To: <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> References: <19bae948-ec2b-257e-d0fc-69ff95093642@oracle.com> <3899785E-F88A-4F4B-8DE7-9002F7835AD3@oracle.com> <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> Message-ID: <2A5A69F0-0995-4E95-8EA9-2F90A4BD5A37@oracle.com> Hi The changes look good to me. Thanks for fixing all this. Please note that I am not a 'R'eviewer. Leonid > On Jan 11, 2019, at 8:54 AM, Leo Korinth wrote: > > Hi again! > > New webrev, no incremental this time either as I have changed all copyright years, all library annotations, and several new tests have been rebased. > > Changes since last time: > 1) The bad rebase artifact (bad rebase of moved file) CriticalNativeStress.java is now removed. I still left the small refactoring to a Java JNI "mirror" class as I think it is nicer than the old solution with several Java files in different packages mapping to the same JNI file. > 2) All relative @library lines now uses the absolute "/" that will improve future refactoring. I still have them on separate lines if several paths are used -- my reason is that they diff better. > 3) All new test cases in the new directory nvdimm have been fixed > 4) A new test in directory epsilon has been fixed > 5) All (Oracle) copyright years have been updated to 2019, I did not bother to add Oracle copyrights to the Epsilon/Shenandoah sources as my contribution is insignificant. > 6) Shenandoah has landed, but I will not update all those test cases, I made this webrev too large already. I have tried to update all Shenandoah test cases that are located outside the shenendoah folder though. > > (New) Webrev: > http://cr.openjdk.java.net/~lkorinth/8214799/02/ > > Testing: > open/test/hotspot/jtreg/:hotspot_gc > > Thanks, > Leo > > > On 22/12/2018 12:10, Leo Korinth wrote: >> Hi! >> On 21/12/2018 21:50, Leonid Mesnik wrote: >>> Hi >>> >>> Great change. The only a couple of comments >>> >>> 1) I see that you added a lot of relative links to include test-root as library like: >>> >>> 32 * @library ../../.. >>> >>> >>> I think you might want to use >>> @library > or add to existing library test/lib like >>> @library /test/lib / >>> >>> instead. You might find a lot of examples in existing compiler and gc tests. >>> >>> It is the more common an unified approach rather then using relative paths. Also it allows you to don't care when you move tests in different packages. >>> >> I will try that, it is certainly better. I think I will use a new @library line though, it is easier to see the change. >>> >>> 2) New test in http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.new.java.html >>> looks confusing to me. It is copied from http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/stress/CriticalNativeStress.new.java.html >>> >>> So now we have test CriticalNativeStress gc/epsilon/CriticalNativeStress.java and CriticalNativeStressEpsilon in gc/stress/CriticalNativeStress.java >>> The code in both files and jtreg tags looks pretty similar. Have you added it intentionally? Could you please explain a little bit purpose of this. >> Many thanks for finding this fault of mine. The file was moved with the Shenandoah push, and I must have rebased it badly although the move of the corresponding c-file went through, strange... >>> Other changes looks good. >>> >> Thanks for taking a look at it! >> I will create a new webrev after the holiday. >> /Leo >>> Leonid >>>> On Dec 21, 2018, at 11:32 AM, Leo Korinth >>> > wrote: >>>> >>>> Hi again! >>>> >>>> I am adding Leonid and Erik to the discussion to see if my package additions are in any way troublesome to the bigger picture. I believe they are not. We are already using Java packages in some tests; this change will just add them to more tests so that one can easily use an IDE. >>>> >>>> Please ignore the old webrev as I had to rebase against the resent Shenandoah push. It is easier to just read this version (http://cr.openjdk.java.net/~lkorinth/8214799/01/). Unfortunately no incremental version is given as this is a rebase. >>>> >>>> I have not had the time to update the test cases under the gc/shenandoah folder (I am also afraid to make this change any bigger), but I have tried to update the test cases that changed or was added by the Shenandoah push (some Epsilon and Shenandoah tests outside the gc/shenandoah folder). >>>> >>>> This rebase basically applies the same kind of changes to the added test cases. One change that I would like you to look more carefully at is the addition of a helper class CriticalNative.java that uses JNI. Without this refactoring I could not have used the same c-file as it was used in different packages (it is used from three different test cases, and the package is part of the JNI export name). Please take an extra look at that change. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~lkorinth/8214799/01/ >>>> >>>> Testing: >>>> I have run jtreg tests under gc/epsilon and I have run :hotspot_gc with Shenandoah in order not to break those test cases. >>>> >>>> Also started new run of tier1-3 and :hotspot_gc >>>> >>>> Thanks, >>>> Leo >>>> >>>> On 05/12/2018 14:44, Leo Korinth wrote: >>>>> Hi, >>>>> I have added package declarations to all jtreg tests in the gc folder (and sub folders). Previously most tests were not in a package (though some where), making it extremely hard to work with jtreg tests in an IDE. >>>>> The main change consists of adding a package declaration that corresponds to the directory the test is located in. This also makes it necessary to change @run annotations. Some test cases uses "common" code that is not located in the test lib. Those test cases now need to have a @library annotation that references the jtreg test root. >>>>> A few test cases had package visible classes with the same name in the same directory. That did work before, but does not work anymore, so I have prefixed those package visible classes with the public class name. >>>>> class TestVerifySilentlyRunSystemGC >>>>> class TestVerifySubSetRunSystemGC >>>>> class TestEagerReclaimHumongousRegionsReclaimRegionFast >>>>> class TestEagerReclaimHumongousRegionsClearMarkBitsReclaimRegionFast >>>>> class TestEagerReclaimHumongousRegionsWithRefsReclaimRegionFast >>>>> Where classes have been referenced using string literals, I have tried to use a .class.getName() instead (where possible). >>>>> I have tried to update copyrights to all files (also adding a missing comma after the second year in some files), and I did add missing copyright to TestFromCardCacheIndex. >>>>> known cons: >>>>> - needs a package line in each java file >>>>> - needs an extra library line in the test if the test is using other files. >>>>> - sometimes needs a run tag >>>>> improvements: >>>>> + can use eclipse or other IDEs without creating a workspace per test (I guess it will be a significant improvement for users of emacs and vi as well) >>>>> + can use test files located in other directories >>>>> After this change, I have several big cleanups that are easy to do with a working IDE. >>>>> Enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8214799 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~lkorinth/8214799/00/ >>>>> Testing: >>>>> passed: >>>>> mach5 remote-build-and-test --build-profiles linux-x64,linux-x64-debug,macosx-x64,solaris-sparcv9,windows-x64 --test open/test/hotspot/jtreg/:hotspot_gc >>>>> now running: >>>>> mach5 remote-test --build-id 2018-12-05-1132377.leo.korinth.hs --build-profiles linux-x64-debug -j tier1,tier2,tier3 >>>>> Thanks, >>>>> Leo >>> From sangheon.kim at oracle.com Fri Jan 11 19:18:38 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Fri, 11 Jan 2019 11:18:38 -0800 Subject: RFR (S): 8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled In-Reply-To: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> References: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> Message-ID: Hi Thomas, On 1/11/19 6:14 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change that fixes somewhat spammy > log messages for the periodic garbage collections feature if it is > *disabled*? > > So at the moment, if you somehow enable gc+periodic debug level log > messages (e.g. via gc*=debug), you will get a message that the current > periodic gc is being skipped because of the wrong reason basically, > also containing some random number due to an uninitialized variable. > > This change fixes that by: > > - at the start of the VM g1 will now print whether periodic gcs are > enabled or disabled (with the selected interval if enabled) once > - only if enabled, the periodic gc checking log messages are printed as > usual, and without the problem with the uninitialized variable. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8216490 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8216490/webrev/ Looks good. Thanks, Sangheon > Testing: > new test > > Thanks, > Thomas > From zgu at redhat.com Fri Jan 11 20:31:36 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 11 Jan 2019 15:31:36 -0500 Subject: RFR 8215549: Shenandoah deduplication cleans up table/queue twice Message-ID: <1547238696.13989.23.camel@redhat.com> Shenandoah string deduplication cleans up deduplication table and queues twice, once via ParallelCleaningTask and then ShenandoahStringDedup::parallel_cleanup(). The second cleanup should be removed after we adopted upstream deduplication implementation. Bug: https://bugs.openjdk.java.net/browse/JDK-8215549 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215549/webrev.00/ Test: tier1,2,3 gc_shenandoah on Linux 64 (fastdebug and release) Thanks, -Zhengyu From rkennke at redhat.com Fri Jan 11 20:41:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 11 Jan 2019 21:41:13 +0100 Subject: RFR 8215549: Shenandoah deduplication cleans up table/queue twice In-Reply-To: <1547238696.13989.23.camel@redhat.com> References: <1547238696.13989.23.camel@redhat.com> Message-ID: Hi Zhengyu, this looks good to me. Thanks, Roman > Shenandoah string deduplication cleans up deduplication table and > queues twice, once via ParallelCleaningTask and then > ShenandoahStringDedup::parallel_cleanup(). The second cleanup should be > removed after we adopted upstream deduplication implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215549 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215549/webrev.00/ > > Test: > > tier1,2,3 gc_shenandoah on Linux 64 (fastdebug and release) > > > Thanks, > > -Zhengyu > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Fri Jan 11 20:43:02 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 11 Jan 2019 15:43:02 -0500 Subject: RFR 8215549: Shenandoah deduplication cleans up table/queue twice In-Reply-To: References: <1547238696.13989.23.camel@redhat.com> Message-ID: <1547239382.13989.24.camel@redhat.com> Thanks, Roman. -Zhengyu On Fri, 2019-01-11 at 21:41 +0100, Roman Kennke wrote: > Hi Zhengyu, > > this looks good to me. > > Thanks, > Roman > > > Shenandoah string deduplication cleans up deduplication table and > > queues twice, once via ParallelCleaningTask and then > > ShenandoahStringDedup::parallel_cleanup(). The second cleanup > > should be > > removed after we adopted upstream deduplication implementation. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215549 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215549/webrev.00/ > > > > Test: > > > > tier1,2,3 gc_shenandoah on Linux 64 (fastdebug and release) > > > > > > Thanks, > > > > -Zhengyu > > > > From kim.barrett at oracle.com Fri Jan 11 23:22:00 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Jan 2019 18:22:00 -0500 Subject: RFR (S): 8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled In-Reply-To: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> References: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> Message-ID: > On Jan 11, 2019, at 9:14 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this small change that fixes somewhat spammy > log messages for the periodic garbage collections feature if it is > *disabled*? > > So at the moment, if you somehow enable gc+periodic debug level log > messages (e.g. via gc*=debug), you will get a message that the current > periodic gc is being skipped because of the wrong reason basically, > also containing some random number due to an uninitialized variable. > > This change fixes that by: > > - at the start of the VM g1 will now print whether periodic gcs are > enabled or disabled (with the selected interval if enabled) once > - only if enabled, the periodic gc checking log messages are printed as > usual, and without the problem with the uninitialized variable. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8216490 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8216490/webrev/ > Testing: > new test > > Thanks, > Thomas ------------------------------------------------------------------------------ test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java 28 * @requires vm.compMode != "Xcomp" Why does this test require not Xcomp? ------------------------------------------------------------------------------ Other than that, looks good. From kim.barrett at oracle.com Sat Jan 12 00:14:40 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Jan 2019 19:14:40 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: <1547140970.13989.6.camel@redhat.com> References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> <1547140970.13989.6.camel@redhat.com> Message-ID: <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> > On Jan 10, 2019, at 12:22 PM, zgu at redhat.com wrote: > > Hi Kim, > > Thanks for the review. > > Please see updated webrev based on your suggestion: > http://cr.openjdk.java.net/~zgu/JDK-8215299/webrev.03/index.html > > >> Looks good, but I?d like to see more testing of something this >> ?core?, especially a bit of stress testing. >> The submit tests are more at the level of ?smoke? tests. > > Besides submit tests, I also ran hotspot_gc tests on Linux 64, which > contains stress tests. > > This cycle, I also ran vmTestbase_vm_gc tests on Linux 64. > > Thanks, > > -Zhengyu > >> >> Given that most callers of regular_clock_call now conditionally call >> set_has_aborted, a helper function to encapsulate that might be nice. Thanks for the additional testing. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1ConcurrentMark.hpp 733 // Set abort flag if above check fails Rather than "above", actually refer to regular_clock_call by name. I don't need to review again for this. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1ConcurrentMark.hpp 734 inline void abort_marking_if_regular_check_fail(); I'm not wild about this name, but don't have a better suggestion. Maybe another reviewer will suggest something. Otherwise, go ahead with this name. ------------------------------------------------------------------------------ Looks good. From kim.barrett at oracle.com Sat Jan 12 02:51:49 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Jan 2019 21:51:49 -0500 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: References: Message-ID: > On Jan 10, 2019, at 3:46 PM, Thomas Schatzl wrote: > [?] > CR: > https://bugs.openjdk.java.net/browse/JDK-8213229 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ > Testing: > hs-tier1-6, performance checking with our performance suite showed no > particular performance differences before/after > > Thanks, > Thomas ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1ConcurrentMark.cpp 1660 // No need to clean string table as it is treated as strong root when 1661 // class unloading is disabled. I think that comment needs updating. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp 46 StringDedupCleaningTask _cleaning_task; Maybe _cleaning_task => _string_dedup_cleaning_task? It's obvious here, but not so much where used. ------------------------------------------------------------------------------ I think this change has introduced a memory leak in the StringTable OopStorage instance. The old code has calls to StringTable::reset_dead_counter() and StringTable::finish_dead_counter() in the StringCleaningTask constructor and destructor, and StringTable::unlink_or_oops_do and StringTable::possibly_parallel_unlink updated the dead counters. This resulted in notification of the ServiceThread when there was enough StringTable OopStorage cleanup work to do (e.g. go through the StringTable OopStorage instance looking for allocated entries with NULL values, and deallocate them). Nothing like that seems to be happening with these changes. I couldn't find anything that would trigger the ServiceThread's cleanup behavior. What I was expecting was that the parallel WeakProcessor would arrange for the closures it receives to be wrapped in counting closures, with the counts being recorded in the WeakProcessorPhaseTimes work items. And then those counts would be both reported in logging and also used in the StringTable case to notify the StringTable of changes. The serial WeakProcessor might do something similar, but I haven't looked at it as much for this problem. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Sat Jan 12 09:52:34 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 12 Jan 2019 04:52:34 -0500 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: References: Message-ID: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> > On Jan 11, 2019, at 9:51 PM, Kim Barrett wrote: > >> On Jan 10, 2019, at 3:46 PM, Thomas Schatzl wrote: >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8213229 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ >> Testing: >> hs-tier1-6, performance checking with our performance suite showed no >> particular performance differences before/after >> >> Thanks, >> Thomas > > ------------------------------------------------------------------------------ > > I think this change has introduced a memory leak in the StringTable > OopStorage instance. Doesn't just leave the OopStorage entries lingering, but also the associated entries in the table. However, not really a leak in the usual sense, I now think. If the internal table gets rehashed or needs to grow, the dead entries should be cleaned up. But having lingering dead entries may lead earlier rehash or growth than would otherwise be needed. From chihiro.ito at oracle.com Sun Jan 13 17:43:01 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Mon, 14 Jan 2019 02:43:01 +0900 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed Message-ID: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> Hi all, Fixing up name "collector.2" of G1GC in PerfCounter.print. Here is the webrev to do that: JBS: https://bugs.openjdk.java.net/browse/JDK-8214236 webrev: http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.00/ Regards, Chihiro From per.liden at oracle.com Sun Jan 13 19:59:31 2019 From: per.liden at oracle.com (Per Liden) Date: Sun, 13 Jan 2019 20:59:31 +0100 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> Message-ID: <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> "G1 stop-the-world concurrent collections" sounds like a contradiction. Can't we find a better name for this? /Per On 01/13/2019 06:43 PM, Chihiro Ito wrote: > Hi all, > > Fixing up name "collector.2" of G1GC in PerfCounter.print. > Here is the webrev to do that: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8214236 > webrev: http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.00/ > > Regards, > Chihiro > From thomas.schatzl at oracle.com Mon Jan 14 09:21:54 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Jan 2019 10:21:54 +0100 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> Message-ID: <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> Hi, On Sun, 2019-01-13 at 20:59 +0100, Per Liden wrote: > "G1 stop-the-world concurrent collections" sounds like a > contradiction. > Can't we find a better name for this? > > On 01/13/2019 06:43 PM, Chihiro Ito wrote: > > Hi all, > > > > Fixing up name "collector.2" of G1GC in PerfCounter.print. > > Here is the webrev to do that: > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8214236 > > webrev: http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.00/ "G1 concurrent cycle pauses" might be better names. It might be useful to look at the other names too: G1 incremental collections G1 stop-the-world full collections I would at least suggest to drop the "stop-the-world" since it seems superfluous as all collections are stw; and maybe add "pauses" to be similar to the above suggested "concurrent cycle pauses", i.e. something like G1 concurrent cycle pauses G1 incremental collection pauses G1 full collection pauses may be slightly better. Note that I have no idea where these names show up, so a CSR and/or release note may be needed. Thanks, Thomas From rkennke at redhat.com Mon Jan 14 11:25:44 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 14 Jan 2019 12:25:44 +0100 Subject: RFR: JDK-8216973: Shenandoah: Kick up cleanup phases in the right places Message-ID: In Shenandoah, we currently start cleanup phase when we dive into concurrent evacuation (and only then), and after the cycle (unconditionally). However, we only create trashed regions in final-mark (immediate garbage and/or garbage from previous cycle), and might skip evacuation altogether, and may not actually create trash at end of cycle if we merge update-refs onto subsequent concurrent-mark. Let's start cleanups where we actually need them: once unconditionally before conc-evac and once after final-update-refs. http://cr.openjdk.java.net/~rkennke/JDK-8216973/webrev.00/ Testing: hotspot_gc_shenandoah Also, should this go into JDK12? Thanks, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Mon Jan 14 11:40:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 Jan 2019 12:40:30 +0100 Subject: RFR: JDK-8216973: Shenandoah: Kick up cleanup phases in the right places In-Reply-To: References: Message-ID: <6b912bea-d687-1bc1-22b9-486f7dae67ff@redhat.com> On 1/14/19 12:25 PM, Roman Kennke wrote: > In Shenandoah, we currently start cleanup phase when we dive into > concurrent evacuation (and only then), and after the cycle > (unconditionally). However, we only create trashed regions in final-mark > (immediate garbage and/or garbage from previous cycle), and might skip > evacuation altogether, and may not actually create trash at end of cycle > if we merge update-refs onto subsequent concurrent-mark. Let's start > cleanups where we actually need them: once unconditionally before > conc-evac and once after final-update-refs. The intent for the patch is okay. > http://cr.openjdk.java.net/~rkennke/JDK-8216973/webrev.00/ I think comments need to be updated, for example: After final-mark: // Final mark might have reclaimed some immediate garbage, kick cleanup to reclaim // the space. This would be the last action if there is nothing to evacuate. heap->entry_cleanup(); After update-refs: // Update references freed up collection set, kick the cleanup to reclaim the space. heap->entry_cleanup(); > Also, should this go into JDK12? I think this is the minor performance enhancement, and as such it should be deferred until first 12u. So, let's push this to jdk/jdk, let it be tested, and then we'll do the backport to jdk-updates/jdk12u, when that arrives. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Mon Jan 14 11:46:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 14 Jan 2019 12:46:40 +0100 Subject: RFR: JDK-8216973: Shenandoah: Kick up cleanup phases in the right places In-Reply-To: <6b912bea-d687-1bc1-22b9-486f7dae67ff@redhat.com> References: <6b912bea-d687-1bc1-22b9-486f7dae67ff@redhat.com> Message-ID: <0b4f2973-9c1c-3207-356f-1f112d937e42@redhat.com> >> In Shenandoah, we currently start cleanup phase when we dive into >> concurrent evacuation (and only then), and after the cycle >> (unconditionally). However, we only create trashed regions in final-mark >> (immediate garbage and/or garbage from previous cycle), and might skip >> evacuation altogether, and may not actually create trash at end of cycle >> if we merge update-refs onto subsequent concurrent-mark. Let's start >> cleanups where we actually need them: once unconditionally before >> conc-evac and once after final-update-refs. > > The intent for the patch is okay. > >> http://cr.openjdk.java.net/~rkennke/JDK-8216973/webrev.00/ > > I think comments need to be updated, for example: > > After final-mark: > > // Final mark might have reclaimed some immediate garbage, kick cleanup to reclaim > // the space. This would be the last action if there is nothing to evacuate. > heap->entry_cleanup(); > > > After update-refs: > > // Update references freed up collection set, kick the cleanup to reclaim the space. > heap->entry_cleanup(); > > >> Also, should this go into JDK12? > > I think this is the minor performance enhancement, and as such it should be deferred until first > 12u. So, let's push this to jdk/jdk, let it be tested, and then we'll do the backport to > jdk-updates/jdk12u, when that arrives. > Alright. I will push this: http://cr.openjdk.java.net/~rkennke/JDK-8216973/webrev.01/ to jdk/jdk then. Thanks! Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Mon Jan 14 11:48:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 Jan 2019 12:48:45 +0100 Subject: RFR: JDK-8216973: Shenandoah: Kick up cleanup phases in the right places In-Reply-To: <0b4f2973-9c1c-3207-356f-1f112d937e42@redhat.com> References: <6b912bea-d687-1bc1-22b9-486f7dae67ff@redhat.com> <0b4f2973-9c1c-3207-356f-1f112d937e42@redhat.com> Message-ID: On 1/14/19 12:46 PM, Roman Kennke wrote: > Alright. I will push this: > http://cr.openjdk.java.net/~rkennke/JDK-8216973/webrev.01/ Looks good to me. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Mon Jan 14 13:21:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 14 Jan 2019 08:21:00 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> <1547140970.13989.6.camel@redhat.com> <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> Message-ID: <1547472060.13989.32.camel@redhat.com> Thanks again, Kim. > > > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1ConcurrentMark.hpp > 733 // Set abort flag if above check fails > > Rather than "above", actually refer to regular_clock_call by name. > I don't need to review again for this. Will fix before push. > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1ConcurrentMark.hpp > 734 inline void abort_marking_if_regular_check_fail(); > > I'm not wild about this name, but don't have a better suggestion. > Maybe another reviewer will suggest something. Otherwise, go > ahead with this name. May I get a second review? Thanks, -Zhengyu > > > ------------------------------------------------------------------- > ----------- > > Looks good. > From leo.korinth at oracle.com Mon Jan 14 13:43:08 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 14 Jan 2019 14:43:08 +0100 Subject: RFR: 8214799: Add package declaration to each JTREG test case in the gc folder In-Reply-To: <2A5A69F0-0995-4E95-8EA9-2F90A4BD5A37@oracle.com> References: <19bae948-ec2b-257e-d0fc-69ff95093642@oracle.com> <3899785E-F88A-4F4B-8DE7-9002F7835AD3@oracle.com> <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> <2A5A69F0-0995-4E95-8EA9-2F90A4BD5A37@oracle.com> Message-ID: On 11/01/2019 18:30, Leonid Mesnik wrote: > Hi > > The changes look good to me. Thanks for fixing all this. Please note that I am not a 'R'eviewer. > > Leonid Thank you Leonid for your (committer) review and suggestions for improvement. /Leo >> On Jan 11, 2019, at 8:54 AM, Leo Korinth wrote: >> >> Hi again! >> >> New webrev, no incremental this time either as I have changed all copyright years, all library annotations, and several new tests have been rebased. >> >> Changes since last time: >> 1) The bad rebase artifact (bad rebase of moved file) CriticalNativeStress.java is now removed. I still left the small refactoring to a Java JNI "mirror" class as I think it is nicer than the old solution with several Java files in different packages mapping to the same JNI file. >> 2) All relative @library lines now uses the absolute "/" that will improve future refactoring. I still have them on separate lines if several paths are used -- my reason is that they diff better. >> 3) All new test cases in the new directory nvdimm have been fixed >> 4) A new test in directory epsilon has been fixed >> 5) All (Oracle) copyright years have been updated to 2019, I did not bother to add Oracle copyrights to the Epsilon/Shenandoah sources as my contribution is insignificant. >> 6) Shenandoah has landed, but I will not update all those test cases, I made this webrev too large already. I have tried to update all Shenandoah test cases that are located outside the shenendoah folder though. >> >> (New) Webrev: >> http://cr.openjdk.java.net/~lkorinth/8214799/02/ >> >> Testing: >> open/test/hotspot/jtreg/:hotspot_gc >> >> Thanks, >> Leo >> >> >> On 22/12/2018 12:10, Leo Korinth wrote: >>> Hi! >>> On 21/12/2018 21:50, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Great change. The only a couple of comments >>>> >>>> 1) I see that you added a lot of relative links to include test-root as library like: >>>> >>>> 32 * @library ../../.. >>>> >>>> >>>> I think you might want to use >>>> @library > or add to existing library test/lib like >>>> @library /test/lib / >>>> >>>> instead. You might find a lot of examples in existing compiler and gc tests. >>>> >>>> It is the more common an unified approach rather then using relative paths. Also it allows you to don't care when you move tests in different packages. >>>> >>> I will try that, it is certainly better. I think I will use a new @library line though, it is easier to see the change. >>>> >>>> 2) New test in http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.new.java.html >>>> looks confusing to me. It is copied from http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/stress/CriticalNativeStress.new.java.html >>>> >>>> So now we have test CriticalNativeStress gc/epsilon/CriticalNativeStress.java and CriticalNativeStressEpsilon in gc/stress/CriticalNativeStress.java >>>> The code in both files and jtreg tags looks pretty similar. Have you added it intentionally? Could you please explain a little bit purpose of this. >>> Many thanks for finding this fault of mine. The file was moved with the Shenandoah push, and I must have rebased it badly although the move of the corresponding c-file went through, strange... >>>> Other changes looks good. >>>> >>> Thanks for taking a look at it! >>> I will create a new webrev after the holiday. >>> /Leo >>>> Leonid >>>>> On Dec 21, 2018, at 11:32 AM, Leo Korinth >>>> > wrote: >>>>> >>>>> Hi again! >>>>> >>>>> I am adding Leonid and Erik to the discussion to see if my package additions are in any way troublesome to the bigger picture. I believe they are not. We are already using Java packages in some tests; this change will just add them to more tests so that one can easily use an IDE. >>>>> >>>>> Please ignore the old webrev as I had to rebase against the resent Shenandoah push. It is easier to just read this version (http://cr.openjdk.java.net/~lkorinth/8214799/01/). Unfortunately no incremental version is given as this is a rebase. >>>>> >>>>> I have not had the time to update the test cases under the gc/shenandoah folder (I am also afraid to make this change any bigger), but I have tried to update the test cases that changed or was added by the Shenandoah push (some Epsilon and Shenandoah tests outside the gc/shenandoah folder). >>>>> >>>>> This rebase basically applies the same kind of changes to the added test cases. One change that I would like you to look more carefully at is the addition of a helper class CriticalNative.java that uses JNI. Without this refactoring I could not have used the same c-file as it was used in different packages (it is used from three different test cases, and the package is part of the JNI export name). Please take an extra look at that change. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~lkorinth/8214799/01/ >>>>> >>>>> Testing: >>>>> I have run jtreg tests under gc/epsilon and I have run :hotspot_gc with Shenandoah in order not to break those test cases. >>>>> >>>>> Also started new run of tier1-3 and :hotspot_gc >>>>> >>>>> Thanks, >>>>> Leo >>>>> >>>>> On 05/12/2018 14:44, Leo Korinth wrote: >>>>>> Hi, >>>>>> I have added package declarations to all jtreg tests in the gc folder (and sub folders). Previously most tests were not in a package (though some where), making it extremely hard to work with jtreg tests in an IDE. >>>>>> The main change consists of adding a package declaration that corresponds to the directory the test is located in. This also makes it necessary to change @run annotations. Some test cases uses "common" code that is not located in the test lib. Those test cases now need to have a @library annotation that references the jtreg test root. >>>>>> A few test cases had package visible classes with the same name in the same directory. That did work before, but does not work anymore, so I have prefixed those package visible classes with the public class name. >>>>>> class TestVerifySilentlyRunSystemGC >>>>>> class TestVerifySubSetRunSystemGC >>>>>> class TestEagerReclaimHumongousRegionsReclaimRegionFast >>>>>> class TestEagerReclaimHumongousRegionsClearMarkBitsReclaimRegionFast >>>>>> class TestEagerReclaimHumongousRegionsWithRefsReclaimRegionFast >>>>>> Where classes have been referenced using string literals, I have tried to use a .class.getName() instead (where possible). >>>>>> I have tried to update copyrights to all files (also adding a missing comma after the second year in some files), and I did add missing copyright to TestFromCardCacheIndex. >>>>>> known cons: >>>>>> - needs a package line in each java file >>>>>> - needs an extra library line in the test if the test is using other files. >>>>>> - sometimes needs a run tag >>>>>> improvements: >>>>>> + can use eclipse or other IDEs without creating a workspace per test (I guess it will be a significant improvement for users of emacs and vi as well) >>>>>> + can use test files located in other directories >>>>>> After this change, I have several big cleanups that are easy to do with a working IDE. >>>>>> Enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8214799 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~lkorinth/8214799/00/ >>>>>> Testing: >>>>>> passed: >>>>>> mach5 remote-build-and-test --build-profiles linux-x64,linux-x64-debug,macosx-x64,solaris-sparcv9,windows-x64 --test open/test/hotspot/jtreg/:hotspot_gc >>>>>> now running: >>>>>> mach5 remote-test --build-id 2018-12-05-1132377.leo.korinth.hs --build-profiles linux-x64-debug -j tier1,tier2,tier3 >>>>>> Thanks, >>>>>> Leo >>>> > From chihiro.ito at oracle.com Mon Jan 14 17:19:08 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Tue, 15 Jan 2019 02:19:08 +0900 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> Message-ID: <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> Hi, Thank you for reviewing and giving ideas. I agree to this idea. In addition, I think we should change also counter names "CMS stop-the-world phases" to "CMS concurrent cycle pauses" in CMS. Regards, Chihiro On 2019/01/14 18:21, Thomas Schatzl wrote: > Hi, > > On Sun, 2019-01-13 at 20:59 +0100, Per Liden wrote: >> "G1 stop-the-world concurrent collections" sounds like a >> contradiction. >> Can't we find a better name for this? >> >> On 01/13/2019 06:43 PM, Chihiro Ito wrote: >>> Hi all, >>> >>> Fixing up name "collector.2" of G1GC in PerfCounter.print. >>> Here is the webrev to do that: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214236 >>> webrev: http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.00/ > "G1 concurrent cycle pauses" might be better names. > > It might be useful to look at the other names too: > > G1 incremental collections > G1 stop-the-world full collections > > I would at least suggest to drop the "stop-the-world" since it seems > superfluous as all collections are stw; and maybe add "pauses" to be > similar to the above suggested "concurrent cycle pauses", i.e. > something like > > G1 concurrent cycle pauses > G1 incremental collection pauses > G1 full collection pauses > > may be slightly better. > > Note that I have no idea where these names show up, so a CSR and/or > release note may be needed. > > Thanks, > Thomas > > > From rkennke at redhat.com Mon Jan 14 21:42:06 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 14 Jan 2019 22:42:06 +0100 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers Message-ID: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> Currently, we have a bit of a mess in ShenandoahBarrierSetAssembler::cmpxchg_oop(): It has special code paths for C1-only (everthing under the boolean arg 'encode') and it has a code path for !ShenandoahCASBarrier. Also, while C1 actually does not exchange, we call it with exchange==true and cmove the result. This is backwards. Also, we hacked to call storeval-barrier in C1-only path, because it can't easily be done otherwise in C1. Streamlining this code would help tremendously to clarify the actual CAS barrier algorithm, which is currently buried under all those special paths. The proposed change does: - Extract the C1-specific paths (currently misnomed under 'encode') into shenandoahBarrierSetC1.cpp - Removed !ShenandoahCASBarrier path from assembler, generate non-Shenandoah-CASes in C2 instead - Make C1 generate the boolean version Bug: https://bugs.openjdk.java.net/browse/JDK-8217016 Proposed fix/refactoring: http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.00/ Testing: hotspot_gc_shenandoah, bunch of specjvm tests Ok? Thanks, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zanglin5 at jd.com Tue Jan 15 02:26:01 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Tue, 15 Jan 2019 02:26:01 +0000 Subject: record object number in AgeTable for G1 Message-ID: <035dddcd97da4662b5a7ca96e48d3618@jd.com> Hi all, I recently worked with G1 and found that the AgeTable records the number of bytes for every age. But it is hard to get the object count for every age, I think it may be useful when I want to know how is the object distribution looks like for every age. so I made a patch to make AgeTable record the object count. do you think it is a reasonable change? Thanks! Lin From thomas.schatzl at oracle.com Tue Jan 15 09:04:11 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Jan 2019 10:04:11 +0100 Subject: record object number in AgeTable for G1 In-Reply-To: <035dddcd97da4662b5a7ca96e48d3618@jd.com> References: <035dddcd97da4662b5a7ca96e48d3618@jd.com> Message-ID: <7db97a230694faf65582f88bacf71e5667ac8ef9.camel@oracle.com> Hi, On Tue, 2019-01-15 at 02:26 +0000, ?? wrote: > Hi all, > I recently worked with G1 and found that the AgeTable records > the number of bytes for every age. But it is hard to get the object > count for every age, I think it may be useful when I want to know how > is the object distribution looks like for every age. so I made a > patch to make AgeTable record the object count. > do you think it is a reasonable change? in such cases, i.e. changes to the core evacuation method, the problem is typically not so much adding information, but weighing the impact on pause times vs. the gain. I.e. such a change would need to be thoroughly performance-tested. Thanks, Thomas From suenaga.yasumasa at nttcom.co.jp Tue Jan 15 09:30:33 2019 From: suenaga.yasumasa at nttcom.co.jp (Yasumasa Suenaga) Date: Tue, 15 Jan 2019 18:30:33 +0900 Subject: PING: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> Message-ID: PING: Did you read my email? I wrote the problem and suggested fix in it. Please tell me if you have question(s). I can file it to JBS if it is a bug. Thanks, Yasumasa On 2019/01/10 18:02, Yasumasa Suenaga wrote: > Hi all, > > I'm Yasumasa Suenaga (OpenJDK reviewer: ysuenaga) > > My customer uses OpenJDK 8u131 with following commandline arguments: > > ? -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 > ? -XX:CompressedClassSpaceSize=128m -Xms4500m -Xmx4500m > ? -XX:MaxMetaspaceSize=256m -Xmn=768m -XX:MaxTenuringThreshold=15 > ? -XX:OnOutOfMemoryError="/bin/kill -ABRT %p" > ? -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC > > Their system has encountered OutOfMemoryError which is caused by Metaspace. > > I checked core image which was collected by OnOutOfMemoryError, and I saw > strange values in it as below: > > ------------------- > (gdb) p Metaspace::_space_list->_reserved_words > $67 = 31195136 > (gdb) p Metaspace::_class_space_list->_reserved_words > $68 = 16777216 > (gdb) p MetaspaceGC::_capacity_until_GC > $75 = 448045056 > ------------------- > > MaxMetaspaceSize and CompressedClassSpaceSize seem to affect Metaspace. > However, MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize. > Is it correct? > > I checked used and committed memory from the core, they seem to be enough > to allocate new objects as below: > > ------------------- > (gdb) p MetaspaceAux::_used_words > $62 = {1742673, 17905981} > (gdb) p Metaspace::_space_list->_committed_words > $64 = 30932992 > (gdb) p Metaspace::_class_space_list->_committed_words > $65 = 2621440 > ------------------- > > I guess the cause of OOME is invalid value in _capacity_until_GC. > _capacity_until_GC is used for expanding / shrinking Metaspace. > However it is not checked when it changes. > > So I think we need to add the code to check it as below: > (The change is for jdk/jdk) > ------------------- > diff -r 32c6cc430526 src/hotspot/share/memory/metaspace.cpp > --- a/src/hotspot/share/memory/metaspace.cpp??? Wed Jan 09 22:59:49 2019 +0100 > +++ b/src/hotspot/share/memory/metaspace.cpp??? Thu Jan 10 17:56:55 2019 +0900 > @@ -143,6 +143,10 @@ > ???? new_value = align_down(max_uintx, Metaspace::commit_alignment()); > ?? } > > +? if (new_value > MaxMetaspaceSize) { > +??? return false; > +? } > + > ?? size_t prev_value = Atomic::cmpxchg(new_value, &_capacity_until_GC, old_capacity_until_GC); > > ?? if (old_capacity_until_GC != prev_value) { > ------------------- > > _capacity_until_GC is set to MaxMetaspaceSize at MetaspaceGC::initialize(), > and it set to committed size or MetaspaceSize at MetaspaceGC::post_initialize(). > So I guess max value of it is MaxMetaspaceSize. > > > What do you think? > If it is a bug, I will file JBS and send review request. > > > Thanks, > > Yasumasa > > > > From thomas.schatzl at oracle.com Tue Jan 15 09:49:45 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Jan 2019 10:49:45 +0100 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> Message-ID: <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> Hi Chihiro, On Tue, 2019-01-15 at 02:19 +0900, Chihiro Ito wrote: > Hi, > > Thank you for reviewing and giving ideas. > > I agree to this idea. In addition, I think we should change also > counter names "CMS stop-the-world phases" to "CMS concurrent cycle > pauses" in CMS. fine with me. Thomas From thomas.schatzl at oracle.com Tue Jan 15 09:52:17 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Jan 2019 10:52:17 +0100 Subject: RFR (S): 8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled In-Reply-To: References: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> Message-ID: <07478fd68384def72c9aa7327e5c3e7e7fe32ca9.camel@oracle.com> Hi, On Fri, 2019-01-11 at 18:22 -0500, Kim Barrett wrote: > > On Jan 11, 2019, at 9:14 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this small change that fixes somewhat > > spammy log messages for the periodic garbage collections feature if > > it is *disabled*? > > > > So at the moment, if you somehow enable gc+periodic debug level log > > messages (e.g. via gc*=debug), you will get a message that the > > current periodic gc is being skipped because of the wrong reason > > basically, also containing some random number due to an > > uninitialized variable. > > > > This change fixes that by: > > > > - at the start of the VM g1 will now print whether periodic gcs are > > enabled or disabled (with the selected interval if enabled) once > > - only if enabled, the periodic gc checking log messages are > > printed as usual, and without the problem with the uninitialized > > variable. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8216490 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8216490/webrev/ > > Testing: > > new test > > > > Thanks, > > Thomas > > ------------------------------------------------------------------- > ----------- > test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java > 28 * @requires vm.compMode != "Xcomp" > > Why does this test require not Xcomp? Copy&Paste error. Fixed in place. Thomas From thomas.schatzl at oracle.com Tue Jan 15 14:13:48 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Jan 2019 15:13:48 +0100 Subject: RFR: 8212826: Make PtrQueue free list lock-free In-Reply-To: References: Message-ID: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> Hi Kim, On Wed, 2019-01-09 at 16:48 -0500, Kim Barrett wrote: > Please review this change to BufferNode::Allocator to eliminate the > Mutex protecting the free-list, instead using a lock-free free-list. > > This eliminates the need for the (access rank) free list lock for the > SATB and DirtyCard buffer allocator. > > Part of this change is the introduction of a LockFreeStack utility > class template. This class doesn't attempt to solve the ABA problem, > instead leaving that to the client. The Allocator uses GlobalCounter > to solve the problem. (Other existing potential uses cases have > separate phases for push and pop, don't recycle objects, or have > other solutions.) Popping a buffer from the free list is done within > a read critical section. A buffer is added to the free list only > after an associated write synchronization is performed. That's really nice, just what I needed :) (The allocator and the stack class). > > Unfortunately, the API for LockFreeStack<> isn't quite what we would > prefer. We would like this class's signature to be > > template class LockFreeStack; > > but it is instead > > template class > LockFreeStack; > > This is due to a bug in Solaris Studio's handling of pointer to data > member references within the class declaration (where the class is > incomplete). (Visual Studio 2013 (not before or after) had a similar > bug.) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8212826 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8212826/open.00/ > - ptrQueue.cpp:121: size_zero seems to be unused, and size_one can be avoided completely by using Atomic::inc/dec instead of add/sub which I would prefer. Even if you kept add/sub, hardcoding (size_t)1 would be less code than the constant declaration as there are not many uses. - test_ptrQueueBufferAllocator.cpp copyright should be "2018, 2019," instead of just 2019. - the gtest adds a small API for testing and comparison should be part of the test. It honestly seems to add nothing to the final test other than adding additional code, particularly because the other variants mentioned in the comment are not there. So I would prefer to flatten the FreeListPtrQueueBufferAllocator/FreeListPtrQueueBufferCompletedList classes. Looks good otherwise. Thanks, Thomas From kim.barrett at oracle.com Tue Jan 15 15:29:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Jan 2019 10:29:17 -0500 Subject: RFR (S): 8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled In-Reply-To: <07478fd68384def72c9aa7327e5c3e7e7fe32ca9.camel@oracle.com> References: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> <07478fd68384def72c9aa7327e5c3e7e7fe32ca9.camel@oracle.com> Message-ID: <383980B3-F072-496F-8020-8EEF727D0F17@oracle.com> > On Jan 15, 2019, at 4:52 AM, Thomas Schatzl wrote: >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8216490 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8216490/webrev/ >>> Testing: >>> new test >>> >>> Thanks, >>> Thomas >> >> ------------------------------------------------------------------- >> ----------- >> test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java >> 28 * @requires vm.compMode != "Xcomp" >> >> Why does this test require not Xcomp? > > Copy&Paste error. Fixed in place. > > Thomas Thanks. Looks good. From chihiro.ito at oracle.com Tue Jan 15 15:30:52 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Wed, 16 Jan 2019 00:30:52 +0900 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> Message-ID: Hi Thomas and Per, I fixed counter name in G1, CMS and Z. Could you review it ? http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ For your information, output of PerfCounter.print is following. G1GC: sun.gc.collector.0.name="G1 incremental collection pauses" sun.gc.collector.1.name="G1 full collection pauses" sun.gc.collector.2.name="G1 concurrent cycle pauses" CMS: sun.gc.collector.2.name="CMS concurrent cycle pauses" ZGC: sun.gc.collector.2.name="Z concurrent cycle pauses" Regards, Chihiro On 2019/01/15 18:49, Thomas Schatzl wrote: > Hi Chihiro, > > On Tue, 2019-01-15 at 02:19 +0900, Chihiro Ito wrote: >> Hi, >> >> Thank you for reviewing and giving ideas. >> >> I agree to this idea. In addition, I think we should change also >> counter names "CMS stop-the-world phases" to "CMS concurrent cycle >> pauses" in CMS. > fine with me. > > Thomas > > > From rkennke at redhat.com Tue Jan 15 15:38:16 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 15 Jan 2019 16:38:16 +0100 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: <1547472060.13989.32.camel@redhat.com> References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> <1547140970.13989.6.camel@redhat.com> <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> <1547472060.13989.32.camel@redhat.com> Message-ID: Hi Zhengyu, Kim, >> ------------------------------------------------------------------- >> ----------- >> src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> 733 // Set abort flag if above check fails >> >> Rather than "above", actually refer to regular_clock_call by name. >> I don't need to review again for this. > > Will fix before push. > > >> ------------------------------------------------------------------- >> ----------- >> src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> 734 inline void abort_marking_if_regular_check_fail(); >> >> I'm not wild about this name, but don't have a better suggestion. >> Maybe another reviewer will suggest something. Otherwise, go >> ahead with this name. > > May I get a second review? Looks ok to me. Thanks! Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Tue Jan 15 15:44:10 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 15 Jan 2019 10:44:10 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> <1547140970.13989.6.camel@redhat.com> <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> <1547472060.13989.32.camel@redhat.com> Message-ID: <1547567050.13989.45.camel@redhat.com> Thanks, Roman. -Zhengyu > Looks ok to me. Thanks! > > Roman > From kim.barrett at oracle.com Tue Jan 15 16:33:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Jan 2019 11:33:35 -0500 Subject: [PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance In-Reply-To: References: Message-ID: > On Dec 23, 2018, at 12:38 PM, Haoyu Li wrote: > > Hi all? > I have developed a patch to enhance the full GC performance of Parallel Scavenge on OpenJDK 11, may I have some reviews? The patch is described as follows and attached in this mail. > > [?] > > The patch and evaluation result are attached. > > Best Regrads, > Haoyu Li, > Institute of Parallel and Distributed Systems(IPADS), > School of Software, > Shanghai Jiao Tong University Thanks for offering to contribute to the OpenJDK project. Sorry it's taken a while to respond, but holidays &etc intervened. The idea of the patch sounds interesting. However, before we can proceed, there may be some process issues that need to be addressed. The first, and most critical: are you covered by an Oracle Contributor Agreement (either individually or via an employer who is sponsoring this work)? If not, that needs to be dealt with first. For details, see https://openjdk.java.net/contribute/. Another is that current development is going into the jdk repo http://hg.openjdk.java.net/jdk/jdk/ (which is currently targeting JDK 13), while your email suggests your patch is against the OpenJDK 11 release. This kind of change should be made in the current line of development, and then perhaps considered for backporting. So the patch will likely need to be updated. (It might not require all that much modification though; ParallelGC has been pretty stable for a while.) Since you don't appear to be an OpenJDK committer/author, you'll need a sponsor to help with some of the other pieces of the puzzle: Each change requires an associated bug ID, from the OpenJDK bug database. Without a username there (which requires OpenJDK author status), your sponsor can create the CR there. Also, changes of more than some trivial extent generally get packaged for review using the webrev tool, and published on cr.openjdk.java.net. https://openjdk.java.net/guide/codeReview.html Your sponsor can help you with that. Your change may need additional testing (both for correctness and performance). For example, you don't mention what platforms you've tested on, there are a lot of functional tests for OpenJDK, and there are probably other performance tests that should be applied to a change like this. For a change like this, your sponsor should be someone currently involved in OpenJDK GC development, preferably in an area related to the patch. It's not required that they be an Oracle employee, though for some things that might help. I can help you find someone. (It might be me, but I don't want to commit to that today.) From kim.barrett at oracle.com Tue Jan 15 22:54:08 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Jan 2019 17:54:08 -0500 Subject: RFR: 8212826: Make PtrQueue free list lock-free In-Reply-To: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> References: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> Message-ID: <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> > On Jan 15, 2019, at 9:13 AM, Thomas Schatzl wrote: > > Hi Kim, > > On Wed, 2019-01-09 at 16:48 -0500, Kim Barrett wrote: >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8212826 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8212826/open.00/ >> > > - ptrQueue.cpp:121: > > size_zero seems to be unused, and size_one can be avoided completely by > using Atomic::inc/dec instead of add/sub which I would prefer. > > Even if you kept add/sub, hardcoding (size_t)1 would be less code than > the constant declaration as there are not many uses. Can?t use inc/dec, because the incremented values are used, and those functions don?t return anything. But it seems that I forgot that Erik and I managed to slip in a bit of argument canonicalization here, so that an exact type match isn?t required; just using ?1u? works. > - test_ptrQueueBufferAllocator.cpp copyright should be "2018, 2019," > instead of just 2019. Oops. Fixed. > - the gtest adds a small API for testing and comparison should be part > of the test. It honestly seems to add nothing to the final test other > than adding additional code, particularly because the other variants > mentioned in the comment are not there. So I would prefer to flatten > the FreeListPtrQueueBufferAllocator/FreeListPtrQueueBufferCompletedList > classes. Done, with a bit more cleanup. > Looks good otherwise. Thanks. Note that I?ve filed a bug against Solaris Studio for the problem with using pointers to data members. I?ll file a JDK RFE to change LockFreeStack to the preferred form once the Solaris Studio bug is fixed and we?re no longer supporting versions with the bug. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8212826/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8212826/open.01.inc/ From thomas.schatzl at oracle.com Tue Jan 15 23:13:56 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Jan 2019 00:13:56 +0100 Subject: RFR (XS): 8217203: Some more includes to .inline.hpp files in gc header files Message-ID: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> Hi all, over time some gc hpp files started directly including .inline.hpp files again. Fix this to avoid future dependency messes. I fixed one of the problems in shenandoah files because it was easy - the one in shenandoahTaskqueue.hpp has been split into an extra CR ( https://bugs.openjdk.java.net/browse/JDK-8217213) as it started getting complicated fixing wrong includes there. CR: https://bugs.openjdk.java.net/browse/JDK-8217203 Webrev: http://cr.openjdk.java.net/~tschatzl/8217203/webrev/ Testing: local compilation, building in CI Thanks, Thomas From kim.barrett at oracle.com Tue Jan 15 23:45:52 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Jan 2019 18:45:52 -0500 Subject: RFR (XS): 8217203: Some more includes to .inline.hpp files in gc header files In-Reply-To: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> References: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> Message-ID: <9392246C-8F7E-40A8-A440-646A6F5B8CBF@oracle.com> > On Jan 15, 2019, at 6:13 PM, Thomas Schatzl wrote: > > Hi all, > > over time some gc hpp files started directly including .inline.hpp > files again. > > Fix this to avoid future dependency messes. > > I fixed one of the problems in shenandoah files because it was easy - > the one in shenandoahTaskqueue.hpp has been split into an extra CR ( > https://bugs.openjdk.java.net/browse/JDK-8217213) as it started getting > complicated fixing wrong includes there. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217203 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217203/webrev/ > Testing: > local compilation, building in CI > > Thanks, > Thomas Looks good. From sangheon.kim at oracle.com Wed Jan 16 00:56:29 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Tue, 15 Jan 2019 16:56:29 -0800 Subject: RFR (XS): 8217203: Some more includes to .inline.hpp files in gc header files In-Reply-To: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> References: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> Message-ID: Hi Thomas, On 1/15/19 3:13 PM, Thomas Schatzl wrote: > Hi all, > > over time some gc hpp files started directly including .inline.hpp > files again. > > Fix this to avoid future dependency messes. > > I fixed one of the problems in shenandoah files because it was easy - > the one in shenandoahTaskqueue.hpp has been split into an extra CR ( > https://bugs.openjdk.java.net/browse/JDK-8217213) as it started getting > complicated fixing wrong includes there. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217203 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217203/webrev/ Looks good. Thanks, Sangheon > Testing: > local compilation, building in CI > > Thanks, > Thomas > From zgu at redhat.com Wed Jan 16 01:03:16 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 15 Jan 2019 20:03:16 -0500 Subject: RFR (XS): 8217203: Some more includes to .inline.hpp files in gc header files In-Reply-To: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> References: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> Message-ID: <1547600596.13989.65.camel@redhat.com> Looks good to me. Thanks for fixing ShenandoahTaskqueue.hpp and filing JDK-8217213. I will handle JDK-8217213. -Zhengyu On Wed, 2019-01-16 at 00:13 +0100, Thomas Schatzl wrote: > Hi all, > > over time some gc hpp files started directly including .inline.hpp > files again. > > Fix this to avoid future dependency messes. > > I fixed one of the problems in shenandoah files because it was easy - > the one in shenandoahTaskqueue.hpp has been split into an extra CR ( > https://bugs.openjdk.java.net/browse/JDK-8217213) as it started > getting > complicated fixing wrong includes there. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217203 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217203/webrev/ > Testing: > local compilation, building in CI > > Thanks, > Thomas > From zanglin5 at jd.com Wed Jan 16 01:29:50 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Wed, 16 Jan 2019 01:29:50 +0000 Subject: record object number in AgeTable for G1 In-Reply-To: <7db97a230694faf65582f88bacf71e5667ac8ef9.camel@oracle.com> References: <035dddcd97da4662b5a7ca96e48d3618@jd.com> <7db97a230694faf65582f88bacf71e5667ac8ef9.camel@oracle.com> Message-ID: Hi Thomas, Thanks for your suggestion, I will try to get some performance number. Btw, do you have any recommendation of the benchmark/micro-bench for pause time measurement? BRs, Lin -----Original Message----- From: Thomas Schatzl Sent: Tuesday, January 15, 2019 5:04 PM To: ?? ; hotspot-gc-dev at openjdk.java.net Subject: Re: record object number in AgeTable for G1 Hi, On Tue, 2019-01-15 at 02:26 +0000, ?? wrote: > Hi all, > I recently worked with G1 and found that the AgeTable records > the number of bytes for every age. But it is hard to get the object > count for every age, I think it may be useful when I want to know how > is the object distribution looks like for every age. so I made a patch > to make AgeTable record the object count. > do you think it is a reasonable change? in such cases, i.e. changes to the core evacuation method, the problem is typically not so much adding information, but weighing the impact on pause times vs. the gain. I.e. such a change would need to be thoroughly performance-tested. Thanks, Thomas From leihouyju at gmail.com Wed Jan 16 02:03:29 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Wed, 16 Jan 2019 10:03:29 +0800 Subject: [PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance In-Reply-To: References: Message-ID: Thanks for your response Kim! For the process issues you mentioned, I have already been covered by an Oracle Contributor Agreement, and I will right away port this patch into OpenJDK 13 to follow the current line, then submit the updated patch to this mail list once I finish. Also as you mentioned, my change need additional testing for both correctness and performance. Can I please get some specific suggestions (like what benchmark or method I need to test the patch with)? Currently I test it with the benchmarks from DaCapo, SPECjvm2008, and JOlden suits on a machine with an Intel x86-64 CPU and a Linux OS. I can only find a suggestion from the page https://openjdk.java.net/contribute/ which says a patch need a unit test with jreg harness, but it also says the unit test is not pratical for performance improvement changes. It really helps if you can offer me some tips about tests. Last but not the least, I really appreciate that you help me find a sponsor or play the role of the sponsor. Best, Haoyu Li Kim Barrett ?2019?1?16??? ??12:33??? > > On Dec 23, 2018, at 12:38 PM, Haoyu Li wrote: > > > > Hi all? > > I have developed a patch to enhance the full GC performance of Parallel > Scavenge on OpenJDK 11, may I have some reviews? The patch is described as > follows and attached in this mail. > > > > [?] > > > > The patch and evaluation result are attached. > > > > Best Regrads, > > Haoyu Li, > > Institute of Parallel and Distributed Systems(IPADS), > > School of Software, > > Shanghai Jiao Tong University > > Thanks for offering to contribute to the OpenJDK project. Sorry it's > taken a while to respond, but holidays &etc intervened. > > The idea of the patch sounds interesting. However, before we can > proceed, there may be some process issues that need to be addressed. > > The first, and most critical: are you covered by an Oracle Contributor > Agreement (either individually or via an employer who is sponsoring > this work)? If not, that needs to be dealt with first. For details, > see https://openjdk.java.net/contribute/. > > Another is that current development is going into the jdk repo > http://hg.openjdk.java.net/jdk/jdk/ (which is currently targeting JDK > 13), while your email suggests your patch is against the OpenJDK 11 > release. This kind of change should be made in the current line of > development, and then perhaps considered for backporting. So the > patch will likely need to be updated. (It might not require all that > much modification though; ParallelGC has been pretty stable for a > while.) > > Since you don't appear to be an OpenJDK committer/author, you'll need > a sponsor to help with some of the other pieces of the puzzle: > > Each change requires an associated bug ID, from the OpenJDK bug > database. Without a username there (which requires OpenJDK author > status), your sponsor can create the CR there. > > Also, changes of more than some trivial extent generally get packaged > for review using the webrev tool, and published on cr.openjdk.java.net. > https://openjdk.java.net/guide/codeReview.html > Your sponsor can help you with that. > > Your change may need additional testing (both for correctness and > performance). For example, you don't mention what platforms you've > tested on, there are a lot of functional tests for OpenJDK, and there > are probably other performance tests that should be applied to a > change like this. > > For a change like this, your sponsor should be someone currently > involved in OpenJDK GC development, preferably in an area related to > the patch. It's not required that they be an Oracle employee, though > for some things that might help. I can help you find someone. (It > might be me, but I don't want to commit to that today.) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manc at google.com Wed Jan 16 02:41:45 2019 From: manc at google.com (Man Cao) Date: Tue, 15 Jan 2019 18:41:45 -0800 Subject: RFR (M): 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC overhead In-Reply-To: <7e0c775d-86c1-b80c-b1a6-373ca21206ba@oracle.com> References: <6b1e59ec7f4746e8e071fd44ec91ca966fac8d78.camel@oracle.com> <7e0c775d-86c1-b80c-b1a6-373ca21206ba@oracle.com> Message-ID: Hi, I rebased the patch to tip and updated year in some headers to 2019, without making any real change: http://cr.openjdk.java.net/~manc/8212206/webrev.02/ I don't foresee that this will be implemented, or even makes sense, for > ZGC. As I see it, this is only a thing STW collectors. For that reason, > I don't think it belongs in CollectedHeap. Keeping it as a separate > utility class for collectors that want to use it sounds better. > Sounds good to keep this patch in the current state, without further changing the CollectedHeap class. I haven't looked very closely at the patch, but couldn't help to notice > that the option is called "GCOverheapLimitThreshold" (and > "AdaptiveSizePolicyGCTimeLimitThreshold" before that), which is a > tautology and a not very good description of what it is. > How about we take the opportunity to clean this up and completely ditch > the "gc_overhead_limit_count" thing and get rid of this option? It's a > "develop" option, so it's not available to normal users anyway. Has > anyone of you ever used this option and actually find it valuable? I didn't find any users inside Google that require changing this option. That said, some users did complain that UseGCOverheadLimit for ParallelGC or CMS is too difficult to get triggered, because of the requirement for 5 consecutive full GCs, which is set by this option. I think if it were a normal "product" option, there will definitely be users setting it. I never understand why it is a "develop" option. I think we could either remove it, or make it an "experimental" option. I'm leaning towards not removing it for now, as I'm not sure if 5 is still a reasonable default value for UseGCOverheadLimit for G1. How about we decide whether to keep or remove this option after JDK-8212084 (UseGCOverheadLimit for G1) is fixed? Also for the hsperfdata counter change, I created https://bugs.openjdk.java.net/browse/JDK-8217221. I will draft a CSR for it later. -Man -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.liden at oracle.com Wed Jan 16 08:55:46 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 16 Jan 2019 09:55:46 +0100 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> Message-ID: <0b6a650f-aa79-25da-2011-7a84c6bffa89@oracle.com> Hi, On 1/15/19 4:30 PM, Chihiro Ito wrote: > Hi Thomas and Per, > > I fixed counter name in G1, CMS and Z. > Could you review it ? > > http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ Works for me. Just one comment. Please align the "ordinal" comment like this: - _collector_counters("stop-the-world" /* name */, + _collector_counters("Z concurrent cycle pauses" /* name */, + 2 /* ordinal */) {} /Per > > > For your information, output of PerfCounter.print is following. > > G1GC: > sun.gc.collector.0.name="G1 incremental collection pauses" > sun.gc.collector.1.name="G1 full collection pauses" > sun.gc.collector.2.name="G1 concurrent cycle pauses" > > CMS: > sun.gc.collector.2.name="CMS concurrent cycle pauses" > > ZGC: > sun.gc.collector.2.name="Z concurrent cycle pauses" > > Regards, > Chihiro > > On 2019/01/15 18:49, Thomas Schatzl wrote: >> Hi Chihiro, >> >> On Tue, 2019-01-15 at 02:19 +0900, Chihiro Ito wrote: >>> Hi, >>> >>> Thank you for reviewing and giving ideas. >>> >>> I agree to this idea. In addition, I think we should change also >>> counter? names "CMS stop-the-world phases" to? "CMS concurrent cycle >>> pauses" in CMS. >> ?? fine with me. >> >> Thomas >> >> >> > From thomas.schatzl at oracle.com Wed Jan 16 10:57:32 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Jan 2019 11:57:32 +0100 Subject: RFR (XS): 8217203: Some more includes to .inline.hpp files in gc header files In-Reply-To: <1547600596.13989.65.camel@redhat.com> References: <66121527221d724bd5c4980d56b0c78867b363eb.camel@oracle.com> <1547600596.13989.65.camel@redhat.com> Message-ID: <767b24022733ebab41594cb0aa40a53a42ba3262.camel@oracle.com> Hi Zhengyu, Sangheon, Kim, thanks for your reviews. Thomas On Tue, 2019-01-15 at 20:03 -0500, zgu at redhat.com wrote: > Looks good to me. > > Thanks for fixing ShenandoahTaskqueue.hpp and filing JDK-8217213. I > will handle JDK-8217213. > > -Zhengyu > > > On Wed, 2019-01-16 at 00:13 +0100, Thomas Schatzl wrote: > > Hi all, > > > > over time some gc hpp files started directly including > > .inline.hpp > > files again. > > > > Fix this to avoid future dependency messes. > > > > I fixed one of the problems in shenandoah files because it was easy > > - > > the one in shenandoahTaskqueue.hpp has been split into an extra CR > > ( > > https://bugs.openjdk.java.net/browse/JDK-8217213) as it started > > getting > > complicated fixing wrong includes there. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8217203 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8217203/webrev/ > > Testing: > > local compilation, building in CI > > > > Thanks, > > Thomas > > From thomas.schatzl at oracle.com Wed Jan 16 12:56:32 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Jan 2019 13:56:32 +0100 Subject: RFR (S): 8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled In-Reply-To: <383980B3-F072-496F-8020-8EEF727D0F17@oracle.com> References: <90a8fac3bc5eba7dbb2c7f1547930ec4b1724aea.camel@oracle.com> <07478fd68384def72c9aa7327e5c3e7e7fe32ca9.camel@oracle.com> <383980B3-F072-496F-8020-8EEF727D0F17@oracle.com> Message-ID: <9196dffc92ec5f4a3604b5b3268cc87c398d6bc0.camel@oracle.com> Kim, Sangheon, On Tue, 2019-01-15 at 10:29 -0500, Kim Barrett wrote: > > On Jan 15, 2019, at 4:52 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > > > > > CR: > > > > https://bugs.openjdk.java.net/browse/JDK-8216490 > > > > Webrev: > > > > http://cr.openjdk.java.net/~tschatzl/8216490/webrev/ > > > > Testing: > > > > [...] > > > > Thomas > > Thanks. Looks good. > thanks for your reviews. Thomas From thomas.schatzl at oracle.com Wed Jan 16 12:55:41 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Jan 2019 13:55:41 +0100 Subject: RFR: 8212826: Make PtrQueue free list lock-free In-Reply-To: <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> References: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> Message-ID: Hi, On Tue, 2019-01-15 at 17:54 -0500, Kim Barrett wrote: > > On Jan 15, 2019, at 9:13 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi Kim, > > > > On Wed, 2019-01-09 at 16:48 -0500, Kim Barrett wrote: > > > CR: > > > https://bugs.openjdk.java.net/browse/JDK-8212826 > > > > > > Webrev: > > > http://cr.openjdk.java.net/~kbarrett/8212826/open.00/ > > > > > > > - ptrQueue.cpp:121: > > > > size_zero seems to be unused, and size_one can be avoided > > completely by using Atomic::inc/dec instead of add/sub which I > > would prefer. > > > > Even if you kept add/sub, hardcoding (size_t)1 would be less code > > than the constant declaration as there are not many uses. > > Can?t use inc/dec, because the incremented values are used, and those > functions don?t return anything. But it seems that I forgot that > Erik and I managed to slip in a bit of argument canonicalization > here, so that an exact type match isn?t required; just using ?1u? > works. > > > - test_ptrQueueBufferAllocator.cpp copyright should be "2018, > > 2019," instead of just 2019. > > Oops. Fixed. > > > - the gtest adds a small API for testing and comparison should be > > part of the test. It honestly seems to add nothing to the final > > test other than adding additional code, particularly because the > > other variants mentioned in the comment are not there. So I would > > prefer to flatten the > > FreeListPtrQueueBufferAllocator/FreeListPtrQueueBufferCompletedList > > classes. > > Done, with a bit more cleanup. > > > Looks good otherwise. > > Thanks. > > Note that I?ve filed a bug against Solaris Studio for the problem > with using pointers to data members. I?ll file a JDK RFE to change > LockFreeStack to the preferred form once the Solaris Studio bug is > fixed and we?re no longer supporting versions with the bug. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8212826/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8212826/open.01.inc/ > Thanks. Looks good. Thomas From thomas.schatzl at oracle.com Wed Jan 16 13:41:42 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Jan 2019 14:41:42 +0100 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> Message-ID: Hi Chihiro, On Wed, 2019-01-16 at 00:30 +0900, Chihiro Ito wrote: > Hi Thomas and Per, > > I fixed counter name in G1, CMS and Z. > Could you review it ? > > http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ > > > For your information, output of PerfCounter.print is following. > > G1GC: > sun.gc.collector.0.name="G1 incremental collection pauses" > sun.gc.collector.1.name="G1 full collection pauses" > sun.gc.collector.2.name="G1 concurrent cycle pauses" > > CMS: > sun.gc.collector.2.name="CMS concurrent cycle pauses" > > ZGC: > sun.gc.collector.2.name="Z concurrent cycle pauses" Fine with me - since we are there, maybe you are interested in revisiting the names for the other CollectorCounters too? I found the following: Parallel GC: "PSScavenge" "PSParallelCompact" "PSMarkSweep" CMS: "CMS" "MSC" Serial: "PCopy" (I have no idea what this is supposed to be; this is serial young gc) We can skip them too if we can't find better names. Thanks, Thomas From chihiro.ito at oracle.com Wed Jan 16 14:42:08 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Wed, 16 Jan 2019 23:42:08 +0900 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <0b6a650f-aa79-25da-2011-7a84c6bffa89@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> <0b6a650f-aa79-25da-2011-7a84c6bffa89@oracle.com> Message-ID: Hi Per, Thank you so much for your reviewing. I care to align comments. I will try to re-request for review after renaming all GCs. Regards, Chihiro On 2019/01/16 17:55, Per Liden wrote: > Hi, > > On 1/15/19 4:30 PM, Chihiro Ito wrote: >> Hi Thomas and Per, >> >> I fixed counter name in G1, CMS and Z. >> Could you review it ? >> >> http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ > > Works for me. Just one comment. Please align the "ordinal" comment > like this: > > - _collector_counters("stop-the-world" /* name */, > + _collector_counters("Z concurrent cycle pauses" /* name */, > + 2 /* ordinal */) {} > > /Per > >> >> >> For your information, output of PerfCounter.print is following. >> >> G1GC: >> sun.gc.collector.0.name="G1 incremental collection pauses" >> sun.gc.collector.1.name="G1 full collection pauses" >> sun.gc.collector.2.name="G1 concurrent cycle pauses" >> >> CMS: >> sun.gc.collector.2.name="CMS concurrent cycle pauses" >> >> ZGC: >> sun.gc.collector.2.name="Z concurrent cycle pauses" >> >> Regards, >> Chihiro >> >> On 2019/01/15 18:49, Thomas Schatzl wrote: >>> Hi Chihiro, >>> >>> On Tue, 2019-01-15 at 02:19 +0900, Chihiro Ito wrote: >>>> Hi, >>>> >>>> Thank you for reviewing and giving ideas. >>>> >>>> I agree to this idea. In addition, I think we should change also >>>> counter names "CMS stop-the-world phases" to "CMS concurrent cycle >>>> pauses" in CMS. >>> fine with me. >>> >>> Thomas >>> >>> >>> >> > From chihiro.ito at oracle.com Wed Jan 16 14:49:19 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Wed, 16 Jan 2019 23:49:19 +0900 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> Message-ID: <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> Hi Thomas, I try to rename for all collections. Regards, Chihiro On 2019/01/16 22:41, Thomas Schatzl wrote: > Hi Chihiro, > > On Wed, 2019-01-16 at 00:30 +0900, Chihiro Ito wrote: >> Hi Thomas and Per, >> >> I fixed counter name in G1, CMS and Z. >> Could you review it ? >> >> http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ >> >> >> For your information, output of PerfCounter.print is following. >> >> G1GC: >> sun.gc.collector.0.name="G1 incremental collection pauses" >> sun.gc.collector.1.name="G1 full collection pauses" >> sun.gc.collector.2.name="G1 concurrent cycle pauses" >> >> CMS: >> sun.gc.collector.2.name="CMS concurrent cycle pauses" >> >> ZGC: >> sun.gc.collector.2.name="Z concurrent cycle pauses" > Fine with me - since we are there, maybe you are interested in > revisiting the names for the other CollectorCounters too? > > I found the following: > > Parallel GC: > > "PSScavenge" > "PSParallelCompact" > "PSMarkSweep" > > CMS: > > "CMS" > "MSC" > > Serial: > > "PCopy" (I have no idea what this is supposed to be; this is serial > young gc) > > We can skip them too if we can't find better names. > > Thanks, > Thomas > > > From per.liden at oracle.com Wed Jan 16 14:59:26 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 16 Jan 2019 15:59:26 +0100 Subject: RFR: 8217258: ZGC: Minor cleanup of ZBarrierSetAssembler Message-ID: <53ca5478-83a6-680f-8541-b8a037ad868f@oracle.com> Minor style/cosmetic cleanups of ZBarrierSetAssembler. Bug: https://bugs.openjdk.java.net/browse/JDK-8217258 Webrev: http://cr.openjdk.java.net/~pliden/8217258/webrev.0 /Per From per.liden at oracle.com Wed Jan 16 14:59:22 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 16 Jan 2019 15:59:22 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 Message-ID: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> Minor style/cosmetic cleanups of ZBarrierSetC2. Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 /Per From thomas.schatzl at oracle.com Wed Jan 16 16:09:53 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Jan 2019 17:09:53 +0100 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: <1547472060.13989.32.camel@redhat.com> References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> <1547140970.13989.6.camel@redhat.com> <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> <1547472060.13989.32.camel@redhat.com> Message-ID: Hi, On Mon, 2019-01-14 at 08:21 -0500, zgu at redhat.com wrote: > Thanks again, Kim. > > > > > > > > > ------------------------------------------------------------------- > > ----------- > > src/hotspot/share/gc/g1/g1ConcurrentMark.hpp > > 733 // Set abort flag if above check fails > > > > Rather than "above", actually refer to regular_clock_call by name. > > I don't need to review again for this. > > Will fix before push. > > > > ------------------------------------------------------------------- > > ----------- > > src/hotspot/share/gc/g1/g1ConcurrentMark.hpp > > 734 inline void abort_marking_if_regular_check_fail(); > > > > I'm not wild about this name, but don't have a better suggestion. > > Maybe another reviewer will suggest something. Otherwise, go > > ahead with this name. My suggestion would be something like "abort_marking_if_regular_clock_call_fails()" which does not make it shorter. It is only a weak suggestion too, so feel free to keep or change it without the need of a re-review. > > May I get a second review? Now the third - looks good. Thanks, Thomas From zgu at redhat.com Wed Jan 16 16:15:21 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 16 Jan 2019 11:15:21 -0500 Subject: RFR(XXS) 8217213: shenandoahTaskQueue.hpp includes .inline.hpp file Message-ID: <1547655321.13989.84.camel@redhat.com> Please review this cleanup that removes include of .inline.hpp in shenandoahTaskQueue.hpp, updates includes in related files that are impacted by the cleanup, and minor style changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8217213 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217213/webrev.00/ Test: PCH and none PCH builds on Linux x64 tier1, 2, 3 gc_shenandoah on Linux x64 Thanks, -Zhengyu From shade at redhat.com Wed Jan 16 16:19:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Jan 2019 17:19:43 +0100 Subject: RFR(XXS) 8217213: shenandoahTaskQueue.hpp includes .inline.hpp file In-Reply-To: <1547655321.13989.84.camel@redhat.com> References: <1547655321.13989.84.camel@redhat.com> Message-ID: <36cc7848-0fbe-cf1b-376d-4d47f56a10eb@redhat.com> On 1/16/19 5:15 PM, zgu at redhat.com wrote: > Please review this cleanup that removes include of .inline.hpp in > shenandoahTaskQueue.hpp, updates includes in related files that are > impacted by the cleanup, and minor style changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217213 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217213/webrev.00/ This looks good to me. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Wed Jan 16 16:21:26 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 16 Jan 2019 11:21:26 -0500 Subject: RFR 8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect In-Reply-To: References: <1546451358.3477.18.camel@redhat.com> <1547040495.3477.54.camel@redhat.com> <1547140970.13989.6.camel@redhat.com> <73F106AF-5474-401C-BC11-BB0130B44DE2@oracle.com> <1547472060.13989.32.camel@redhat.com> Message-ID: <1547655686.13989.85.camel@redhat.com> --------------------------------------------------------------- > > > ---- > > > ----------- > > > src/hotspot/share/gc/g1/g1ConcurrentMark.hpp > > > 734 inline void abort_marking_if_regular_check_fail(); > > > > > > I'm not wild about this name, but don't have a better suggestion. > > > Maybe another reviewer will suggest something. Otherwise, go > > > ahead with this name. > > My suggestion would be something like > "abort_marking_if_regular_clock_call_fails()" which does not make it > shorter. It is only a weak suggestion too, so feel free to keep or > change it without the need of a re-review. > > > > > May I get a second review? > > Now the third - looks good. > Thanks, Thomas. -Zhengyu > Thanks, > Thomas > > From zgu at redhat.com Wed Jan 16 16:22:20 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 16 Jan 2019 11:22:20 -0500 Subject: RFR(XXS) 8217213: shenandoahTaskQueue.hpp includes .inline.hpp file In-Reply-To: <36cc7848-0fbe-cf1b-376d-4d47f56a10eb@redhat.com> References: <1547655321.13989.84.camel@redhat.com> <36cc7848-0fbe-cf1b-376d-4d47f56a10eb@redhat.com> Message-ID: <1547655740.13989.86.camel@redhat.com> Thanks for the review, Aleksey. -Zhengyu On Wed, 2019-01-16 at 17:19 +0100, Aleksey Shipilev wrote: > On 1/16/19 5:15 PM, zgu at redhat.com wrote: > > Please review this cleanup that removes include of .inline.hpp in > > shenandoahTaskQueue.hpp, updates includes in related files that are > > impacted by the cleanup, and minor style changes. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217213 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217213/webrev.00/ > > This looks good to me. > > -Aleksey > From shade at redhat.com Wed Jan 16 17:21:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Jan 2019 18:21:27 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes Message-ID: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8217014 Fix: http://cr.openjdk.java.net/~shade/8217014/webrev.01/ While Epsilon does not do the GC collection cycles, Metadata GC machinery is external to it. Notably, CollectedHeap::satisfy_failed_metadata_allocation would initiate its own VM operation and call CollectedHeap::collect_as_vm_thread(GCCause::_metadata_GC_threshold) inside of it. All other GCs would eventually call MetaspaceGC::compute_new_size during that collection cycle. Epsilon would not, because it currently ignores the GC requests wholesale. Since MetaspaceGC::compute_new_size is not called, metaspace would resize a little, but would re-enter satisfy_failed_metadata_allocation and call for safepoint again rather soon, because the increment was small. You can see that as the flurry of "Metadata GC Threshold" requests ignored by Epsilon. The easy way out is to "handle" the metadata GC requests and call the resize in Epsilon. The change also hooks up Metadata printing to the GC logging, and adds the test that creates lots of classes to verify. The example log for new jtreg test: [0.003s][info][gc] Non-resizeable heap; start/max: 128M [0.003s][info][gc] Using TLAB allocation; max: 4096K [0.003s][info][gc] Elastic TLABs enabled; elasticity: 1.10x [0.003s][info][gc] Elastic TLABs decay enabled; decay time: 1000ms [0.003s][info][gc] Using Epsilon [0.279s][info][gc] Heap: 128M reserved, 128M (100.00%) committed, 6M (5.24%) used [0.945s][info][gc ] Heap: 128M reserved, 128M (100.00%) committed, 39M (30.64%) used [0.945s][info][gc,metaspace] Metaspace: 36M reserved, 15M (44.10%) committed, 14M (40.62%) used [1.225s][info][gc ] GC request for "Metadata GC Threshold" is handled [1.225s][info][gc,metaspace] Metaspace: 38M reserved, 20M (54.73%) committed, 19M (51.48%) used [1.326s][info][gc ] Heap: 128M reserved, 128M (100.00%) committed, 64M (50.17%) used [1.326s][info][gc,metaspace] Metaspace: 40M reserved, 25M (64.18%) committed, 24M (60.64%) used For more realistic example, before the change the startup of springboot-petclinic with Epsilon does 110 (!) "Metadata GC Threshold" requests in first 5 seconds, each of those in its own safepoint. After this change we only do 3 requests, and thus significantly less safepoints. Testing: hotspot tier1, gc/epsilon, jdk-submit, new test Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From erik.osterlund at oracle.com Wed Jan 16 19:21:32 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 16 Jan 2019 20:21:32 +0100 Subject: RFR: 8217258: ZGC: Minor cleanup of ZBarrierSetAssembler In-Reply-To: <53ca5478-83a6-680f-8541-b8a037ad868f@oracle.com> References: <53ca5478-83a6-680f-8541-b8a037ad868f@oracle.com> Message-ID: Hi Per, Looks good. Thanks, /Erik > On 16 Jan 2019, at 15:59, Per Liden wrote: > > Minor style/cosmetic cleanups of ZBarrierSetAssembler. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217258 > Webrev: http://cr.openjdk.java.net/~pliden/8217258/webrev.0 > > /Per From thomas.stuefe at gmail.com Wed Jan 16 20:34:07 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 16 Jan 2019 21:34:07 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> Message-ID: Hi Alexey, looks good. In your test you could set the initial metaspace size to a small size too for added effect, this triggers a lot of resizing early on (eg -XX:MetaspaceSize=1m). nit: EpsilonHeap::print_metaspace_info(): I assume this cannot be called before metaspace is set up. Still, would prefer checking for reserved=0 before printing the percentages. Cheers, Thomas On Wed, Jan 16, 2019 at 6:23 PM Aleksey Shipilev wrote: > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8217014 > > Fix: > http://cr.openjdk.java.net/~shade/8217014/webrev.01/ > > While Epsilon does not do the GC collection cycles, Metadata GC machinery is external to it. > Notably, CollectedHeap::satisfy_failed_metadata_allocation would initiate its own VM operation and > call CollectedHeap::collect_as_vm_thread(GCCause::_metadata_GC_threshold) inside of it. All other > GCs would eventually call MetaspaceGC::compute_new_size during that collection cycle. Epsilon would > not, because it currently ignores the GC requests wholesale. > > Since MetaspaceGC::compute_new_size is not called, metaspace would resize a little, but would > re-enter satisfy_failed_metadata_allocation and call for safepoint again rather soon, because the > increment was small. You can see that as the flurry of "Metadata GC Threshold" requests ignored by > Epsilon. > > The easy way out is to "handle" the metadata GC requests and call the resize in Epsilon. The change > also hooks up Metadata printing to the GC logging, and adds the test that creates lots of classes to > verify. The example log for new jtreg test: > > [0.003s][info][gc] Non-resizeable heap; start/max: 128M > [0.003s][info][gc] Using TLAB allocation; max: 4096K > [0.003s][info][gc] Elastic TLABs enabled; elasticity: 1.10x > [0.003s][info][gc] Elastic TLABs decay enabled; decay time: 1000ms > [0.003s][info][gc] Using Epsilon > [0.279s][info][gc] Heap: 128M reserved, 128M (100.00%) committed, 6M (5.24%) used > [0.945s][info][gc ] Heap: 128M reserved, 128M (100.00%) committed, 39M (30.64%) used > [0.945s][info][gc,metaspace] Metaspace: 36M reserved, 15M (44.10%) committed, 14M (40.62%) used > [1.225s][info][gc ] GC request for "Metadata GC Threshold" is handled > [1.225s][info][gc,metaspace] Metaspace: 38M reserved, 20M (54.73%) committed, 19M (51.48%) used > [1.326s][info][gc ] Heap: 128M reserved, 128M (100.00%) committed, 64M (50.17%) used > [1.326s][info][gc,metaspace] Metaspace: 40M reserved, 25M (64.18%) committed, 24M (60.64%) used > > > For more realistic example, before the change the startup of springboot-petclinic with Epsilon does > 110 (!) "Metadata GC Threshold" requests in first 5 seconds, each of those in its own safepoint. > After this change we only do 3 requests, and thus significantly less safepoints. > > Testing: hotspot tier1, gc/epsilon, jdk-submit, new test > > Thanks, > -Aleksey -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Wed Jan 16 20:59:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Jan 2019 21:59:59 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> Message-ID: Hi, On 1/16/19 9:34 PM, Thomas St?fe wrote: > looks good. Thanks! > In your test you could set the initial metaspace size to a small size too for added effect, this > triggers a lot of resizing early on (eg -XX:MetaspaceSize=1m). Right. I was trying to achieve the same by setting Initial*, but MetaspaceSize is sure better. > nit: EpsilonHeap::print_metaspace_info(): I assume this cannot be called before metaspace is set up. > Still, would prefer checking for reserved=0 before printing the percentages. Nice catch. Checked for zero in both heap and metaspace cases. Also turned both methods private, so we control when they are called from within. New webrev: http://cr.openjdk.java.net/~shade/8217014/webrev.02/ Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kim.barrett at oracle.com Wed Jan 16 21:16:44 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Jan 2019 16:16:44 -0500 Subject: RFR: 8212826: Make PtrQueue free list lock-free In-Reply-To: References: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> Message-ID: <4708F3B8-DC0E-4430-B2EF-1DBCD9D1F479@oracle.com> > On Jan 16, 2019, at 7:55 AM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2019-01-15 at 17:54 -0500, Kim Barrett wrote: >> [?] >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8212826/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8212826/open.01.inc/ >> > > Thanks. Looks good. > > Thomas Thanks. From thomas.stuefe at gmail.com Wed Jan 16 21:38:59 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 16 Jan 2019 22:38:59 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> Message-ID: Looks good to me. Cheers, Thomas On Wed 16. Jan 2019 at 22:00, Aleksey Shipilev wrote: > Hi, > > On 1/16/19 9:34 PM, Thomas St?fe wrote: > > looks good. > > Thanks! > > > In your test you could set the initial metaspace size to a small size > too for added effect, this > > triggers a lot of resizing early on (eg -XX:MetaspaceSize=1m). > > Right. I was trying to achieve the same by setting Initial*, but > MetaspaceSize is sure better. > > > nit: EpsilonHeap::print_metaspace_info(): I assume this cannot be called > before metaspace is set up. > > Still, would prefer checking for reserved=0 before printing the > percentages. > > Nice catch. Checked for zero in both heap and metaspace cases. Also turned > both methods private, so > we control when they are called from within. > > New webrev: > http://cr.openjdk.java.net/~shade/8217014/webrev.02/ > > Thanks, > -Aleksey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Thu Jan 17 09:32:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Jan 2019 10:32:00 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> Message-ID: <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> On 1/16/19 6:21 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8217014 > > Fix: > http://cr.openjdk.java.net/~shade/8217014/webrev.01/ Got an external comment: since we are changing the end-of-run message, it makes sense be to able to print sizes in K, not in M. The simple addendum is to use proper_unit infra for heap/metadata occupancy messages. Hopefully final webrev: http://cr.openjdk.java.net/~shade/8217014/webrev.03/ Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Thu Jan 17 09:33:42 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Jan 2019 10:33:42 +0100 Subject: RFR(XXS) 8217213: shenandoahTaskQueue.hpp includes .inline.hpp file In-Reply-To: <1547655321.13989.84.camel@redhat.com> References: <1547655321.13989.84.camel@redhat.com> Message-ID: <5546b03cf3ae5d4e4e0bdbeecee3649c0320df47.camel@oracle.com> Hi, On Wed, 2019-01-16 at 11:15 -0500, zgu at redhat.com wrote: > Please review this cleanup that removes include of .inline.hpp in > shenandoahTaskQueue.hpp, updates includes in related files that are > impacted by the cleanup, and minor style changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217213 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217213/webrev.00/ > > Test: > PCH and none PCH builds on Linux x64 > tier1, 2, 3 gc_shenandoah on Linux x64 > minor nit: shenandoahVerifier.cpp contains both shenandoahHeap.inline.hpp and shenandoahHeap.hpp. No need to re-review if you intend to do something about this. Looks good otherwise. Thanks, Thomas From thomas.schatzl at oracle.com Thu Jan 17 09:37:22 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Jan 2019 10:37:22 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 In-Reply-To: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> References: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> Message-ID: <0409253a0972d444ceb1eef31b58d63c4b16235b.camel@oracle.com> Hi, On Wed, 2019-01-16 at 15:59 +0100, Per Liden wrote: > Minor style/cosmetic cleanups of ZBarrierSetC2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 > Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 > > /Per cleanups look good. Thomas From thomas.schatzl at oracle.com Thu Jan 17 10:12:38 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Jan 2019 11:12:38 +0100 Subject: RFR(S): 8215934: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <9CE87A68-7C22-4254-8D3F-4DA53A38D160@amazon.com> References: <9CE87A68-7C22-4254-8D3F-4DA53A38D160@amazon.com> Message-ID: Hi, On Wed, 2019-01-09 at 20:41 +0000, Hohensee, Paul wrote: > Thomas reviewed the CSR, so I?ve put it into Finalized state. Thanks > Thomas. > > Please review the backport. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215934 > Webrev: http://cr.openjdk.java.net/~phh/8215934/webrev.00/ > one nit: I do not completely understand the " 30 * @requires vm.opt.MaxGCPauseMillis == "null"" in TestOldGenCollectionUsage.java as the test itself runs in othervm mode anyway. (The vm.gc=="G1" | vm.gc=="null" has traditionally been used to limit the number of invocations of this test, i.e. to not get repeats when running all tests with all collectors. But then the test is in the g1 subdirectory anyway). The MaxGCPauseMillis @requires does not hurt, but seems to serve no real purpose. Looks good. Thomas From thomas.schatzl at oracle.com Thu Jan 17 10:43:40 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Jan 2019 11:43:40 +0100 Subject: record object number in AgeTable for G1 In-Reply-To: References: <035dddcd97da4662b5a7ca96e48d3618@jd.com> <7db97a230694faf65582f88bacf71e5667ac8ef9.camel@oracle.com> Message-ID: <16d3ee1ae9cb586f68ab34a8df51d2cf9534adc9.camel@oracle.com> Hi, On Wed, 2019-01-16 at 01:29 +0000, ?? wrote: > Hi Thomas, > Thanks for your suggestion, I will try to get some performance > number. Btw, do you have any recommendation of the benchmark/micro- > bench for pause time measurement? I would start with a simple JMH benchmark that copies over quite a lot of data.[0] Try to reduce variance in the results by e.g. fixing generation sizes and maxing out region size (to decrease the overhead of allocating new regions). Btw, g1's "Object Copy" phase readings are probably exactly what you want to look at btw. Specjbb2005 [3] pause times tend to also be somewhat sensitive to changes to the evacuation loop. At least it is very reproducible. There are other benchmarks like the DaCapo benchmark [4] (or Scalabench [5]) available, but from a GC POV they tend to be a bit too small for reasonable heap sizes/systems for good measurements. After that, look at Specjbb2015 if you have access to it. A regression in critical-jops would basically be a no-go unless there is significant other gains elsewhere. Note that with current machines (depending on what you have) you probably want to run with quite large configurations to reduce the impact of noise. Before going into this lengthy testing process, that I would like to ask what you think the gain from this information (number of objects per age group) would be? I admit that I once or maybe twice hacked information like this in for some investigations, but it do not remember it yielding interesting enough information to base decisions on it. I always ended up adding more instrumentation, that was way too intrusive for the product... Lastly, there are some procedural issues that we need to cover before we can accept a patch: are you covered by an Oracle Contributor Agreement (either individually or via an employer who is sponsoring this work)? I haven't found your name (that is, the Pinyin for the name you used in this email) so you don't appear to be covered and this needs to be dealt first [1]. Since you also seem to be a first-time contributor, you need a sponsor of the patch to help you with procedural issues (like getting a bug id in the bug tracker). For the actual review, changes of more than some trivial extent generally get packaged for review using the webrev tool, and published on cr.openjdk.java.net [2]. Your sponsor can also help you with that. A sponsor should be someone currently involved in OpenJDK GC development, preferably in an area related to the patch. It's not required that they be an Oracle employee, though for some things that might help. I can help you find someone. (It might be me, but I don't want to commit to that today.) Thanks, Thomas [0] http://openjdk.java.net/projects/code-tools/jmh/ [1] https://openjdk.java.net/contribute/ [2] https://openjdk.java.net/guide/codeReview.html [3] http://www.spec.org/jbb2005/ [4] http://dacapobench.org/ [5] http://scalabench.org/ From zgu at redhat.com Thu Jan 17 13:46:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 08:46:43 -0500 Subject: RFR(XXS) 8217213: shenandoahTaskQueue.hpp includes .inline.hpp file In-Reply-To: <5546b03cf3ae5d4e4e0bdbeecee3649c0320df47.camel@oracle.com> References: <1547655321.13989.84.camel@redhat.com> <5546b03cf3ae5d4e4e0bdbeecee3649c0320df47.camel@oracle.com> Message-ID: <54aa2701-b68e-cacb-83ea-34786992b0bf@redhat.com> Hi Thomas, Thanks for reviewing. > > minor nit: > > shenandoahVerifier.cpp contains both shenandoahHeap.inline.hpp and > shenandoahHeap.hpp. > > No need to re-review if you intend to do something about this. Will fix and retest before push. -Zhengyu > > Looks good otherwise. > > Thanks, > Thomas > From zgu at redhat.com Thu Jan 17 14:12:06 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 09:12:06 -0500 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> Message-ID: <954845ef-7e57-1e03-16eb-00d2bc82af91@redhat.com> Hi Aleksey, > > Got an external comment: since we are changing the end-of-run message, it makes sense be to able to > print sizes in K, not in M. The simple addendum is to use proper_unit infra for heap/metadata > occupancy messages. > > Hopefully final webrev: > http://cr.openjdk.java.net/~shade/8217014/webrev.03/ MetaspaceGC::compute_new_size() seems to be called for every GC cycle, not just metaspace inducted GC cycle, in other GCs. Otherwise, looks good. Thanks, -Zhengyu > > Thanks, > -Aleksey > From shade at redhat.com Thu Jan 17 14:16:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Jan 2019 15:16:01 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: <954845ef-7e57-1e03-16eb-00d2bc82af91@redhat.com> References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> <954845ef-7e57-1e03-16eb-00d2bc82af91@redhat.com> Message-ID: <717ea703-4bb6-2186-a136-7c29eaa1dce2@redhat.com> On 1/17/19 3:12 PM, Zhengyu Gu wrote: >> Hopefully final webrev: >> ?? http://cr.openjdk.java.net/~shade/8217014/webrev.03/ > > MetaspaceGC::compute_new_size() seems to be called for every GC cycle, not just metaspace inducted > GC cycle, in other GCs. Yeah. Epsilon does not do GC cycles, so it only has to react on _metadata_gc_* causes that are invoked from the shared code. Thanks for taking a look! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Thu Jan 17 14:26:34 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 09:26:34 -0500 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: <717ea703-4bb6-2186-a136-7c29eaa1dce2@redhat.com> References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> <954845ef-7e57-1e03-16eb-00d2bc82af91@redhat.com> <717ea703-4bb6-2186-a136-7c29eaa1dce2@redhat.com> Message-ID: <1f432963-086d-355a-c315-bb49925ba82e@redhat.com> On 1/17/19 9:16 AM, Aleksey Shipilev wrote: > On 1/17/19 3:12 PM, Zhengyu Gu wrote: >>> Hopefully final webrev: >>> ?? http://cr.openjdk.java.net/~shade/8217014/webrev.03/ >> MetaspaceGC::compute_new_size() seems to be called for every GC cycle, not just metaspace inducted >> GC cycle, in other GCs. > Yeah. Epsilon does not do GC cycles, so it only has to react on _metadata_gc_* causes that are > invoked from the shared code. Right! Thanks, -Zhengyu > Thanks for taking a look! > > -Aleksey > From zgu at redhat.com Thu Jan 17 14:30:15 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 09:30:15 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <1546530552.3477.31.camel@redhat.com> References: <1546530552.3477.31.camel@redhat.com> Message-ID: <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> Ping! In addition to hotspot_gc tests (+/- UseOWSTTaskTerminator) on Linux 64, also ran vmTestbase_vm_gc (+/- UseOWSTTaskterminator) and submit tests. Thanks, -Zhengyu On 1/3/19 10:49 AM, zgu at redhat.com wrote: > Threads that enter termination protocol, should always see the same > termination result, terminated or aborted. And terminator should > always complete in one of two following states: > > Terminated: _offered_termination == _n_threads (all threads arrived and > terminated) > Aborted: _offered_termination = 0 (none of threads completed) > > Current implementation does not guarantee that, so that, it can leave > terminator in inconsistent states. The inconsistent states can trigger > assertion failure when reset the terminator for reuse (vs. > reset_for_reuse() method) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215047 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.00/index.htm > l > > Test: > > hotspot_gc on Linux x64 (fastdebug and release) > > Thanks, > > -Zhengyu > From thomas.stuefe at gmail.com Thu Jan 17 15:09:37 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Jan 2019 16:09:37 +0100 Subject: RFR (S) 8217014: Epsilon should not ignore Metadata GC causes In-Reply-To: <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> References: <06d8b474-3cfa-7f9a-7732-dd89caa8146c@redhat.com> <14813ba5-2818-9b38-52af-0db5ff2beef2@redhat.com> Message-ID: +1 ..Thomas On Thu, Jan 17, 2019 at 10:32 AM Aleksey Shipilev wrote: > On 1/16/19 6:21 PM, Aleksey Shipilev wrote: > > RFE: > > https://bugs.openjdk.java.net/browse/JDK-8217014 > > > > Fix: > > http://cr.openjdk.java.net/~shade/8217014/webrev.01/ > > Got an external comment: since we are changing the end-of-run message, it > makes sense be to able to > print sizes in K, not in M. The simple addendum is to use proper_unit > infra for heap/metadata > occupancy messages. > > Hopefully final webrev: > http://cr.openjdk.java.net/~shade/8217014/webrev.03/ > > Thanks, > -Aleksey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu at redhat.com Thu Jan 17 15:22:37 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 10:22:37 -0500 Subject: RFR(XXS) 8217213: shenandoahTaskQueue.hpp includes .inline.hpp file In-Reply-To: <54aa2701-b68e-cacb-83ea-34786992b0bf@redhat.com> References: <1547655321.13989.84.camel@redhat.com> <5546b03cf3ae5d4e4e0bdbeecee3649c0320df47.camel@oracle.com> <54aa2701-b68e-cacb-83ea-34786992b0bf@redhat.com> Message-ID: <4da25d69-6dc4-d853-4014-74905c756007@redhat.com> Hi Thomas, >> ? minor nit: >> >> shenandoahVerifier.cpp contains both shenandoahHeap.inline.hpp and >> shenandoahHeap.hpp. >> >> No need to re-review if you intend to do something about this. Found a few more instances, so will fix them in one batch. https://bugs.openjdk.java.net/browse/JDK-8217319 Thanks, -Zhengyu > > Will fix and retest before push. > > -Zhengyu > >> >> Looks good otherwise. >> >> Thanks, >> ?? Thomas >> From leo.korinth at oracle.com Thu Jan 17 15:58:34 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 17 Jan 2019 16:58:34 +0100 Subject: RFR: 8214799: Add package declaration to each JTREG test case in the gc folder In-Reply-To: References: <19bae948-ec2b-257e-d0fc-69ff95093642@oracle.com> <3899785E-F88A-4F4B-8DE7-9002F7835AD3@oracle.com> <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> <2A5A69F0-0995-4E95-8EA9-2F90A4BD5A37@oracle.com> Message-ID: <5acce3ca-6fd1-9024-1946-e4d866d97bbf@oracle.com> Hi, I have added package name to newly added TestPeriodicLogMessages.java. I would be happy for a review from a reviewer (for the whole change, not only this test). The updated test case has been tested. /Leo diff --git a/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java b/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java index 2cede583c45..bd02a6e1c0a 100644 --- a/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java +++ b/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java @@ -21,6 +21,8 @@ * questions. */ +package gc.g1; + /** * @test TestPeriodicLogMessages * @bug 8216490 @@ -29,6 +31,7 @@ * @library /test/lib / * @modules java.base/jdk.internal.misc * @modules java.management/sun.management + * @run main gc.g1.TestPeriodicLogMessages */ import jdk.test.lib.process.OutputAnalyzer; On 14/01/2019 14:43, Leo Korinth wrote: > On 11/01/2019 18:30, Leonid Mesnik wrote: >> Hi >> >> The changes look good to me. Thanks for fixing all this.? Please note >> that I am not a 'R'eviewer. >> >> Leonid > > Thank you Leonid for your (committer) review and suggestions for > improvement. > > /Leo > >>> On Jan 11, 2019, at 8:54 AM, Leo Korinth wrote: >>> >>> Hi again! >>> >>> New webrev, no incremental this time either as I have changed all >>> copyright years, all library annotations, and several new tests have >>> been rebased. >>> >>> Changes since last time: >>> 1) The bad rebase artifact (bad rebase of moved file) >>> CriticalNativeStress.java is now removed. I still left the small >>> refactoring to a Java JNI "mirror" class as I think it is nicer than >>> the old solution with several Java files in different packages >>> mapping to the same JNI file. >>> 2) All relative @library lines now uses the absolute "/" that will >>> improve future refactoring. I still have them on separate lines if >>> several paths are used -- my reason is that they diff better. >>> 3) All new test cases in the new directory nvdimm have been fixed >>> 4) A new test in directory epsilon has been fixed >>> 5) All (Oracle) copyright years have been updated to 2019, I did not >>> bother to add Oracle copyrights to the Epsilon/Shenandoah sources as >>> my contribution is insignificant. >>> 6) Shenandoah has landed, but I will not update all those test cases, >>> I made this webrev too large already. I have tried to update all >>> Shenandoah test cases that are located outside the shenendoah folder >>> though. >>> >>> (New) Webrev: >>> http://cr.openjdk.java.net/~lkorinth/8214799/02/ >>> >>> Testing: >>> open/test/hotspot/jtreg/:hotspot_gc >>> >>> Thanks, >>> Leo >>> >>> >>> On 22/12/2018 12:10, Leo Korinth wrote: >>>> Hi! >>>> On 21/12/2018 21:50, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Great change. The only a couple of comments >>>>> >>>>> 1) I see that you added a lot of relative links to include >>>>> test-root as library like: >>>>> >>>>> 32? * @library ../../.. >>>>> >>>>> >>>>> I think you might want to use >>>>> ?? @library? > or add to existing library test/lib like >>>>> @library /test/lib / >>>>> >>>>> instead. You might find a lot of examples in existing compiler and >>>>> gc tests. >>>>> >>>>> It is the more common an unified approach? rather then using >>>>> relative paths. Also it allows you to don't care when you move >>>>> tests in different packages. >>>>> >>>> I will try that, it is certainly better. I think I will use a new >>>> @library line though, it is easier to see the change. >>>>> >>>>> 2) New test in >>>>> http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.new.java.html >>>>> >>>>> looks confusing to me. It is copied from >>>>> http://cr.openjdk.java.net/~lkorinth/8214799/01/test/hotspot/jtreg/gc/stress/CriticalNativeStress.new.java.html >>>>> >>>>> >>>>> So now we have test CriticalNativeStress >>>>> gc/epsilon/CriticalNativeStress.java and >>>>> CriticalNativeStressEpsilon in gc/stress/CriticalNativeStress.java >>>>> The code in both files and jtreg tags looks pretty similar. Have >>>>> you added it intentionally? Could you please explain a little bit >>>>> purpose of this. >>>> Many thanks for finding this fault of mine. The file was moved with >>>> the Shenandoah push, and I must have rebased it badly although the >>>> move of the corresponding c-file went through, strange... >>>>> Other changes looks good. >>>>> >>>> Thanks for taking a look at it! >>>> I will create a new webrev after the holiday. >>>> /Leo >>>>> Leonid >>>>>> On Dec 21, 2018, at 11:32 AM, Leo Korinth >>>>> > wrote: >>>>>> >>>>>> Hi again! >>>>>> >>>>>> I am adding Leonid and Erik to the discussion to see if my package >>>>>> additions are in any way troublesome to the bigger picture. I >>>>>> believe they are not. We are already using Java packages in some >>>>>> tests; this change will just add them to more tests so that one >>>>>> can easily use an IDE. >>>>>> >>>>>> Please ignore the old webrev as I had to rebase against the resent >>>>>> Shenandoah push. It is easier to just read this version >>>>>> (http://cr.openjdk.java.net/~lkorinth/8214799/01/). Unfortunately >>>>>> no incremental version is given as this is a rebase. >>>>>> >>>>>> I have not had the time to update the test cases under the >>>>>> gc/shenandoah folder (I am also afraid to make this change any >>>>>> bigger), but I have tried to update the test cases that changed or >>>>>> was added by the Shenandoah push (some Epsilon and Shenandoah >>>>>> tests outside the gc/shenandoah folder). >>>>>> >>>>>> This rebase basically applies the same kind of changes to the >>>>>> added test cases. One change that I would like you to look more >>>>>> carefully at is the addition of a helper class CriticalNative.java >>>>>> that uses JNI. Without this refactoring I could not have used the >>>>>> same c-file as it was used in different packages (it is used from >>>>>> three different test cases, and the package is part of the JNI >>>>>> export name). Please take an extra look at that change. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~lkorinth/8214799/01/ >>>>>> >>>>>> Testing: >>>>>> I have run jtreg tests under gc/epsilon and I have run :hotspot_gc >>>>>> with Shenandoah in order not to break those test cases. >>>>>> >>>>>> Also started new run of tier1-3 and :hotspot_gc >>>>>> >>>>>> Thanks, >>>>>> Leo >>>>>> >>>>>> On 05/12/2018 14:44, Leo Korinth wrote: >>>>>>> Hi, >>>>>>> I have added package declarations to all jtreg tests in the gc >>>>>>> folder (and sub folders). Previously most tests were not in a >>>>>>> package (though some where), making it extremely hard to work >>>>>>> with jtreg tests in an IDE. >>>>>>> The main change consists of adding a package declaration that >>>>>>> corresponds to the directory the test is located in. This also >>>>>>> makes it necessary to change @run annotations. Some test cases >>>>>>> uses "common" code that is not located in the test lib. Those >>>>>>> test cases now need to have a @library annotation that references >>>>>>> the jtreg test root. >>>>>>> A few test cases had package visible classes with the same name >>>>>>> in the same directory. That did work before, but does not work >>>>>>> anymore, so I have prefixed those package visible classes with >>>>>>> the public class name. >>>>>>> class TestVerifySilentlyRunSystemGC >>>>>>> class TestVerifySubSetRunSystemGC >>>>>>> class TestEagerReclaimHumongousRegionsReclaimRegionFast >>>>>>> class TestEagerReclaimHumongousRegionsClearMarkBitsReclaimRegionFast >>>>>>> class TestEagerReclaimHumongousRegionsWithRefsReclaimRegionFast >>>>>>> Where classes have been referenced using string literals, I have >>>>>>> tried to use a .class.getName() instead (where possible). >>>>>>> I have tried to update copyrights to all files (also adding a >>>>>>> missing comma after the second year in some files), and I did add >>>>>>> missing copyright to TestFromCardCacheIndex. >>>>>>> known cons: >>>>>>> - needs a package line in each java file >>>>>>> - needs an extra library line in the test if the test is using >>>>>>> other files. >>>>>>> - sometimes needs a run tag >>>>>>> improvements: >>>>>>> + can use eclipse or other IDEs without creating a workspace per >>>>>>> test (I guess it will be a significant improvement for users of >>>>>>> emacs and vi as well) >>>>>>> + can use test files located in other directories >>>>>>> After this change, I have several big cleanups that are easy to >>>>>>> do with a working IDE. >>>>>>> Enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214799 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~lkorinth/8214799/00/ >>>>>>> Testing: >>>>>>> passed: >>>>>>> mach5 remote-build-and-test --build-profiles >>>>>>> linux-x64,linux-x64-debug,macosx-x64,solaris-sparcv9,windows-x64 >>>>>>> --test open/test/hotspot/jtreg/:hotspot_gc >>>>>>> now running: >>>>>>> mach5 remote-test --build-id 2018-12-05-1132377.leo.korinth.hs >>>>>>> --build-profiles linux-x64-debug -j tier1,tier2,tier3 >>>>>>> Thanks, >>>>>>> Leo >>>>> >> From zgu at redhat.com Thu Jan 17 16:53:47 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 11:53:47 -0500 Subject: RFR(T) 8217319: Cleanup Shenandoah includes Message-ID: Please review this trivial cleanup, that removes includes of .hpp files if corresponding .inline.hpp files are also included. Bug: https://bugs.openjdk.java.net/browse/JDK-8217319 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217319/webrev.00/ Test: PCH and none PCH builds tier1, 2, 3 gc_shenandoah on Linux x64 Thanks, -Zhengyu From shade at redhat.com Thu Jan 17 16:55:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Jan 2019 17:55:29 +0100 Subject: RFR(T) 8217319: Cleanup Shenandoah includes In-Reply-To: References: Message-ID: <7b7a1659-f6f1-81fb-3b4b-bd679216cf58@redhat.com> On 1/17/19 5:53 PM, Zhengyu Gu wrote: > Please review this trivial cleanup, that removes includes of .hpp files if corresponding .inline.hpp > files are also included. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217319 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217319/webrev.00/ Looks good! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From leo.korinth at oracle.com Thu Jan 17 16:58:03 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 17 Jan 2019 17:58:03 +0100 Subject: 8217329: JTREG: Clean up, remove unused imports in gc folder Message-ID: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> Hi, This fix removes unused imports and newlines in the jtreg/gc folder. This fix is somewhat based/dependent on "8214799: Add package declaration to each JTREG test case in the gc folder". That fix is out for review. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8217329 Webrev: http://cr.openjdk.java.net/~lkorinth/8217329/00 Testing: passed locally: open/test/hotspot/jtreg/:hotspot_gc Thanks, Leo From claes.redestad at oracle.com Thu Jan 17 17:12:54 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Jan 2019 18:12:54 +0100 Subject: RFR: 8217325: Enable inlining of java_lang_Class::oop_size_raw Message-ID: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> Hi, InstanceMirrorKlass::oop_size could be helped slightly if java_lang_Class::oop_size_raw was made inlineable. This significantly speeds up one branch in oopDesc::size_given_klass (heavily used by G1, at least during startup/warmup) while not causing any increase in binary size (linux x64). Bug: https://bugs.openjdk.java.net/browse/JDK-8217325 Webrev: http://cr.openjdk.java.net/~redestad/8217325/open.00/ Testing: tier1-2 (complete) Thanks! /Claes From zgu at redhat.com Thu Jan 17 17:13:59 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 17 Jan 2019 12:13:59 -0500 Subject: RFR(T) 8217319: Cleanup Shenandoah includes In-Reply-To: <7b7a1659-f6f1-81fb-3b4b-bd679216cf58@redhat.com> References: <7b7a1659-f6f1-81fb-3b4b-bd679216cf58@redhat.com> Message-ID: <92d28825-095b-7838-d87f-6e5cb6769e8d@redhat.com> Thanks, Aleksey -Zhengyu On 1/17/19 11:55 AM, Aleksey Shipilev wrote: > On 1/17/19 5:53 PM, Zhengyu Gu wrote: >> Please review this trivial cleanup, that removes includes of .hpp files if corresponding .inline.hpp >> files are also included. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217319 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217319/webrev.00/ > > Looks good! > > -Aleksey > From shade at redhat.com Thu Jan 17 17:23:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Jan 2019 18:23:38 +0100 Subject: RFR: 8217325: Enable inlining of java_lang_Class::oop_size_raw In-Reply-To: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> References: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> Message-ID: On 1/17/19 6:12 PM, Claes Redestad wrote: > Hi, > > InstanceMirrorKlass::oop_size could be helped slightly if > java_lang_Class::oop_size_raw was made inlineable. > > This significantly speeds up one branch in oopDesc::size_given_klass > (heavily used by G1, at least during startup/warmup) while not causing > any increase in binary size (linux x64). > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217325 > Webrev: http://cr.openjdk.java.net/~redestad/8217325/open.00/ Looks good. I remember seeing the profiles for Shenandoah that walks the objects and uses oopDesc::size* heavily, and it was inlined in product builds. That said, inlining it manually does not hurt. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From leonid.mesnik at oracle.com Thu Jan 17 22:41:45 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 17 Jan 2019 14:41:45 -0800 Subject: 8217329: JTREG: Clean up, remove unused imports in gc folder In-Reply-To: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> References: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> Message-ID: <668E59CD-8B83-487E-9DC9-6D911E8D0B23@oracle.com> Hi Fix looks good. (I haven't checked manually if removed imports are really used though. Running tests should enough.) Please get also 'R'eview from 'R'eviewer. Leonid > On Jan 17, 2019, at 8:58 AM, Leo Korinth wrote: > > Hi, > > This fix removes unused imports and newlines in the jtreg/gc folder. > > This fix is somewhat based/dependent on "8214799: Add package declaration to each JTREG test case in the gc folder". That fix is out for review. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8217329 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8217329/00 > > Testing: > passed locally: open/test/hotspot/jtreg/:hotspot_gc > > Thanks, > Leo From leo.korinth at oracle.com Fri Jan 18 08:57:02 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 18 Jan 2019 09:57:02 +0100 Subject: 8217329: JTREG: Clean up, remove unused imports in gc folder In-Reply-To: <668E59CD-8B83-487E-9DC9-6D911E8D0B23@oracle.com> References: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> <668E59CD-8B83-487E-9DC9-6D911E8D0B23@oracle.com> Message-ID: <932513e4-6c01-bddc-f152-9fbbdd5e016d@oracle.com> On 17/01/2019 23:41, Leonid Mesnik wrote: > Hi > > Fix looks good. (I haven't checked manually if removed imports are really used though. Running tests should enough.) Please get also 'R'eview from 'R'eviewer. Thanks for your review Leonid. /Leo > > Leonid > >> On Jan 17, 2019, at 8:58 AM, Leo Korinth wrote: >> >> Hi, >> >> This fix removes unused imports and newlines in the jtreg/gc folder. >> >> This fix is somewhat based/dependent on "8214799: Add package declaration to each JTREG test case in the gc folder". That fix is out for review. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8217329 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8217329/00 >> >> Testing: >> passed locally: open/test/hotspot/jtreg/:hotspot_gc >> >> Thanks, >> Leo > From leo.korinth at oracle.com Fri Jan 18 09:11:22 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 18 Jan 2019 10:11:22 +0100 Subject: RFR: 8217332: JTREG: Clean up, use generics instead of raw types Message-ID: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> Hi, This webrev fixes lack of generics usage in the jtreg/gc folder. This fix is somewhat based/dependent on "8214799: Add package declaration to each JTREG test case in the gc folder". That fix is out for review. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8217332 Webrev: http://cr.openjdk.java.net/~lkorinth/8217332/00 Testing: passed locally: open/test/hotspot/jtreg/:hotspot_gc Thanks, Leo From shade at redhat.com Fri Jan 18 12:28:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 18 Jan 2019 13:28:07 +0100 Subject: RFR (S) 8217343: Shenandoah control thread should be able to run at critical priority Message-ID: <027c5c31-a801-047a-ebeb-ad61ca23953f@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8217343 Fix: http://cr.openjdk.java.net/~shade/8217343/webrev.01/ This allows for elevated thread priority for Shenandoah control thread. The change depends on JDK-8217378 fixed first. Testing: hotspot_gc_shenandoah, new test Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Fri Jan 18 12:41:53 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 18 Jan 2019 13:41:53 +0100 Subject: RFR (S) 8217343: Shenandoah control thread should be able to run at critical priority In-Reply-To: <027c5c31-a801-047a-ebeb-ad61ca23953f@redhat.com> References: <027c5c31-a801-047a-ebeb-ad61ca23953f@redhat.com> Message-ID: <548fcb09-8413-5e2d-a9b1-9cb8ee52bb47@redhat.com> Looks good to me. Thanks! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8217343 > > Fix: > http://cr.openjdk.java.net/~shade/8217343/webrev.01/ > > This allows for elevated thread priority for Shenandoah control thread. The change depends on > JDK-8217378 fixed first. > > Testing: hotspot_gc_shenandoah, new test > > Thanks, > -Aleksey > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Fri Jan 18 13:31:30 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Jan 2019 14:31:30 +0100 Subject: RFR (XXS): 8217374: Rename G1 EvacuationInfo class to G1EvacuationInfo Message-ID: Hi all, can I have reviews for this small change that makes the EvacuationInfo class/files correspond to the naming scheme we should use in collector specific directories? CR: https://bugs.openjdk.java.net/browse/JDK-8217374 Webrev: http://cr.openjdk.java.net/~tschatzl/8217374/webrev/ testing: local compilation Thanks, Thomas From zanglin5 at jd.com Fri Jan 18 13:48:24 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Fri, 18 Jan 2019 13:48:24 +0000 Subject: record object number in AgeTable for G1 In-Reply-To: <16d3ee1ae9cb586f68ab34a8df51d2cf9534adc9.camel@oracle.com> References: <035dddcd97da4662b5a7ca96e48d3618@jd.com> <7db97a230694faf65582f88bacf71e5667ac8ef9.camel@oracle.com> <16d3ee1ae9cb586f68ab34a8df51d2cf9534adc9.camel@oracle.com> Message-ID: <4129f4238a16499f871910c3f202ee10@jd.com> Hi Thomas, Thanks a lot for your suggestion. Yes, the mainly purpose of this change is to calculate the distribution of objects at each age, after rethink of it , I agree with you that this change is more like an instrumentation for profiling rather than feature for product, and it more or less takes effect of the pause time, since most of the change works in g1 pause phase. So I think it may not be necessary to have a patch for it. And thanks a lot for the info of measuring GC performance, I will use it for performance evaluation of my future changes in GC. BTW, My company (JD.COM or Beijing Wodong Tianjun Information Technology Co. Ltd) has signed the OCA. So I may have more discussion or patches related with GC in future. BRs, Lin -----Original Message----- From: Thomas Schatzl Sent: Thursday, January 17, 2019 6:44 PM To: ?? ; hotspot-gc-dev at openjdk.java.net Subject: Re: record object number in AgeTable for G1 Hi, On Wed, 2019-01-16 at 01:29 +0000, ?? wrote: > Hi Thomas, > Thanks for your suggestion, I will try to get some performance > number. Btw, do you have any recommendation of the benchmark/micro- > bench for pause time measurement? I would start with a simple JMH benchmark that copies over quite a lot of data.[0] Try to reduce variance in the results by e.g. fixing generation sizes and maxing out region size (to decrease the overhead of allocating new regions). Btw, g1's "Object Copy" phase readings are probably exactly what you want to look at btw. Specjbb2005 [3] pause times tend to also be somewhat sensitive to changes to the evacuation loop. At least it is very reproducible. There are other benchmarks like the DaCapo benchmark [4] (or Scalabench [5]) available, but from a GC POV they tend to be a bit too small for reasonable heap sizes/systems for good measurements. After that, look at Specjbb2015 if you have access to it. A regression in critical-jops would basically be a no-go unless there is significant other gains elsewhere. Note that with current machines (depending on what you have) you probably want to run with quite large configurations to reduce the impact of noise. Before going into this lengthy testing process, that I would like to ask what you think the gain from this information (number of objects per age group) would be? I admit that I once or maybe twice hacked information like this in for some investigations, but it do not remember it yielding interesting enough information to base decisions on it. I always ended up adding more instrumentation, that was way too intrusive for the product... Lastly, there are some procedural issues that we need to cover before we can accept a patch: are you covered by an Oracle Contributor Agreement (either individually or via an employer who is sponsoring this work)? I haven't found your name (that is, the Pinyin for the name you used in this email) so you don't appear to be covered and this needs to be dealt first [1]. Since you also seem to be a first-time contributor, you need a sponsor of the patch to help you with procedural issues (like getting a bug id in the bug tracker). For the actual review, changes of more than some trivial extent generally get packaged for review using the webrev tool, and published on cr.openjdk.java.net [2]. Your sponsor can also help you with that. A sponsor should be someone currently involved in OpenJDK GC development, preferably in an area related to the patch. It's not required that they be an Oracle employee, though for some things that might help. I can help you find someone. (It might be me, but I don't want to commit to that today.) Thanks, Thomas [0] http://openjdk.java.net/projects/code-tools/jmh/ [1] https://openjdk.java.net/contribute/ [2] https://openjdk.java.net/guide/codeReview.html [3] http://www.spec.org/jbb2005/ [4] http://dacapobench.org/ [5] http://scalabench.org/ From claes.redestad at oracle.com Fri Jan 18 16:03:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Jan 2019 17:03:45 +0100 Subject: RFR: 8217387: Remove dead develop flag CIFireOOMAt Message-ID: Hi, the develop flag CIFireOOMAt is effectively dead and should be removed. Webrev: http://cr.openjdk.java.net/~redestad/8217387/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217387 Thanks! /Claes From shade at redhat.com Fri Jan 18 16:01:04 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 18 Jan 2019 17:01:04 +0100 Subject: RFR: 8217387: Remove dead develop flag CIFireOOMAt In-Reply-To: References: Message-ID: <03f5e7bf-bb4c-a4bd-c959-1ad3c754f130@redhat.com> On 1/18/19 5:03 PM, Claes Redestad wrote: > the develop flag CIFireOOMAt is effectively dead and should be removed. > > Webrev: http://cr.openjdk.java.net/~redestad/8217387/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217387 Looks good. There are indeed no "write" usages. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From leo.korinth at oracle.com Fri Jan 18 16:00:30 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 18 Jan 2019 17:00:30 +0100 Subject: RFR: 8217385: JTREG: Clean up, make sure to close resources Message-ID: Hi, This clean up closes resources in some test cases in the jtreg/gc folder. This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8217385 Webrev: http://cr.openjdk.java.net/~lkorinth/8217385/00 Testing: passed locally: open/test/hotspot/jtreg/:hotspot_gc Thanks, Leo From claes.redestad at oracle.com Fri Jan 18 16:10:08 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Jan 2019 17:10:08 +0100 Subject: RFR: 8217387: Remove dead develop flag CIFireOOMAt In-Reply-To: <03f5e7bf-bb4c-a4bd-c959-1ad3c754f130@redhat.com> References: <03f5e7bf-bb4c-a4bd-c959-1ad3c754f130@redhat.com> Message-ID: On 2019-01-18 17:01, Aleksey Shipilev wrote: > Looks good. There are indeed no "write" usages. Thanks! /Claes From leo.korinth at oracle.com Fri Jan 18 17:23:43 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 18 Jan 2019 18:23:43 +0100 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings Message-ID: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> Hi, Here I am removing warnings for unused variables. Some variables can not be removed as in the case of creating a new primitive array without assigning it to a variable. It is not allowed, in those cases I use @SuppressWarnings("unused"). In some cases the variable is not used at all, and I remove it, but still add the variable name as a comment after the expression, as the variable name might have helped as documentation. I also just commented out "final int CONSTANT_Unicode = 2;" if that information might be useful in the future, it is a constant that we do not expect in the test case. Otherwise I just try to remove the code. This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8217389 Webrev: http://cr.openjdk.java.net/~lkorinth/8217389/00 Testing: passed locally: open/test/hotspot/jtreg/:hotspot_gc Thanks, Leo From hohensee at amazon.com Fri Jan 18 20:43:15 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Jan 2019 20:43:15 +0000 Subject: RFR (XXS): 8217374: Rename G1 EvacuationInfo class to G1EvacuationInfo In-Reply-To: References: Message-ID: <4B15FFC9-CEF6-4A38-8B05-7A8DF7CC905B@amazon.com> Looks good. Paul ?On 1/18/19, 5:32 AM, "hotspot-gc-dev on behalf of Thomas Schatzl" wrote: Hi all, can I have reviews for this small change that makes the EvacuationInfo class/files correspond to the naming scheme we should use in collector specific directories? CR: https://bugs.openjdk.java.net/browse/JDK-8217374 Webrev: http://cr.openjdk.java.net/~tschatzl/8217374/webrev/ testing: local compilation Thanks, Thomas From hohensee at amazon.com Fri Jan 18 21:06:36 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Jan 2019 21:06:36 +0000 Subject: RFR(S): 8215934: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <9CE87A68-7C22-4254-8D3F-4DA53A38D160@amazon.com> Message-ID: Thank you for your review, Thomas. I used TestLogging.java in the same directory as a template for TestOldGenCollectionUsage.java. I'd expect that running all the gc tests directly from jtreg would try to run these, but I'm not a jtreg expert so I'm not certain. The tests in the parent directory that run othervm include "@requires vm.gc.G1". @requires vm.opt.MaxGCPauseMillis == "null" could go away, it's a copy-paste artifact. TestLogging.java looks to need to override MaxGCPauseMillis, but TestOldGenCollectionUsage.java doesn't. I'll file a separate (trivial) RFE to fix that in tip and backport it. Paul ?On 1/17/19, 2:13 AM, "Thomas Schatzl" wrote: Hi, On Wed, 2019-01-09 at 20:41 +0000, Hohensee, Paul wrote: > Thomas reviewed the CSR, so I?ve put it into Finalized state. Thanks > Thomas. > > Please review the backport. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215934 > Webrev: http://cr.openjdk.java.net/~phh/8215934/webrev.00/ > one nit: I do not completely understand the " 30 * @requires vm.opt.MaxGCPauseMillis == "null"" in TestOldGenCollectionUsage.java as the test itself runs in othervm mode anyway. (The vm.gc=="G1" | vm.gc=="null" has traditionally been used to limit the number of invocations of this test, i.e. to not get repeats when running all tests with all collectors. But then the test is in the g1 subdirectory anyway). The MaxGCPauseMillis @requires does not hurt, but seems to serve no real purpose. Looks good. Thomas From leonid.mesnik at oracle.com Fri Jan 18 21:24:14 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 18 Jan 2019 13:24:14 -0800 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> Message-ID: Leo 1. http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java.udiff.html I am not sure how your changes make code clear. Also '128*M' should have spaces. > On Jan 18, 2019, at 9:23 AM, Leo Korinth wrote: > > Hi, > > Here I am removing warnings for unused variables. > > Some variables can not be removed as in the case of creating a new primitive array without assigning it to a variable. It is not allowed, in those cases I use @SuppressWarnings("unused"). > I think that it would be better to really use these variables somehow. The hotspot compilers might also optimize such arrays initialization since results are not used. The tests like this http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/cslocker/TestCSLocker.java just silently pass without any memory allocation and actual testing. I think it would be better to change this variables to be public static and/or be used by some external stuff (print zero/last element as example). It guarantee that compiler can't remove this allocation as a dead code. See following test as example: http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/gc/TestMemoryInitialization.java Might be some library helper which produce some amount off garbage is useful. There are already a lot of methods to produce garbage here but they seems to be overcomplicated. Not sure it make sense to reuse them. http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp Leonid > In some cases the variable is not used at all, and I remove it, but still add the variable name as a comment after the expression, as the variable name might have helped as documentation. I also just commented out "final int CONSTANT_Unicode = 2;" if that information might be useful in the future, it is a constant that we do not expect in the test case. > > Otherwise I just try to remove the code. > > This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8217389 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8217389/00 > > Testing: > passed locally: open/test/hotspot/jtreg/:hotspot_gc > > Thanks, > Leo -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Sat Jan 19 07:26:23 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Fri, 18 Jan 2019 23:26:23 -0800 Subject: RFR: 8212826: Make PtrQueue free list lock-free In-Reply-To: <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> References: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> Message-ID: Hi Kim, On 1/15/19 2:54 PM, Kim Barrett wrote: >> On Jan 15, 2019, at 9:13 AM, Thomas Schatzl wrote: >> >> Hi Kim, >> >> On Wed, 2019-01-09 at 16:48 -0500, Kim Barrett wrote: >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8212826 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8212826/open.00/ >>> >> - ptrQueue.cpp:121: >> >> size_zero seems to be unused, and size_one can be avoided completely by >> using Atomic::inc/dec instead of add/sub which I would prefer. >> >> Even if you kept add/sub, hardcoding (size_t)1 would be less code than >> the constant declaration as there are not many uses. > Can?t use inc/dec, because the incremented values are used, and those functions > don?t return anything. But it seems that I forgot that Erik and I managed to slip in > a bit of argument canonicalization here, so that an exact type match isn?t required; > just using ?1u? works. > >> - test_ptrQueueBufferAllocator.cpp copyright should be "2018, 2019," >> instead of just 2019. > Oops. Fixed. > >> - the gtest adds a small API for testing and comparison should be part >> of the test. It honestly seems to add nothing to the final test other >> than adding additional code, particularly because the other variants >> mentioned in the comment are not there. So I would prefer to flatten >> the FreeListPtrQueueBufferAllocator/FreeListPtrQueueBufferCompletedList >> classes. > Done, with a bit more cleanup. > >> Looks good otherwise. > Thanks. > > Note that I?ve filed a bug against Solaris Studio for the problem with > using pointers to data members. I?ll file a JDK RFE to change > LockFreeStack to the preferred form once the Solaris Studio bug is > fixed and we?re no longer supporting versions with the bug. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8212826/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8212826/open.01.inc/ 01 looks good. FYI, 4 files failed(ptrQueue.hpp, logTag.hpp padded.hpp mutexLocker.hpp) to apply because the copyright year is already updated. Actual codes were applied cleanly. I don't need a webrev for this change. Thanks, Sangheon > > From sangheon.kim at oracle.com Sat Jan 19 15:17:18 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Sat, 19 Jan 2019 07:17:18 -0800 Subject: RFR(trivial): 8213695: gc/TestAllocateHeapAtMultiple.java is slow in some configs In-Reply-To: References: Message-ID: <23c18091-d58a-c260-dd5d-8ff8fa2403fb@oracle.com> Hi Kishor, Sending to 'hotspot-gc-dev' as well. On 1/17/19 6:42 PM, Kharbas, Kishor wrote: > > Greetings, > > I ran this test multiple times on Linux & Windows and the tests > complete in less than a second. However, I do not have a sparc system > to test (if I am correct, earlier discussion pointed that timeout > issue is seen on sparc). > > My guess of what is happening is ? For testing purposes we use the > file system of the test directory, instead of a dax filesystem for > nv-dimm. With the AllocateHeapAt flag set, heap memory is mapped to a > temporary file in the test directory. Depending on the test > environment (filesystem, memory, disk, etc), heap memory access might > be quite slower. > > So I think we should decrease the heap size of the tests. The 5th & > 6th subtests can be changed to use 32M instead of 4G. The 4^th subtest > can be removed. > > Here is the patch with the changes - > http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ > > Looks good to me. And I can sponsor this patch, but we need a review from a (R)eviewer. FYI, I tested the patch on sparc machines(same kind of machines which reported the problem) for 40 times and its run time was mostly less than 3 seconds. Thanks, Sangheon > Hopefully someone can test whether this change makes the run time > deterministic. > > Thanks, > > Kishor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Sat Jan 19 23:37:58 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 19 Jan 2019 18:37:58 -0500 Subject: RFR(trivial): 8213695: gc/TestAllocateHeapAtMultiple.java is slow in some configs In-Reply-To: <23c18091-d58a-c260-dd5d-8ff8fa2403fb@oracle.com> References: <23c18091-d58a-c260-dd5d-8ff8fa2403fb@oracle.com> Message-ID: <6A099E86-33C6-4C94-8228-6F962D3715DF@oracle.com> > On Jan 19, 2019, at 10:17 AM, sangheon.kim at oracle.com wrote: > > Hi Kishor, > > Sending to 'hotspot-gc-dev' as well. > > On 1/17/19 6:42 PM, Kharbas, Kishor wrote: >> Greetings, >> >> I ran this test multiple times on Linux & Windows and the tests complete in less than a second. However, I do not have a sparc system to test (if I am correct, earlier discussion pointed that timeout issue is seen on sparc). >> >> My guess of what is happening is ? For testing purposes we use the file system of the test directory, instead of a dax filesystem for nv-dimm. With the AllocateHeapAt flag set, heap memory is mapped to a temporary file in the test directory. Depending on the test environment (filesystem, memory, disk, etc), heap memory access might be quite slower. >> >> So I think we should decrease the heap size of the tests. The 5th & 6th subtests can be changed to use 32M instead of 4G. The 4th subtest can be removed. >> >> Here is the patch with the changes - http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ > Looks good to me. > And I can sponsor this patch, but we need a review from a (R)eviewer. > > FYI, I tested the patch on sparc machines(same kind of machines which reported the problem) for 40 times and its run time was mostly less than 3 seconds. Looks good. From kim.barrett at oracle.com Sat Jan 19 23:44:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 19 Jan 2019 18:44:09 -0500 Subject: RFR: 8212826: Make PtrQueue free list lock-free In-Reply-To: References: <1f5c95c09919bef04f2773324c2478d516b4448c.camel@oracle.com> <290A5973-68EA-4308-9AB7-0AAF88F3F988@oracle.com> Message-ID: > On Jan 19, 2019, at 2:26 AM, sangheon.kim at oracle.com wrote: >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8212826/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8212826/open.01.inc/ > 01 looks good. Thanks. > FYI, 4 files failed(ptrQueue.hpp, logTag.hpp padded.hpp mutexLocker.hpp) to apply because the copyright year is already updated. > Actual codes were applied cleanly. I don't need a webrev for this change. Yeah. I should get one of those copyright updater scripts various people use, so I can deal with it just before pushing. Of course, this year there will be much less of a need for updates, since Coleen has already touched most .hpp files. From kim.barrett at oracle.com Sun Jan 20 00:29:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 19 Jan 2019 19:29:22 -0500 Subject: RFR (XXS): 8217374: Rename G1 EvacuationInfo class to G1EvacuationInfo In-Reply-To: References: Message-ID: > On Jan 18, 2019, at 8:31 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this small change that makes the > EvacuationInfo class/files correspond to the naming scheme we should > use in collector specific directories? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217374 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217374/webrev/ > testing: > local compilation > > Thanks, > Thomas Looks good. From kim.barrett at oracle.com Sun Jan 20 00:37:43 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 19 Jan 2019 19:37:43 -0500 Subject: RFR: 8217387: Remove dead develop flag CIFireOOMAt In-Reply-To: References: Message-ID: > On Jan 18, 2019, at 11:03 AM, Claes Redestad wrote: > > Hi, > > the develop flag CIFireOOMAt is effectively dead and should be removed. > > Webrev: http://cr.openjdk.java.net/~redestad/8217387/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217387 > > Thanks! > > /Claes Looks good. From claes.redestad at oracle.com Sun Jan 20 00:41:58 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 20 Jan 2019 01:41:58 +0100 Subject: RFR: 8217387: Remove dead develop flag CIFireOOMAt In-Reply-To: References: Message-ID: On 2019-01-20 01:37, Kim Barrett wrote: > Looks good. Thanks, Kim! /Claes From shade at redhat.com Sun Jan 20 09:10:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 20 Jan 2019 10:10:34 +0100 Subject: RFR [URGENT] (XS) 8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free) Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8217419 Fix: diff -r 9ff1e6cacac3 src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp Sat Jan 19 19:50:01 2019 -0500 +++ b/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp Sun Jan 20 10:06:16 2019 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2018, Red Hat, Inc. All rights reserved. + * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as @@ -29,7 +29,7 @@ ShenandoahSATBMarkQueueSet::ShenandoahSATBMarkQueueSet() : _heap(NULL), - _satb_mark_queue_buffer_allocator(ShenandoahSATBBufferSize, SATB_Q_FL_lock) + _satb_mark_queue_buffer_allocator("SATB Buffer Allocator", ShenandoahSATBBufferSize) {} void ShenandoahSATBMarkQueueSet::initialize(ShenandoahHeap* const heap, Testing: Linux x86_64 build, hotspot_gc_shenandoah Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From aph at redhat.com Sun Jan 20 09:39:55 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 20 Jan 2019 09:39:55 +0000 Subject: RFR [URGENT] (XS) 8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: References: Message-ID: <515d7fc5-5495-6950-a39e-c2637c082064@redhat.com> On 1/20/19 9:10 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217419 > > Fix: > > diff -r 9ff1e6cacac3 src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp Sat Jan 19 19:50:01 2019 -0500 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp Sun Jan 20 10:06:16 2019 +0100 OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From volker.simonis at gmail.com Sun Jan 20 09:53:01 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 20 Jan 2019 10:53:01 +0100 Subject: RFR [URGENT] (XS) 8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: References: Message-ID: Looks good. Aleksey Shipilev schrieb am So. 20. Jan. 2019 um 10:10: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217419 > > Fix: > > diff -r 9ff1e6cacac3 > src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp > Sat Jan 19 19:50:01 2019 -0500 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp > Sun Jan 20 10:06:16 2019 +0100 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2018, Red Hat, Inc. All rights reserved. > + * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > @@ -29,7 +29,7 @@ > > ShenandoahSATBMarkQueueSet::ShenandoahSATBMarkQueueSet() : > _heap(NULL), > - _satb_mark_queue_buffer_allocator(ShenandoahSATBBufferSize, > SATB_Q_FL_lock) > + _satb_mark_queue_buffer_allocator("SATB Buffer Allocator", > ShenandoahSATBBufferSize) > {} > > void ShenandoahSATBMarkQueueSet::initialize(ShenandoahHeap* const heap, > > > Testing: Linux x86_64 build, hotspot_gc_shenandoah > > Thanks, > -Aleksey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Sun Jan 20 10:13:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 20 Jan 2019 11:13:43 +0100 Subject: RFR [URGENT] (XS) 8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: <2F949C04-C4D2-4593-B2A5-52D265621A6F@kennke.org> References: <2F949C04-C4D2-4593-B2A5-52D265621A6F@kennke.org> Message-ID: Thanks folks, pushed. -Aleksey On 1/20/19 11:05 AM, Roman Kennke wrote: > Yup. Thanks! > > Roman > > > Am 20. Januar 2019 10:10:34 MEZ schrieb Aleksey Shipilev : >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8217419 >> >> Fix: >> >> diff -r 9ff1e6cacac3 >> src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp >> --- a/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp >> Sat Jan 19 19:50:01 2019 -0500 >> +++ b/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp >> Sun Jan 20 10:06:16 2019 +0100 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2018, Red Hat, Inc. All rights reserved. >> + * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> @@ -29,7 +29,7 @@ >> >> ShenandoahSATBMarkQueueSet::ShenandoahSATBMarkQueueSet() : >> _heap(NULL), >> - _satb_mark_queue_buffer_allocator(ShenandoahSATBBufferSize, >> SATB_Q_FL_lock) >> + _satb_mark_queue_buffer_allocator("SATB Buffer Allocator", >> ShenandoahSATBBufferSize) >> {} >> >> void ShenandoahSATBMarkQueueSet::initialize(ShenandoahHeap* const heap, >> >> >> Testing: Linux x86_64 build, hotspot_gc_shenandoah >> >> Thanks, >> -Aleksey > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christoph.langer at sap.com Sun Jan 20 14:08:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 20 Jan 2019 14:08:25 +0000 Subject: RFR: 8212826: Make PtrQueue free list lock-free - Build error in gtest Message-ID: <9359d66c6bdc457ca1bd60961f4fa222@sap.com> Hi Kim, in my build on Windows I now get this: c:/mercurial/jdk/test/hotspot/gtest/utilities/test_lockFreeStack.cpp(54): error C2921: redefinition: 'Stack': class template is being redeclared as 'typedef LockFreeStackTestElement::Stack Stack' c:\mercurial\jdk\src\hotspot\share\utilities/stack.hpp(93): note: see declaration of 'Stack' Seems like there's a conflict. Are you aware of that? Is there already a bug open for this? Thank you Christoph > -----Original Message----- > From: hotspot-gc-dev On > Behalf Of Kim Barrett > Sent: Sonntag, 20. Januar 2019 00:44 > To: sangheon.kim at oracle.com > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR: 8212826: Make PtrQueue free list lock-free > > > On Jan 19, 2019, at 2:26 AM, sangheon.kim at oracle.com wrote: > >> > >> New webrevs: > >> full: http://cr.openjdk.java.net/~kbarrett/8212826/open.01/ > >> incr: http://cr.openjdk.java.net/~kbarrett/8212826/open.01.inc/ > > 01 looks good. > > Thanks. > > > FYI, 4 files failed(ptrQueue.hpp, logTag.hpp padded.hpp mutexLocker.hpp) > to apply because the copyright year is already updated. > > Actual codes were applied cleanly. I don't need a webrev for this change. > > Yeah. I should get one of those copyright updater scripts various people use, > so I can deal with it just before pushing. > Of course, this year there will be much less of a need for updates, since > Coleen has already touched most .hpp files. From kim.barrett at oracle.com Sun Jan 20 18:56:21 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Jan 2019 13:56:21 -0500 Subject: RFR: 8212826: Make PtrQueue free list lock-free - Build error in gtest In-Reply-To: <9359d66c6bdc457ca1bd60961f4fa222@sap.com> References: <9359d66c6bdc457ca1bd60961f4fa222@sap.com> Message-ID: <4B88FF95-0BA4-460D-AC9F-9D626D90E761@oracle.com> > On Jan 20, 2019, at 9:08 AM, Langer, Christoph wrote: > > Hi Kim, > > in my build on Windows I now get this: > c:/mercurial/jdk/test/hotspot/gtest/utilities/test_lockFreeStack.cpp(54): error C2921: redefinition: 'Stack': class template is being redeclared as 'typedef LockFreeStackTestElement::Stack Stack' > c:\mercurial\jdk\src\hotspot\share\utilities/stack.hpp(93): note: see declaration of 'Stack' > Seems like there's a conflict. > > Are you aware of that? Is there already a bug open for this? It builds fine with the version of Windows we are using in our automated test setup. What version of Windows are you using? We?re using VS2017 with MSVC++ 15.5. Or maybe there?s a configuration difference? From christoph.langer at sap.com Sun Jan 20 19:02:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 20 Jan 2019 19:02:41 +0000 Subject: RFR: 8212826: Make PtrQueue free list lock-free - Build error in gtest In-Reply-To: <4B88FF95-0BA4-460D-AC9F-9D626D90E761@oracle.com> References: <9359d66c6bdc457ca1bd60961f4fa222@sap.com> <4B88FF95-0BA4-460D-AC9F-9D626D90E761@oracle.com> Message-ID: Hi Kim, my configure says: * Toolchain: microsoft (Microsoft Visual Studio 2017) * C Compiler: Version 19.16.27024.1 (at /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1416~1.270/bin/hostx86/x64/cl) * C++ Compiler: Version 19.16.27024.1 (at /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1416~1.270/bin/hostx86/x64/cl) So it probably has to do with that newer version... Best regards Christoph > -----Original Message----- > From: Kim Barrett > Sent: Sonntag, 20. Januar 2019 19:56 > To: Langer, Christoph > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR: 8212826: Make PtrQueue free list lock-free - Build error in > gtest > > > On Jan 20, 2019, at 9:08 AM, Langer, Christoph > wrote: > > > > Hi Kim, > > > > in my build on Windows I now get this: > > c:/mercurial/jdk/test/hotspot/gtest/utilities/test_lockFreeStack.cpp(54): > error C2921: redefinition: 'Stack': class template is being redeclared as > 'typedef LockFreeStackTestElement::Stack Stack' > > c:\mercurial\jdk\src\hotspot\share\utilities/stack.hpp(93): note: see > declaration of 'Stack' > > Seems like there's a conflict. > > > > Are you aware of that? Is there already a bug open for this? > > It builds fine with the version of Windows we are using in our automated test > setup. > What version of Windows are you using? We?re using VS2017 with MSVC++ > 15.5. > Or maybe there?s a configuration difference? From shade at redhat.com Sun Jan 20 20:09:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 20 Jan 2019 21:09:07 +0100 Subject: RFR: 8212826: Make PtrQueue free list lock-free - Build error in gtest In-Reply-To: <4B88FF95-0BA4-460D-AC9F-9D626D90E761@oracle.com> References: <9359d66c6bdc457ca1bd60961f4fa222@sap.com> <4B88FF95-0BA4-460D-AC9F-9D626D90E761@oracle.com> Message-ID: <13aa1b84-fbcf-2ea3-bb61-cbfc08264961@redhat.com> On 1/20/19 7:56 PM, Kim Barrett wrote: >> On Jan 20, 2019, at 9:08 AM, Langer, Christoph wrote: >> >> Hi Kim, >> >> in my build on Windows I now get this: >> c:/mercurial/jdk/test/hotspot/gtest/utilities/test_lockFreeStack.cpp(54): error C2921: redefinition: 'Stack': class template is being redeclared as 'typedef LockFreeStackTestElement::Stack Stack' >> c:\mercurial\jdk\src\hotspot\share\utilities/stack.hpp(93): note: see declaration of 'Stack' >> Seems like there's a conflict. >> >> Are you aware of that? Is there already a bug open for this? > > It builds fine with the version of Windows we are using in our automated test setup. > What version of Windows are you using? We?re using VS2017 with MSVC++ 15.5. > Or maybe there?s a configuration difference? It fails for me with MSVC 2013 on Windows 7. Filed: https://bugs.openjdk.java.net/browse/JDK-8217423 I have a potential fix. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Sun Jan 20 20:39:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 20 Jan 2019 21:39:32 +0100 Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free) Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8217423 Fix: http://cr.openjdk.java.net/~shade/8217423/webrev.01/ Current Windows build is broken. This patch fixes it by renaming the test typedef to resolve the name conflict with the actual Stack. I suspect that definition comes via precompiled.hpp, but regardless, including stack.hpp accidentally should not break the test. Let's instead use the special name for test typedef. Testing: {Linux, Windows} x86_64 build, gtest; jdk-submit (running) Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christoph.langer at sap.com Sun Jan 20 21:28:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 20 Jan 2019 21:28:21 +0000 Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: References: Message-ID: <53cd80b427a24beca47ccec32bfddb6b@sap.com> Hi Aleksey, the rename looks reasonable to me. Thanks for fixing. Best regards Christoph > -----Original Message----- > From: hotspot-gc-dev On > Behalf Of Aleksey Shipilev > Sent: Sonntag, 20. Januar 2019 21:40 > To: hotspot-gc-dev at openjdk.java.net > Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make > PtrQueue free list lock-free) > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217423 > > Fix: > http://cr.openjdk.java.net/~shade/8217423/webrev.01/ > > Current Windows build is broken. This patch fixes it by renaming the test > typedef to resolve the > name conflict with the actual Stack. I suspect that definition comes via > precompiled.hpp, but > regardless, including stack.hpp accidentally should not break the test. Let's > instead use the > special name for test typedef. > > Testing: {Linux, Windows} x86_64 build, gtest; jdk-submit (running) > > Thanks, > -Aleksey From zgu at redhat.com Sun Jan 20 21:42:00 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Sun, 20 Jan 2019 16:42:00 -0500 Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: <53cd80b427a24beca47ccec32bfddb6b@sap.com> References: <53cd80b427a24beca47ccec32bfddb6b@sap.com> Message-ID: Looks good to me too. -Zhengyu Sent from my iPad > On Jan 20, 2019, at 4:28 PM, Langer, Christoph wrote: > > Hi Aleksey, > > the rename looks reasonable to me. Thanks for fixing. > > Best regards > Christoph > >> -----Original Message----- >> From: hotspot-gc-dev On >> Behalf Of Aleksey Shipilev >> Sent: Sonntag, 20. Januar 2019 21:40 >> To: hotspot-gc-dev at openjdk.java.net >> Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make >> PtrQueue free list lock-free) >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8217423 >> >> Fix: >> http://cr.openjdk.java.net/~shade/8217423/webrev.01/ >> >> Current Windows build is broken. This patch fixes it by renaming the test >> typedef to resolve the >> name conflict with the actual Stack. I suspect that definition comes via >> precompiled.hpp, but >> regardless, including stack.hpp accidentally should not break the test. Let's >> instead use the >> special name for test typedef. >> >> Testing: {Linux, Windows} x86_64 build, gtest; jdk-submit (running) >> >> Thanks, >> -Aleksey > From kim.barrett at oracle.com Mon Jan 21 01:31:53 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Jan 2019 20:31:53 -0500 Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: References: Message-ID: <8E3C0914-3D31-4DFC-B0C2-D6F25351E518@oracle.com> > On Jan 20, 2019, at 3:39 PM, Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217423 > > Fix: > http://cr.openjdk.java.net/~shade/8217423/webrev.01/ > > Current Windows build is broken. This patch fixes it by renaming the test typedef to resolve the > name conflict with the actual Stack. I suspect that definition comes via precompiled.hpp, but > regardless, including stack.hpp accidentally should not break the test. Let's instead use the > special name for test typedef. > > Testing: {Linux, Windows} x86_64 build, gtest; jdk-submit (running) > > Thanks, > -Aleksey Looks good. From kim.barrett at oracle.com Mon Jan 21 01:37:39 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Jan 2019 20:37:39 -0500 Subject: RFR: 8212826: Make PtrQueue free list lock-free - Build error in gtest In-Reply-To: <13aa1b84-fbcf-2ea3-bb61-cbfc08264961@redhat.com> References: <9359d66c6bdc457ca1bd60961f4fa222@sap.com> <4B88FF95-0BA4-460D-AC9F-9D626D90E761@oracle.com> <13aa1b84-fbcf-2ea3-bb61-cbfc08264961@redhat.com> Message-ID: <97511029-3078-40F4-9A58-8A4EF910BDE7@oracle.com> > On Jan 20, 2019, at 3:09 PM, Aleksey Shipilev wrote: > > On 1/20/19 7:56 PM, Kim Barrett wrote: >>> On Jan 20, 2019, at 9:08 AM, Langer, Christoph wrote: >>> >>> Hi Kim, >>> >>> in my build on Windows I now get this: >>> c:/mercurial/jdk/test/hotspot/gtest/utilities/test_lockFreeStack.cpp(54): error C2921: redefinition: 'Stack': class template is being redeclared as 'typedef LockFreeStackTestElement::Stack Stack' >>> c:\mercurial\jdk\src\hotspot\share\utilities/stack.hpp(93): note: see declaration of 'Stack' >>> Seems like there's a conflict. >>> >>> Are you aware of that? Is there already a bug open for this? >> >> It builds fine with the version of Windows we are using in our automated test setup. >> What version of Windows are you using? We?re using VS2017 with MSVC++ 15.5. >> Or maybe there?s a configuration difference? > > It fails for me with MSVC 2013 on Windows 7. Filed: > https://bugs.openjdk.java.net/browse/JDK-8217423 > > I have a potential fix. > > -Aleksey I suspect the reason I didn?t see this failure is the absence of Shenandoah in my testing. I didn?t find the #include chain to prove that (though I didn?t try very hard, either). From suenaga.yasumasa at nttcom.co.jp Mon Jan 21 08:52:28 2019 From: suenaga.yasumasa at nttcom.co.jp (Yasumasa Suenaga) Date: Mon, 21 Jan 2019 17:52:28 +0900 Subject: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> Message-ID: <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> Hi all, I filed this issue to JBS: https://bugs.openjdk.java.net/browse/JDK-8217432 I investigated it, and I found that `minimum_desired_capacity` and `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()` might exceed MaxMetaspaceSize. They shouldn't exceed MaxMetaspaceSize. I uploaded webrev for this bug. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ This change has passed all tests on submit repo, :vmTestbase_vm_metaspace, and :vmTestbase_nsk_sysdict jtreg tests. Thanks, Yasumasa On 2019/01/15 18:30, Yasumasa Suenaga wrote: > PING: Did you read my email? > > I wrote the problem and suggested fix in it. > Please tell me if you have question(s). > > I can file it to JBS if it is a bug. > > > Thanks, > > Yasumasa > > > On 2019/01/10 18:02, Yasumasa Suenaga wrote: >> Hi all, >> >> I'm Yasumasa Suenaga (OpenJDK reviewer: ysuenaga) >> >> My customer uses OpenJDK 8u131 with following commandline arguments: >> >> ?? -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 >> ?? -XX:CompressedClassSpaceSize=128m -Xms4500m -Xmx4500m >> ?? -XX:MaxMetaspaceSize=256m -Xmn=768m -XX:MaxTenuringThreshold=15 >> ?? -XX:OnOutOfMemoryError="/bin/kill -ABRT %p" >> ?? -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC >> >> Their system has encountered OutOfMemoryError which is caused by Metaspace. >> >> I checked core image which was collected by OnOutOfMemoryError, and I saw >> strange values in it as below: >> >> ------------------- >> (gdb) p Metaspace::_space_list->_reserved_words >> $67 = 31195136 >> (gdb) p Metaspace::_class_space_list->_reserved_words >> $68 = 16777216 >> (gdb) p MetaspaceGC::_capacity_until_GC >> $75 = 448045056 >> ------------------- >> >> MaxMetaspaceSize and CompressedClassSpaceSize seem to affect Metaspace. >> However, MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize. >> Is it correct? >> >> I checked used and committed memory from the core, they seem to be enough >> to allocate new objects as below: >> >> ------------------- >> (gdb) p MetaspaceAux::_used_words >> $62 = {1742673, 17905981} >> (gdb) p Metaspace::_space_list->_committed_words >> $64 = 30932992 >> (gdb) p Metaspace::_class_space_list->_committed_words >> $65 = 2621440 >> ------------------- >> >> I guess the cause of OOME is invalid value in _capacity_until_GC. >> _capacity_until_GC is used for expanding / shrinking Metaspace. >> However it is not checked when it changes. >> >> So I think we need to add the code to check it as below: >> (The change is for jdk/jdk) >> ------------------- >> diff -r 32c6cc430526 src/hotspot/share/memory/metaspace.cpp >> --- a/src/hotspot/share/memory/metaspace.cpp??? Wed Jan 09 22:59:49 2019 +0100 >> +++ b/src/hotspot/share/memory/metaspace.cpp??? Thu Jan 10 17:56:55 2019 +0900 >> @@ -143,6 +143,10 @@ >> ????? new_value = align_down(max_uintx, Metaspace::commit_alignment()); >> ??? } >> >> +? if (new_value > MaxMetaspaceSize) { >> +??? return false; >> +? } >> + >> ??? size_t prev_value = Atomic::cmpxchg(new_value, &_capacity_until_GC, old_capacity_until_GC); >> >> ??? if (old_capacity_until_GC != prev_value) { >> ------------------- >> >> _capacity_until_GC is set to MaxMetaspaceSize at MetaspaceGC::initialize(), >> and it set to committed size or MetaspaceSize at MetaspaceGC::post_initialize(). >> So I guess max value of it is MaxMetaspaceSize. >> >> >> What do you think? >> If it is a bug, I will file JBS and send review request. >> >> >> Thanks, >> >> Yasumasa >> >> >> >> From shade at redhat.com Mon Jan 21 09:11:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 21 Jan 2019 10:11:39 +0100 Subject: RFR (S) 8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: <8E3C0914-3D31-4DFC-B0C2-D6F25351E518@oracle.com> References: <8E3C0914-3D31-4DFC-B0C2-D6F25351E518@oracle.com> Message-ID: On 1/21/19 2:31 AM, Kim Barrett wrote: >> Fix: >> http://cr.openjdk.java.net/~shade/8217423/webrev.01/ > > Looks good. Thanks, pushed. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From leo.korinth at oracle.com Mon Jan 21 09:34:06 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 21 Jan 2019 10:34:06 +0100 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> Message-ID: <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> Hi! On 18/01/2019 22:24, Leonid Mesnik wrote: > Leo > > 1. > http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java.udiff.html > > I am not sure how your changes make code clear. Also '128*M' should have > spaces. The main purpose is to remove a compiler warning for unused variable (M64). I also do believe 128*M is more obvious at inspection than M128 (and the construct is used in many places in the code). It also saves two lines of code. I agree that 128*M should have spaces, I have seen it without spaces with the same type of construct, but now I see it with spaces as well. I will add the spaces. > >> On Jan 18, 2019, at 9:23 AM, Leo Korinth > > wrote: >> >> Hi, >> >> Here I am removing warnings for unused variables. >> >> Some variables can not be removed as in the case of creating a new >> primitive array without assigning it to a variable. It is not allowed, >> in those cases I use @SuppressWarnings("unused"). >> > > I think that it would be better to really use these variables somehow. Yes, but I am only removing warnings or bugs (or I will never finish this). > The hotspot compilers might also optimize such arrays initialization > since results are not used. ?The tests like this > http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/cslocker/TestCSLocker.java > just silently pass without any memory allocation and actual testing. > > I think it would be better to change this variables to be public static > and/or be used by some external stuff (print zero/last element as > example). It guarantee that compiler can't remove this allocation as a > dead code. Yes, I will make them public static variables. I understand that is enough to guarantee allocation. I will try to update these test cases accordingly. We will then get some actual improvement in tests and not only clear warnings :-) I will prepare a new webrev. Thanks, Leo > > See following test as example: > http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/gc/TestMemoryInitialization.java > > Might be some library helper which produce some amount off garbage is > useful. > There are already a lot of methods to produce garbage here but they > seems to be overcomplicated. Not sure it make sense to reuse them. > http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp > > > Leonid > >> In some cases the variable is not used at all, and I remove it, but >> still add the variable name as a comment after the expression, as the >> variable name might have helped as documentation. I also just >> commented out "final int CONSTANT_Unicode = 2;" if that information >> might be useful in the future, it is a constant that we do not expect >> in the test case. >> >> Otherwise I just try to remove the code. >> >> This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8217389 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8217389/00 >> >> Testing: >> passed locally: open/test/hotspot/jtreg/:hotspot_gc >> >> Thanks, >> Leo > From shade at redhat.com Mon Jan 21 09:54:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 21 Jan 2019 10:54:58 +0100 Subject: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> Message-ID: <5309bb4a-9ebd-b4e4-a373-fdbe5143c8cd@redhat.com> On 1/21/19 9:52 AM, Yasumasa Suenaga wrote: > I filed this issue to JBS: > ? https://bugs.openjdk.java.net/browse/JDK-8217432 > > I investigated it, and I found that `minimum_desired_capacity` and > `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()` > might exceed MaxMetaspaceSize. They shouldn't exceed MaxMetaspaceSize. Yes, looks like it. I was wondering in my recent Epsilon tests why setting very low MaxMetaspaceSize did not OOM. With your patch, it OOMs on low MMS, as expected. I think you can construct the non-GC-specific regression test. Take the sample class generator from here: http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/gc/epsilon/TestClasses.java and feed different MaxMetaspaceSize settings via ProcessTools, like here: http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java > I uploaded webrev for this bug. Could you review it? > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ It is weird to see this block in expand_and_allocate: 1498 if (!incremented && SafepointSynchronize::is_at_safepoint()) { 1499 // Cannot expand metaspace more. 1500 return NULL; 1501 } Maybe we should instead fall-through in inc_capacity_until_GC? 141 if (new_value < old_capacity_until_GC) { 142 // The addition wrapped around, set new_value to aligned max value. 143 new_value = align_down(max_uintx, Metaspace::commit_alignment()); 144 } 145 146 if (new_value > MaxMetaspaceSize) { 147 return false; // instead, new_value = MIN2(new_value, MaxMetaspaceSize); 148 } 149 ...that would naturally exit the loop, AFAIU. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Mon Jan 21 11:20:01 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Jan 2019 12:20:01 +0100 Subject: RFR (XXS): 8217374: Rename G1 EvacuationInfo class to G1EvacuationInfo In-Reply-To: References: Message-ID: Thanks Kim and Paul for your reviews. Thomas On Sat, 2019-01-19 at 19:29 -0500, Kim Barrett wrote: > > On Jan 18, 2019, at 8:31 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this small change that makes the > > EvacuationInfo class/files correspond to the naming scheme we > > should > > use in collector specific directories? > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8217374 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8217374/webrev/ > > testing: > > local compilation > > > > Thanks, > > Thomas > > Looks good. > From leo.korinth at oracle.com Mon Jan 21 11:30:57 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 21 Jan 2019 12:30:57 +0100 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> Message-ID: <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> Hi, I have a new update that uses Reference.reachabilityFence to make sure that allocations are not optimized away. After a bit of thinking and asking around, I believe reachabilityFence to be a better solution than a public static variable in these cases where we want to make sure allocation is not optimized away but do not want the object to be reachable. It also makes it a bit more obvious that the code is used to allocate garbage and not to be optimized away rather than being a programming mistake. I also added spaces to the "XXX*M" pattern. Webrev (Full): http://cr.openjdk.java.net/~lkorinth/8217389/01 Webrev (Incremental): http://cr.openjdk.java.net/~lkorinth/8217389/00_01 Testing: gc test suite still passes. Thanks, Leo On 21/01/2019 10:34, Leo Korinth wrote: > Hi! > > On 18/01/2019 22:24, Leonid Mesnik wrote: >> Leo >> >> 1. >> http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java.udiff.html >> >> >> I am not sure how your changes make code clear. Also '128*M' should >> have spaces. > > The main purpose is to remove a compiler warning for unused variable > (M64). I also do believe 128*M is more obvious at inspection than M128 > (and the construct is used in many places in the code). It also saves > two lines of code. I agree that 128*M should have spaces, I have seen it > without spaces with the same type of construct, but now I see it with > spaces as well. I will add the spaces. > >> >>> On Jan 18, 2019, at 9:23 AM, Leo Korinth >> > wrote: >>> >>> Hi, >>> >>> Here I am removing warnings for unused variables. >>> >>> Some variables can not be removed as in the case of creating a new >>> primitive array without assigning it to a variable. It is not >>> allowed, in those cases I use @SuppressWarnings("unused"). >>> >> >> I think that it would be better to really use these variables somehow. > > Yes, but I am only removing warnings or bugs (or I will never finish this). > >> The hotspot compilers might also optimize such arrays initialization >> since results are not used. ?The tests like this >> http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/cslocker/TestCSLocker.java >> >> just silently pass without any memory allocation and actual testing. >> >> I think it would be better to change this variables to be public >> static and/or be used by some external stuff (print zero/last element >> as example). It guarantee that compiler can't remove this allocation >> as a dead code. > > Yes, I will make them public static variables. I understand that is > enough to guarantee allocation. I will try to update these test cases > accordingly. We will then get some actual improvement in tests and not > only clear warnings :-) > > I will prepare a new webrev. > > Thanks, Leo > >> >> See following test as example: >> http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/gc/TestMemoryInitialization.java >> >> >> Might be some library helper which produce some amount off garbage is >> useful. >> There are already a lot of methods to produce garbage here but they >> seems to be overcomplicated. Not sure it make sense to reuse them. >> http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp >> >> >> >> Leonid >> >>> In some cases the variable is not used at all, and I remove it, but >>> still add the variable name as a comment after the expression, as the >>> variable name might have helped as documentation. I also just >>> commented out "final int CONSTANT_Unicode = 2;" if that information >>> might be useful in the future, it is a constant that we do not expect >>> in the test case. >>> >>> Otherwise I just try to remove the code. >>> >>> This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8217389 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lkorinth/8217389/00 >>> >>> Testing: >>> passed locally: open/test/hotspot/jtreg/:hotspot_gc >>> >>> Thanks, >>> Leo >> From thomas.schatzl at oracle.com Mon Jan 21 11:35:05 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Jan 2019 12:35:05 +0100 Subject: RFR (L): 8217330: Split CollectionSetChooser into collection set candidate container and the chooser algorithm Message-ID: Hi all, can I have reviews for this cleanup change that splits CollectionSetChooser into the container holding the collection set candidates (named G1CollectionSetCandidates) and the CollectionSetChooser (will be renamed in JDK-8217328) that only contains static methods to create the candidate set? I think this improves readability of the code a lot given this misnomer. Finally it removes some really ugly constructor hack (sorry D. Detlefs!) with GrowableArray. (It actually, if you remove new file headers, reduces code size a bit too) CR: https://bugs.openjdk.java.net/browse/JDK-8217330 Webrev: http://cr.openjdk.java.net/~tschatzl/8217330/webrev/ Testing: hs-tier1-5 Thanks, Thomas From thomas.schatzl at oracle.com Mon Jan 21 11:54:09 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Jan 2019 12:54:09 +0100 Subject: RFR (S): 8217328: Rename CollectionSetChooser to G1CollectionSetChooser Message-ID: <848f025d7f8b828d9b37dc296dd568cf80131238.camel@oracle.com> Hi all, can I have reviews for this simple rename of CollectionSetChooser to G1CollectionSetChooser to have it adhere to naming guidelines? This only contains renames of the files and the class. CR: https://bugs.openjdk.java.net/browse/JDK-8217328 Webrev: http://cr.openjdk.java.net/~tschatzl/8217328/webrev/ Testing: local compilation Thanks, Thomas From yasuenag at gmail.com Mon Jan 21 12:12:44 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 21 Jan 2019 21:12:44 +0900 Subject: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <5309bb4a-9ebd-b4e4-a373-fdbe5143c8cd@redhat.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <5309bb4a-9ebd-b4e4-a373-fdbe5143c8cd@redhat.com> Message-ID: <2cce4e6b-b75f-b356-cdc5-ed670eb095fa@gmail.com> Hi Aleksey, On 2019/01/21 18:54, Aleksey Shipilev wrote: > On 1/21/19 9:52 AM, Yasumasa Suenaga wrote: >> I filed this issue to JBS: >> ? https://bugs.openjdk.java.net/browse/JDK-8217432 >> >> I investigated it, and I found that `minimum_desired_capacity` and >> `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()` >> might exceed MaxMetaspaceSize. They shouldn't exceed >> MaxMetaspaceSize. > > Yes, looks like it. I was wondering in my recent Epsilon tests why > setting very low MaxMetaspaceSize > did not OOM. With your patch, it OOMs on low MMS, as expected. > > I think you can construct the non-GC-specific regression test. Take > the sample class generator from > here: > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/gc/epsilon/TestClasses.java > and > feed different MaxMetaspaceSize settings via ProcessTools, like here: > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java I think we can test it with test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java . I've confirmed ShrinkGrowTest works fine on my Linux x64 box. >> I uploaded webrev for this bug. Could you review it? >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ > > It is weird to see this block in expand_and_allocate: > > 1498 if (!incremented && SafepointSynchronize::is_at_safepoint()) { > 1499 // Cannot expand metaspace more. > 1500 return NULL; > 1501 } > > Maybe we should instead fall-through in inc_capacity_until_GC? No. If MetaspaceGC::inc_capacity_until_GC() returns NULL, new metadata allocation might be failed because Metaspace does not have enough space. while (!incremented && res == NULL) Thus above condition will be `true` forever :-) (inc_capacity_until_GC() is false && cannot get memory from Metaspace) You can see this behavior with ShrinkGrowTest. But you need to attach GDB to it. Thanks, Yasumasa > 141 if (new_value < old_capacity_until_GC) { > 142 // The addition wrapped around, set new_value to aligned max value. > 143 new_value = align_down(max_uintx, Metaspace::commit_alignment()); > 144 } > 145 > 146 if (new_value > MaxMetaspaceSize) { > 147 return false; // instead, new_value = MIN2(new_value, MaxMetaspaceSize); > 148 } > 149 > > ...that would naturally exit the loop, AFAIU. > > Thanks, > -Aleksey > From leo.korinth at oracle.com Mon Jan 21 14:48:14 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 21 Jan 2019 15:48:14 +0100 Subject: RFR (S): 8217328: Rename CollectionSetChooser to G1CollectionSetChooser In-Reply-To: <848f025d7f8b828d9b37dc296dd568cf80131238.camel@oracle.com> References: <848f025d7f8b828d9b37dc296dd568cf80131238.camel@oracle.com> Message-ID: <3b8f1bde-76fe-0b97-e80f-1b51ad2c2b81@oracle.com> Hi, rename looks good to me, thanks for cleaning this up! /Leo On 21/01/2019 12:54, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this simple rename of CollectionSetChooser to > G1CollectionSetChooser to have it adhere to naming guidelines? > > This only contains renames of the files and the class. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217328 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217328/webrev/ > Testing: > local compilation > > Thanks, > Thomas > From leonid.mesnik at oracle.com Mon Jan 21 17:40:39 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 21 Jan 2019 09:40:39 -0800 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> Message-ID: Hi Looks good, thanks for very nice clean up. Indeed, the Reference.reachabilityFence() should be the best way to ensure that object is reachable. Leonid > On Jan 21, 2019, at 3:30 AM, Leo Korinth wrote: > > Hi, > > I have a new update that uses Reference.reachabilityFence to make sure that allocations are not optimized away. After a bit of thinking and asking around, I believe reachabilityFence to be a better solution than a public static variable in these cases where we want to make sure allocation is not optimized away but do not want the object to be reachable. It also makes it a bit more obvious that the code is used to allocate garbage and not to be optimized away rather than being a programming mistake. > > I also added spaces to the "XXX*M" pattern. > > Webrev (Full): http://cr.openjdk.java.net/~lkorinth/8217389/01 > Webrev (Incremental): http://cr.openjdk.java.net/~lkorinth/8217389/00_01 > > Testing: gc test suite still passes. > > Thanks, > Leo > > On 21/01/2019 10:34, Leo Korinth wrote: >> Hi! >> On 18/01/2019 22:24, Leonid Mesnik wrote: >>> Leo >>> >>> 1. http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java.udiff.html >>> >>> I am not sure how your changes make code clear. Also '128*M' should have spaces. >> The main purpose is to remove a compiler warning for unused variable (M64). I also do believe 128*M is more obvious at inspection than M128 (and the construct is used in many places in the code). It also saves two lines of code. I agree that 128*M should have spaces, I have seen it without spaces with the same type of construct, but now I see it with spaces as well. I will add the spaces. >>> >>>> On Jan 18, 2019, at 9:23 AM, Leo Korinth >>> > wrote: >>>> >>>> Hi, >>>> >>>> Here I am removing warnings for unused variables. >>>> >>>> Some variables can not be removed as in the case of creating a new primitive array without assigning it to a variable. It is not allowed, in those cases I use @SuppressWarnings("unused"). >>>> >>> >>> I think that it would be better to really use these variables somehow. >> Yes, but I am only removing warnings or bugs (or I will never finish this). >>> The hotspot compilers might also optimize such arrays initialization since results are not used. The tests like this >>> http://cr.openjdk.java.net/~lkorinth/8217389/00/test/hotspot/jtreg/gc/cslocker/TestCSLocker.java >>> just silently pass without any memory allocation and actual testing. >>> >>> I think it would be better to change this variables to be public static and/or be used by some external stuff (print zero/last element as example). It guarantee that compiler can't remove this allocation as a dead code. >> Yes, I will make them public static variables. I understand that is enough to guarantee allocation. I will try to update these test cases accordingly. We will then get some actual improvement in tests and not only clear warnings :-) >> I will prepare a new webrev. >> Thanks, Leo >>> >>> See following test as example: >>> http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/gc/TestMemoryInitialization.java >>> >>> Might be some library helper which produce some amount off garbage is useful. >>> There are already a lot of methods to produce garbage here but they seems to be overcomplicated. Not sure it make sense to reuse them. >>> http://hg.openjdk.java.net/jdk/jdk/file/cb7347310fa1/test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp >>> >>> >>> Leonid >>> >>>> In some cases the variable is not used at all, and I remove it, but still add the variable name as a comment after the expression, as the variable name might have helped as documentation. I also just commented out "final int CONSTANT_Unicode = 2;" if that information might be useful in the future, it is a constant that we do not expect in the test case. >>>> >>>> Otherwise I just try to remove the code. >>>> >>>> This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. >>>> >>>> Enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8217389 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~lkorinth/8217389/00 >>>> >>>> Testing: >>>> passed locally: open/test/hotspot/jtreg/:hotspot_gc >>>> >>>> Thanks, >>>> Leo >>> From kim.barrett at oracle.com Mon Jan 21 18:58:29 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Jan 2019 13:58:29 -0500 Subject: RFR (S): 8217328: Rename CollectionSetChooser to G1CollectionSetChooser In-Reply-To: <848f025d7f8b828d9b37dc296dd568cf80131238.camel@oracle.com> References: <848f025d7f8b828d9b37dc296dd568cf80131238.camel@oracle.com> Message-ID: > On Jan 21, 2019, at 6:54 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this simple rename of CollectionSetChooser to > G1CollectionSetChooser to have it adhere to naming guidelines? > > This only contains renames of the files and the class. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217328 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217328/webrev/ > Testing: > local compilation > > Thanks, > Thomas Looks good. From per.liden at oracle.com Tue Jan 22 09:36:33 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 10:36:33 +0100 Subject: RFR: 8217309: ZGC: Fix ZNMethodTable corruption Message-ID: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> Calls to CollectedHeap::register_nmethod()/unregister_nmethod() should be protected by the CodeCache_lock (when called outside of safepoints). However, nmethod::make_unloaded() calls CollectedHeap::unregister_nmethod() without this lock held, which can corrupt the ZNMethodTable. Adding the lock is straight forward. The rest of the patch adjusts ZNMethodTable::unregister_nmethod() to never return false (which should never happen), adds the the proper asserts, etc. Bug: https://bugs.openjdk.java.net/browse/JDK-8217309 Webrev: http://cr.openjdk.java.net/~pliden/8217309/webrev.0 Testing: Tier1-4 on all archs. Tier-1-7 on Linux/x86 (I'll update the bug with the proper fix-request label, justification, etc) /Per From stefan.karlsson at oracle.com Tue Jan 22 09:53:41 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2019 10:53:41 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 In-Reply-To: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> References: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> Message-ID: Hi Per, On 2019-01-16 15:59, Per Liden wrote: > Minor style/cosmetic cleanups of ZBarrierSetC2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 > Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 This change contains cleanups and they look good. However, the patch also contains a bug fix in ZBarrierSetC2::escape_add_final_edges (a missing break causing a fall-through in the switch statement), and I'd like to see that getting fixed as a separate changeset. Thanks, StefanK > > /Per From per.liden at oracle.com Tue Jan 22 09:56:02 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 10:56:02 +0100 Subject: RFR: 8217503: ZGC: Fix fall through bug in ZBarrierSetC2::escape_add_final_edges() Message-ID: <840c5ab2-c041-f597-29b1-189a8d762097@oracle.com> The switch statement in ZBarrierSetC2::escape_add_final_edges() has a fall through bug, letting the Op_LoadBarrierSlowReg/Op_LoadBarrierWeakSlowReg case fall through into the Op_Proj case. Bug: https://bugs.openjdk.java.net/browse/JDK-8217503 Webrev: http://cr.openjdk.java.net/~pliden/8217503/webrev.0 /Per From stefan.karlsson at oracle.com Tue Jan 22 09:55:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2019 10:55:57 +0100 Subject: RFR: 8217258: ZGC: Minor cleanup of ZBarrierSetAssembler In-Reply-To: <53ca5478-83a6-680f-8541-b8a037ad868f@oracle.com> References: <53ca5478-83a6-680f-8541-b8a037ad868f@oracle.com> Message-ID: <559dfa6b-2419-d457-91b6-cbcc2dd9685d@oracle.com> Looks good. StefanK On 2019-01-16 15:59, Per Liden wrote: > Minor style/cosmetic cleanups of ZBarrierSetAssembler. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217258 > Webrev: http://cr.openjdk.java.net/~pliden/8217258/webrev.0 > > /Per From per.liden at oracle.com Tue Jan 22 09:58:42 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 10:58:42 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 In-Reply-To: References: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> Message-ID: <42704517-b6f2-898e-9b4b-8e3a53c9fe99@oracle.com> On 1/22/19 10:53 AM, Stefan Karlsson wrote: > Hi Per, > > On 2019-01-16 15:59, Per Liden wrote: >> Minor style/cosmetic cleanups of ZBarrierSetC2. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 >> Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 > > This change contains cleanups and they look good. However, the patch > also contains a bug fix in ZBarrierSetC2::escape_add_final_edges (a > missing break causing a fall-through in the switch statement), and I'd > like to see that getting fixed as a separate changeset. Thanks for reviewing Stefan. Filed and sent out https://bugs.openjdk.java.net/browse/JDK-8217503 to deal with the fall through bug. Updated this webrev accordingly: http://cr.openjdk.java.net/~pliden/8217257/webrev.1 /Per > > Thanks, > StefanK > >> >> /Per From stefan.karlsson at oracle.com Tue Jan 22 09:56:59 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2019 10:56:59 +0100 Subject: RFR: 8217503: ZGC: Fix fall through bug in ZBarrierSetC2::escape_add_final_edges() In-Reply-To: <840c5ab2-c041-f597-29b1-189a8d762097@oracle.com> References: <840c5ab2-c041-f597-29b1-189a8d762097@oracle.com> Message-ID: <05ffb297-154a-c9a3-02dc-abc85aa0a7ec@oracle.com> Looks good. StefanK On 2019-01-22 10:56, Per Liden wrote: > The switch statement in ZBarrierSetC2::escape_add_final_edges() has a > fall through bug, letting the > Op_LoadBarrierSlowReg/Op_LoadBarrierWeakSlowReg case fall through into > the Op_Proj case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217503 > Webrev: http://cr.openjdk.java.net/~pliden/8217503/webrev.0 > > /Per From per.liden at oracle.com Tue Jan 22 10:01:55 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 11:01:55 +0100 Subject: RFR: 8217258: ZGC: Minor cleanup of ZBarrierSetAssembler In-Reply-To: <559dfa6b-2419-d457-91b6-cbcc2dd9685d@oracle.com> References: <53ca5478-83a6-680f-8541-b8a037ad868f@oracle.com> <559dfa6b-2419-d457-91b6-cbcc2dd9685d@oracle.com> Message-ID: <25c1051b-4281-190b-3ef6-9db88ed391ac@oracle.com> Thanks for reviewing, Erik and Stefan! /Per On 1/22/19 10:55 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-01-16 15:59, Per Liden wrote: >> Minor style/cosmetic cleanups of ZBarrierSetAssembler. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217258 >> Webrev: http://cr.openjdk.java.net/~pliden/8217258/webrev.0 >> >> /Per From per.liden at oracle.com Tue Jan 22 10:00:28 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 11:00:28 +0100 Subject: RFR: 8217503: ZGC: Fix fall through bug in ZBarrierSetC2::escape_add_final_edges() In-Reply-To: <05ffb297-154a-c9a3-02dc-abc85aa0a7ec@oracle.com> References: <840c5ab2-c041-f597-29b1-189a8d762097@oracle.com> <05ffb297-154a-c9a3-02dc-abc85aa0a7ec@oracle.com> Message-ID: <0ab3a090-460f-88a7-2e47-6f3ffff6a5a9@oracle.com> Thanks Stefan! /Per On 1/22/19 10:56 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-01-22 10:56, Per Liden wrote: >> The switch statement in ZBarrierSetC2::escape_add_final_edges() has a >> fall through bug, letting the >> Op_LoadBarrierSlowReg/Op_LoadBarrierWeakSlowReg case fall through into >> the Op_Proj case. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217503 >> Webrev: http://cr.openjdk.java.net/~pliden/8217503/webrev.0 >> >> /Per From erik.osterlund at oracle.com Tue Jan 22 10:02:51 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 22 Jan 2019 11:02:51 +0100 Subject: RFR: 8217309: ZGC: Fix ZNMethodTable corruption In-Reply-To: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> References: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> Message-ID: Hi Per, Looks good. Thanks, /Erik On 2019-01-22 10:36, Per Liden wrote: > Calls to CollectedHeap::register_nmethod()/unregister_nmethod() should > be protected by the CodeCache_lock (when called outside of > safepoints). However, nmethod::make_unloaded() calls > CollectedHeap::unregister_nmethod() without this lock held, which can > corrupt the ZNMethodTable. Adding the lock is straight forward. The > rest of the patch adjusts ZNMethodTable::unregister_nmethod() to never > return false (which should never happen), adds the the proper asserts, > etc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217309 > Webrev: http://cr.openjdk.java.net/~pliden/8217309/webrev.0 > > Testing: Tier1-4 on all archs. Tier-1-7 on Linux/x86 > > (I'll update the bug with the proper fix-request label, justification, > etc) > > /Per From thomas.schatzl at oracle.com Tue Jan 22 10:02:52 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 11:02:52 +0100 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> Message-ID: <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> Hi all, On Sat, 2019-01-12 at 04:52 -0500, Kim Barrett wrote: > > On Jan 11, 2019, at 9:51 PM, Kim Barrett > > wrote: > > > > > On Jan 10, 2019, at 3:46 PM, Thomas Schatzl < > > > thomas.schatzl at oracle.com> wrote: > > > [?] > > > CR: > > > https://bugs.openjdk.java.net/browse/JDK-8213229 > > > Webrev: > > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ > > > Testing: > > > hs-tier1-6, performance checking with our performance suite > > > showed no particular performance differences before/after Updated webrev at http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1_to_2 (diff) http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2/ (full) implementing the notification of the ServiceThread and applying Kim's naming suggestion. Thanks, Thomas From per.liden at oracle.com Tue Jan 22 10:02:20 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 11:02:20 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 In-Reply-To: <0409253a0972d444ceb1eef31b58d63c4b16235b.camel@oracle.com> References: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> <0409253a0972d444ceb1eef31b58d63c4b16235b.camel@oracle.com> Message-ID: <33fad2b6-eeab-6ea7-bb46-a8e385ec7804@oracle.com> Thanks Thomas! /Per On 1/17/19 10:37 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2019-01-16 at 15:59 +0100, Per Liden wrote: >> Minor style/cosmetic cleanups of ZBarrierSetC2. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 >> Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 >> >> /Per > > cleanups look good. > > Thomas > From per.liden at oracle.com Tue Jan 22 10:03:00 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 11:03:00 +0100 Subject: RFR: 8217309: ZGC: Fix ZNMethodTable corruption In-Reply-To: References: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> Message-ID: <9cdd4407-386f-263c-6ee7-93ab89793fb0@oracle.com> Thanks Erik! /Per On 1/22/19 11:02 AM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-01-22 10:36, Per Liden wrote: >> Calls to CollectedHeap::register_nmethod()/unregister_nmethod() should >> be protected by the CodeCache_lock (when called outside of >> safepoints). However, nmethod::make_unloaded() calls >> CollectedHeap::unregister_nmethod() without this lock held, which can >> corrupt the ZNMethodTable. Adding the lock is straight forward. The >> rest of the patch adjusts ZNMethodTable::unregister_nmethod() to never >> return false (which should never happen), adds the the proper asserts, >> etc. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217309 >> Webrev: http://cr.openjdk.java.net/~pliden/8217309/webrev.0 >> >> Testing: Tier1-4 on all archs. Tier-1-7 on Linux/x86 >> >> (I'll update the bug with the proper fix-request label, justification, >> etc) >> >> /Per > From stefan.karlsson at oracle.com Tue Jan 22 10:34:16 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2019 11:34:16 +0100 Subject: RFR: 8217309: ZGC: Fix ZNMethodTable corruption In-Reply-To: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> References: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> Message-ID: <9350a25b-4ef2-59ec-ccd7-7e08cca9318f@oracle.com> Hi Per, On 2019-01-22 10:36, Per Liden wrote: > Calls to CollectedHeap::register_nmethod()/unregister_nmethod() should > be protected by the CodeCache_lock (when called outside of safepoints). > However, nmethod::make_unloaded() calls > CollectedHeap::unregister_nmethod() without this lock held, which can > corrupt the ZNMethodTable. Adding the lock is straight forward. The rest > of the patch adjusts ZNMethodTable::unregister_nmethod() to never return > false (which should never happen), adds the the proper asserts, etc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217309 > Webrev: http://cr.openjdk.java.net/~pliden/8217309/webrev.0 Looks good. One thought about related code: while (_iter_table != NULL) { MutexUnlockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); os::naked_short_sleep(1); } We might want to consider changing this into using wait/notify instead of unlocker/sleep. Thanks, StefanK > > Testing: Tier1-4 on all archs. Tier-1-7 on Linux/x86 > > (I'll update the bug with the proper fix-request label, justification, etc) > > /Per From stefan.karlsson at oracle.com Tue Jan 22 10:35:29 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2019 11:35:29 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 In-Reply-To: <42704517-b6f2-898e-9b4b-8e3a53c9fe99@oracle.com> References: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> <42704517-b6f2-898e-9b4b-8e3a53c9fe99@oracle.com> Message-ID: <3a216dd9-0b2b-c9c8-dd72-161f19193fb9@oracle.com> Looks good. StefanK On 2019-01-22 10:58, Per Liden wrote: > On 1/22/19 10:53 AM, Stefan Karlsson wrote: >> Hi Per, >> >> On 2019-01-16 15:59, Per Liden wrote: >>> Minor style/cosmetic cleanups of ZBarrierSetC2. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 >>> Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 >> >> This change contains cleanups and they look good. However, the patch >> also contains a bug fix in ZBarrierSetC2::escape_add_final_edges (a >> missing break causing a fall-through in the switch statement), and I'd >> like to see that getting fixed as a separate changeset. > > Thanks for reviewing Stefan. > > Filed and sent out https://bugs.openjdk.java.net/browse/JDK-8217503 to > deal with the fall through bug. > > Updated this webrev accordingly: > > http://cr.openjdk.java.net/~pliden/8217257/webrev.1 > > /Per > >> >> Thanks, >> StefanK >> >>> >>> /Per From thomas.schatzl at oracle.com Tue Jan 22 10:46:42 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 11:46:42 +0100 Subject: RFR (S): 8217328: Rename CollectionSetChooser to G1CollectionSetChooser In-Reply-To: References: <848f025d7f8b828d9b37dc296dd568cf80131238.camel@oracle.com> Message-ID: <67f3fe3999fb7bfc296f35b2e0a4c146e912eb47.camel@oracle.com> Hi Kim, Sangheon, thanks for your review. I will push it with 8217330 is reviewed - I failed to mention that this change depends on the other. Thanks, Thomas On Mon, 2019-01-21 at 13:58 -0500, Kim Barrett wrote: > > On Jan 21, 2019, at 6:54 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this simple rename of CollectionSetChooser > > to G1CollectionSetChooser to have it adhere to naming guidelines? > > > > This only contains renames of the files and the class. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8217328 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8217328/webrev/ > > Testing: > > local compilation > > > > Thanks, > > Thomas > > Looks good. > From thomas.schatzl at oracle.com Tue Jan 22 11:02:22 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 12:02:22 +0100 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> Message-ID: Hi, On Mon, 2019-01-21 at 12:30 +0100, Leo Korinth wrote: > Hi, > > I have a new update that uses Reference.reachabilityFence to make > sure that allocations are not optimized away. After a bit of thinking > and asking around, I believe reachabilityFence to be a better > solution than a public static variable in these cases where we want > to make sure allocation is not optimized away but do not want the > object to be reachable. It also makes it a bit more obvious that the > code is used to allocate garbage and not to be optimized away rather > than being a programming mistake. > > I also added spaces to the "XXX*M" pattern. > > Webrev (Full): http://cr.openjdk.java.net/~lkorinth/8217389/01 > Webrev (Incremental): > http://cr.openjdk.java.net/~lkorinth/8217389/00_01 > > Testing: gc test suite still passes. Looks good. Note that some tests use System.out.println(some-object) to achieve the same effect - maybe using reachabilityFence there might be worthwhile too. Thanks, Thomas From per.liden at oracle.com Tue Jan 22 11:05:33 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 12:05:33 +0100 Subject: RFR: 8217309: ZGC: Fix ZNMethodTable corruption In-Reply-To: <9350a25b-4ef2-59ec-ccd7-7e08cca9318f@oracle.com> References: <514d6a95-52c7-ef47-8e5e-5f0c56b7af03@oracle.com> <9350a25b-4ef2-59ec-ccd7-7e08cca9318f@oracle.com> Message-ID: On 1/22/19 11:34 AM, Stefan Karlsson wrote: > Hi Per, > > On 2019-01-22 10:36, Per Liden wrote: >> Calls to CollectedHeap::register_nmethod()/unregister_nmethod() should >> be protected by the CodeCache_lock (when called outside of >> safepoints). However, nmethod::make_unloaded() calls >> CollectedHeap::unregister_nmethod() without this lock held, which can >> corrupt the ZNMethodTable. Adding the lock is straight forward. The >> rest of the patch adjusts ZNMethodTable::unregister_nmethod() to never >> return false (which should never happen), adds the the proper asserts, >> etc. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217309 >> Webrev: http://cr.openjdk.java.net/~pliden/8217309/webrev.0 > > Looks good. Thanks for reviewing Stefan. > > One thought about related code: > ?? while (_iter_table != NULL) { > ???? MutexUnlockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); > ???? os::naked_short_sleep(1); > ?? } > > We might want to consider changing this into using wait/notify instead > of unlocker/sleep. Sounds like a good future enhancement. /Per > > Thanks, > StefanK > >> >> Testing: Tier1-4 on all archs. Tier-1-7 on Linux/x86 >> >> (I'll update the bug with the proper fix-request label, justification, >> etc) >> >> /Per From per.liden at oracle.com Tue Jan 22 11:05:45 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 22 Jan 2019 12:05:45 +0100 Subject: RFR: 8217257: ZGC: Minor cleanup of ZBarrierSetC2 In-Reply-To: <3a216dd9-0b2b-c9c8-dd72-161f19193fb9@oracle.com> References: <51abf871-8459-d3a5-7a55-aad17c4aa243@oracle.com> <42704517-b6f2-898e-9b4b-8e3a53c9fe99@oracle.com> <3a216dd9-0b2b-c9c8-dd72-161f19193fb9@oracle.com> Message-ID: <3e9eb5b6-1b76-a173-defe-9b999a4138f2@oracle.com> Thanks! /Per On 1/22/19 11:35 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-01-22 10:58, Per Liden wrote: >> On 1/22/19 10:53 AM, Stefan Karlsson wrote: >>> Hi Per, >>> >>> On 2019-01-16 15:59, Per Liden wrote: >>>> Minor style/cosmetic cleanups of ZBarrierSetC2. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217257 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8217257/webrev.0 >>> >>> This change contains cleanups and they look good. However, the patch >>> also contains a bug fix in ZBarrierSetC2::escape_add_final_edges (a >>> missing break causing a fall-through in the switch statement), and >>> I'd like to see that getting fixed as a separate changeset. >> >> Thanks for reviewing Stefan. >> >> Filed and sent out https://bugs.openjdk.java.net/browse/JDK-8217503 to >> deal with the fall through bug. >> >> Updated this webrev accordingly: >> >> http://cr.openjdk.java.net/~pliden/8217257/webrev.1 >> >> /Per >> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> /Per From thomas.schatzl at oracle.com Tue Jan 22 12:05:23 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 13:05:23 +0100 Subject: record object number in AgeTable for G1 In-Reply-To: <4129f4238a16499f871910c3f202ee10@jd.com> References: <035dddcd97da4662b5a7ca96e48d3618@jd.com> <7db97a230694faf65582f88bacf71e5667ac8ef9.camel@oracle.com> <16d3ee1ae9cb586f68ab34a8df51d2cf9534adc9.camel@oracle.com> <4129f4238a16499f871910c3f202ee10@jd.com> Message-ID: <7c0114e4498ba3da1e2c0ed2fda84660de945c36.camel@oracle.com> Hi, On Fri, 2019-01-18 at 13:48 +0000, ?? wrote: > Hi Thomas, > Thanks a lot for your suggestion. > > Yes, the mainly purpose of this change is to calculate the > distribution of objects at each age, after rethink of it , I agree > with you that this change is more like an instrumentation for > profiling rather than feature for product, and it more or less takes > effect of the pause time, since most of the change works in g1 pause > phase. So I think it may not be necessary to have a patch for it. > And thanks a lot for the info of measuring GC performance, I > will use it for performance evaluation of my future changes in GC. Looking forward to these changes :) > BTW, My company (JD.COM or Beijing Wodong Tianjun Information > Technology Co. Ltd) has signed the OCA. So I may have more discussion > or patches related with GC in future. Okay, good to know. Thanks, Thomas From leo.korinth at oracle.com Tue Jan 22 13:01:27 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 22 Jan 2019 14:01:27 +0100 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> Message-ID: <61217926-63b0-a28d-38a0-d0b89821d57b@oracle.com> On 22/01/2019 12:02, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-01-21 at 12:30 +0100, Leo Korinth wrote: >> Hi, >> >> I have a new update that uses Reference.reachabilityFence to make >> sure that allocations are not optimized away. After a bit of thinking >> and asking around, I believe reachabilityFence to be a better >> solution than a public static variable in these cases where we want >> to make sure allocation is not optimized away but do not want the >> object to be reachable. It also makes it a bit more obvious that the >> code is used to allocate garbage and not to be optimized away rather >> than being a programming mistake. >> >> I also added spaces to the "XXX*M" pattern. >> >> Webrev (Full): http://cr.openjdk.java.net/~lkorinth/8217389/01 >> Webrev (Incremental): >> http://cr.openjdk.java.net/~lkorinth/8217389/00_01 >> >> Testing: gc test suite still passes. > > Looks good. Thanks for your review. > > Note that some tests use System.out.println(some-object) to achieve the > same effect - maybe using reachabilityFence there might be worthwhile > too. Thanks for pointing this out. I have created: https://bugs.openjdk.java.net/browse/JDK-8217515 JTREG: clean up, use Reference.reachabilityFence instead of System.out.println (and assigned it to me). I do not want to add it to this fix and create too big webrevs/long reviews. Thanks, Leo > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Jan 22 13:03:22 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 14:03:22 +0100 Subject: RFR: 8217389: JTREG: Clean up, remove unused variable warnings In-Reply-To: <61217926-63b0-a28d-38a0-d0b89821d57b@oracle.com> References: <99fbfb39-0a23-f06a-8389-a9512629b8fb@oracle.com> <6138cc9f-267c-ee4a-b62e-e3ffe0a4a04d@oracle.com> <61a4559a-5a32-3324-73fa-a727b68c20b8@oracle.com> <61217926-63b0-a28d-38a0-d0b89821d57b@oracle.com> Message-ID: Hi, On Tue, 2019-01-22 at 14:01 +0100, Leo Korinth wrote: > > On 22/01/2019 12:02, Thomas Schatzl wrote: > > Hi, > > [..] > > > > Note that some tests use System.out.println(some-object) to achieve > > the same effect - maybe using reachabilityFence there might be > > worthwhile too. > > Thanks for pointing this out. I have created: > https://bugs.openjdk.java.net/browse/JDK-82175155 JTREG: clean up, > use Reference.reachabilityFence instead of System.out.println (and > assigned it to me). > > I do not want to add it to this fix and create too big webrevs/long > reviews. That's fine, and has been the intention to do it separately. Thomas From hohensee at amazon.com Tue Jan 22 15:19:24 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 22 Jan 2019 15:19:24 +0000 Subject: RFR(XXS): 8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java Message-ID: Please review this small cleanup. JBS: https://bugs.openjdk.java.net/browse/JDK-8217520 Webrev: http://cr.openjdk.java.net/~phh/8217520/webrev.00/ This change is in response to a comment by Thomas as part of a review of the backport of JDK-8195115 to jdk8u. See https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024570.html Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu at redhat.com Tue Jan 22 15:22:35 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jan 2019 10:22:35 -0500 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> Message-ID: Hi Thomas, Shenandoah part looks good to me. Nits: *) weakProcessor.inline.hpp Line #52 indent *) weakProcessor.cpp includes both .hpp and .inline.hpp Thanks, -Zhengyu On 1/22/19 5:02 AM, Thomas Schatzl wrote: > Hi all, > > On Sat, 2019-01-12 at 04:52 -0500, Kim Barrett wrote: >>> On Jan 11, 2019, at 9:51 PM, Kim Barrett >>> wrote: >>> >>>> On Jan 10, 2019, at 3:46 PM, Thomas Schatzl < >>>> thomas.schatzl at oracle.com> wrote: >>>> [?] >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8213229 >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ >>>> Testing: >>>> hs-tier1-6, performance checking with our performance suite >>>> showed no particular performance differences before/after > > Updated webrev at > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1_to_2 (diff) > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2/ (full) > > implementing the notification of the ServiceThread and applying Kim's > naming suggestion. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Jan 22 15:29:09 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 16:29:09 +0100 Subject: RFR(XXS): 8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java In-Reply-To: References: Message-ID: Hi, On Tue, 2019-01-22 at 15:19 +0000, Hohensee, Paul wrote: > Please review this small cleanup. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8217520 > Webrev: http://cr.openjdk.java.net/~phh/8217520/webrev.00/ > > This change is in response to a comment by Thomas as part of a review > of the backport of JDK-8195115 to jdk8u. See > > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024570.html > looks good. Thanks, Thomas From thomas.schatzl at oracle.com Tue Jan 22 15:31:40 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 16:31:40 +0100 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> Message-ID: <1e5e48724a40062a96277a70faad62f11168529b.camel@oracle.com> Hi Zhengyu, On Tue, 2019-01-22 at 10:22 -0500, Zhengyu Gu wrote: > Hi Thomas, > > Shenandoah part looks good to me. > > Nits: > > *) weakProcessor.inline.hpp Line #52 indent > > *) weakProcessor.cpp includes both .hpp and .inline.hpp > thanks for your review. Fixed both issues and regenerated change at the old location. Thanks, Thomas From roman at kennke.org Sun Jan 20 10:05:38 2019 From: roman at kennke.org (Roman Kennke) Date: Sun, 20 Jan 2019 11:05:38 +0100 Subject: RFR [URGENT] (XS) 8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free) In-Reply-To: References: Message-ID: <2F949C04-C4D2-4593-B2A5-52D265621A6F@kennke.org> Yup. Thanks! Roman Am 20. Januar 2019 10:10:34 MEZ schrieb Aleksey Shipilev : >Bug: > https://bugs.openjdk.java.net/browse/JDK-8217419 > >Fix: > >diff -r 9ff1e6cacac3 >src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp >--- a/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp >Sat Jan 19 19:50:01 2019 -0500 >+++ b/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp >Sun Jan 20 10:06:16 2019 +0100 >@@ -1,5 +1,5 @@ > /* >- * Copyright (c) 2018, Red Hat, Inc. All rights reserved. >+ * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as >@@ -29,7 +29,7 @@ > > ShenandoahSATBMarkQueueSet::ShenandoahSATBMarkQueueSet() : > _heap(NULL), >- _satb_mark_queue_buffer_allocator(ShenandoahSATBBufferSize, >SATB_Q_FL_lock) >+ _satb_mark_queue_buffer_allocator("SATB Buffer Allocator", >ShenandoahSATBBufferSize) > {} > >void ShenandoahSATBMarkQueueSet::initialize(ShenandoahHeap* const heap, > > >Testing: Linux x86_64 build, hotspot_gc_shenandoah > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From hohensee at amazon.com Tue Jan 22 17:00:31 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 22 Jan 2019 17:00:31 +0000 Subject: RFR(XXS): 8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java In-Reply-To: References: Message-ID: <595E91EE-A8FC-409A-81B1-49AE7F8343AE@amazon.com> Thanks for your review. May I consider this trivial and push? ?On 1/22/19, 7:30 AM, "Thomas Schatzl" wrote: Hi, On Tue, 2019-01-22 at 15:19 +0000, Hohensee, Paul wrote: > Please review this small cleanup. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8217520 > Webrev: http://cr.openjdk.java.net/~phh/8217520/webrev.00/ > > This change is in response to a comment by Thomas as part of a review > of the backport of JDK-8195115 to jdk8u. See > > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024570.html > looks good. Thanks, Thomas From thomas.schatzl at oracle.com Tue Jan 22 18:37:29 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Jan 2019 19:37:29 +0100 Subject: RFR(XXS): 8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java In-Reply-To: <595E91EE-A8FC-409A-81B1-49AE7F8343AE@amazon.com> References: <595E91EE-A8FC-409A-81B1-49AE7F8343AE@amazon.com> Message-ID: Hi, On Tue, 2019-01-22 at 17:00 +0000, Hohensee, Paul wrote: > Thanks for your review. May I consider this trivial and push? > yes. Thomas From kim.barrett at oracle.com Tue Jan 22 19:39:19 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Jan 2019 14:39:19 -0500 Subject: RFR: 8217474: Remove WhiteBox.getConcurrentGCPhases() Message-ID: Please review this change to remove a not really useful test and the assocated infrastructure. The test really doesn't carry its weight. This is a step toward improving the WhiteBox control of concurrent collection cycles, to make it more amenable for use by ZGC too. [I'll update copyrights before pushing.] CR: https://bugs.openjdk.java.net/browse/JDK-8217474 Webrev: http://cr.openjdk.java.net/~kbarrett/8217474/open.00/ Testing: mach5 tier1, which includes running the tests in jtreg/gc/concurrent_phase_control. From shade at redhat.com Tue Jan 22 19:43:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jan 2019 20:43:27 +0100 Subject: RFR: 8217474: Remove WhiteBox.getConcurrentGCPhases() In-Reply-To: References: Message-ID: On 1/22/19 8:39 PM, Kim Barrett wrote: > Please review this change to remove a not really useful test and the > assocated infrastructure. The test really doesn't carry its weight. > > This is a step toward improving the WhiteBox control of concurrent > collection cycles, to make it more amenable for use by ZGC too. > > [I'll update copyrights before pushing.] > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217474 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8217474/open.00/ Yes, please. I was scratching my head if/how to adapt this to Shenandoah, but decided it was not worth it. The patch looks good. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kim.barrett at oracle.com Tue Jan 22 20:30:21 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Jan 2019 15:30:21 -0500 Subject: RFR: 8217474: Remove WhiteBox.getConcurrentGCPhases() In-Reply-To: References: Message-ID: <37249EA7-C651-43F1-9073-A2B0A0CB2BFC@oracle.com> > On Jan 22, 2019, at 2:43 PM, Aleksey Shipilev wrote: > > On 1/22/19 8:39 PM, Kim Barrett wrote: >> Please review this change to remove a not really useful test and the >> assocated infrastructure. The test really doesn't carry its weight. >> >> This is a step toward improving the WhiteBox control of concurrent >> collection cycles, to make it more amenable for use by ZGC too. >> >> [I'll update copyrights before pushing.] >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8217474 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8217474/open.00/ > > Yes, please. I was scratching my head if/how to adapt this to Shenandoah, but decided it was not > worth it. The patch looks good. > > -Aleksey Thanks. There are more changes coming. This one is just getting rid of some deadwood to make later changes smaller and more focused. The goal is to have something that all of G1, Z, and Shenandoah can use without too much head scratching. From zgu at redhat.com Tue Jan 22 20:52:36 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jan 2019 15:52:36 -0500 Subject: RFR(XXS) 8217522: Missing barriers in some java_lang_String assertion code after JDK-8213229 Message-ID: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> Although the changes are in shared code, but they only affect Shenandoah. Once JDK-8213229 pushed, we need this patch to unbreak Shenandoah tests. The root cause, after JDK-8213229, is that references in stringtable are updated concurrently, instead of at safepoints. Bug: https://bugs.openjdk.java.net/browse/JDK-8217522 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217522/webrev.00/ Test: hotspot_gc, tier1, 2, 3_gc_shenandoah on Linux x64 (fastdebug) Thanks, -Zhengyu From shade at redhat.com Tue Jan 22 20:58:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jan 2019 21:58:30 +0100 Subject: RFR(XXS) 8217522: Missing barriers in some java_lang_String assertion code after JDK-8213229 In-Reply-To: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> References: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> Message-ID: <0c93d74c-7705-ab75-ef7f-b0f0d0547174@redhat.com> On 1/22/19 9:52 PM, Zhengyu Gu wrote: > Although the changes are in shared code, but they only affect Shenandoah. > > Once JDK-8213229 pushed, we need this patch to unbreak Shenandoah tests. The root cause, after > JDK-8213229, is that references in stringtable are updated concurrently, instead of at safepoints. Ah, dang. I suggested oopDesc::equals_raw to Claes, hoping that would be enough. Yes, stronger oopDesc::equals is preferred. It is mildly irritating those can be different copies of the object, though, but it is safe because we are only reading from them. Looks good! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Tue Jan 22 21:00:32 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jan 2019 16:00:32 -0500 Subject: RFR(XXS) 8217522: Missing barriers in some java_lang_String assertion code after JDK-8213229 In-Reply-To: <0c93d74c-7705-ab75-ef7f-b0f0d0547174@redhat.com> References: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> <0c93d74c-7705-ab75-ef7f-b0f0d0547174@redhat.com> Message-ID: <424a0f5b-7308-4b77-d10f-126e3dba3cee@redhat.com> On 1/22/19 3:58 PM, Aleksey Shipilev wrote: > On 1/22/19 9:52 PM, Zhengyu Gu wrote: >> Although the changes are in shared code, but they only affect Shenandoah. >> >> Once JDK-8213229 pushed, we need this patch to unbreak Shenandoah tests. The root cause, after >> JDK-8213229, is that references in stringtable are updated concurrently, instead of at safepoints. > > Ah, dang. I suggested oopDesc::equals_raw to Claes, hoping that would be enough. Yes, stronger > oopDesc::equals is preferred. It is mildly irritating those can be different copies of the object, > though, but it is safe because we are only reading from them. I noticed that, his final patch does not have oopDesc::equals_raw ... Thanks, -Zhengyu > > Looks good! > > -Aleksey > > > From claes.redestad at oracle.com Tue Jan 22 22:52:30 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 23:52:30 +0100 Subject: RFR(XXS) 8217522: Missing barriers in some java_lang_String assertion code after JDK-8213229 In-Reply-To: <424a0f5b-7308-4b77-d10f-126e3dba3cee@redhat.com> References: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> <0c93d74c-7705-ab75-ef7f-b0f0d0547174@redhat.com> <424a0f5b-7308-4b77-d10f-126e3dba3cee@redhat.com> Message-ID: On 2019-01-22 22:00, Zhengyu Gu wrote: >> Ah, dang. I suggested oopDesc::equals_raw to Claes, hoping that would >> be enough. Yes, stronger >> oopDesc::equals is preferred. It is mildly irritating those can be >> different copies of the object, >> though, but it is safe because we are only reading from them. > > I noticed that, his final patch does not have oopDesc::equals_raw ... There was a version of that patch out for review - based on suggestions from David Holmes - which we ended up backing away from. The pushed patch uses oopDesc::equals_raw in a few assertions: http://hg.openjdk.java.net/jdk/jdk/rev/bc2bb4eee477 Changing these to oopDesc::equals sounds OK to me. /Claes From zgu at redhat.com Wed Jan 23 00:13:46 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jan 2019 19:13:46 -0500 Subject: RFR(XXS) 8217522: Missing barriers in some java_lang_String assertion code after JDK-8213229 In-Reply-To: References: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> <0c93d74c-7705-ab75-ef7f-b0f0d0547174@redhat.com> <424a0f5b-7308-4b77-d10f-126e3dba3cee@redhat.com> Message-ID: <07fb76ef-3d43-cffb-7231-de9fa5075c9c@redhat.com> Hi Claes, On 1/22/19 5:52 PM, Claes Redestad wrote: > > On 2019-01-22 22:00, Zhengyu Gu wrote: >>> Ah, dang. I suggested oopDesc::equals_raw to Claes, hoping that would >>> be enough. Yes, stronger >>> oopDesc::equals is preferred. It is mildly irritating those can be >>> different copies of the object, >>> though, but it is safe because we are only reading from them. >> >> I noticed that, his final patch does not have oopDesc::equals_raw ... > > There was a version of that patch out for review - based on suggestions > from David Holmes - which we ended up backing away from. The pushed > patch uses oopDesc::equals_raw in a few assertions: > http://hg.openjdk.java.net/jdk/jdk/rev/bc2bb4eee477 > > Changing these to oopDesc::equals sounds OK to me. Thanks you for pointing out. I will rebase my changes. -Zhengyu > > /Claes From zgu at redhat.com Wed Jan 23 00:28:56 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jan 2019 19:28:56 -0500 Subject: RFR(XXS) 8217522: Missing barriers in some java_lang_String assertion code after JDK-8213229 In-Reply-To: References: <00e3def6-acb3-e15d-ab29-f40832eae4ba@redhat.com> <0c93d74c-7705-ab75-ef7f-b0f0d0547174@redhat.com> <424a0f5b-7308-4b77-d10f-126e3dba3cee@redhat.com> Message-ID: <64ed45ce-6b14-d1a1-7d21-6d01d74e903a@redhat.com> On 1/22/19 5:52 PM, Claes Redestad wrote: > > On 2019-01-22 22:00, Zhengyu Gu wrote: >>> Ah, dang. I suggested oopDesc::equals_raw to Claes, hoping that would >>> be enough. Yes, stronger >>> oopDesc::equals is preferred. It is mildly irritating those can be >>> different copies of the object, >>> though, but it is safe because we are only reading from them. >> >> I noticed that, his final patch does not have oopDesc::equals_raw ... > > There was a version of that patch out for review - based on suggestions > from David Holmes - which we ended up backing away from. The pushed > patch uses oopDesc::equals_raw in a few assertions: > http://hg.openjdk.java.net/jdk/jdk/rev/bc2bb4eee477 Ah, I did not realize equals_raw was from this changeset :-) I thought they are pre-existing code. Sorry for the confusing replies. > > Changing these to oopDesc::equals sounds OK to me. Thanks for the review, Aleksey and Claes. -Zhengyu > > /Claes From thomas.schatzl at oracle.com Wed Jan 23 09:51:54 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 23 Jan 2019 10:51:54 +0100 Subject: RFR: 8214799: Add package declaration to each JTREG test case in the gc folder In-Reply-To: <5acce3ca-6fd1-9024-1946-e4d866d97bbf@oracle.com> References: <19bae948-ec2b-257e-d0fc-69ff95093642@oracle.com> <3899785E-F88A-4F4B-8DE7-9002F7835AD3@oracle.com> <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> <2A5A69F0-0995-4E95-8EA9-2F90A4BD5A37@oracle.com> <5acce3ca-6fd1-9024-1946-e4d866d97bbf@oracle.com> Message-ID: <4df492e6b70edc553e81dcfb664f240354917f56.camel@oracle.com> Hi, On Thu, 2019-01-17 at 16:58 +0100, Leo Korinth wrote: > Hi, > > I have added package name to newly added > TestPeriodicLogMessages.java. > > I would be happy for a review from a reviewer (for the whole change, > not > only this test). > > The updated test case has been tested. Good change to decrease the threshold to improve these :) .02 changes and below diff look good. Thomas > > /Leo > > > diff --git a/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java > b/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java > index 2cede583c45..bd02a6e1c0a 100644 > --- a/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java > +++ b/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java > @@ -21,6 +21,8 @@ > * questions. > */ > > +package gc.g1; > + > /** > * @test TestPeriodicLogMessages > * @bug 8216490 > @@ -29,6 +31,7 @@ > * @library /test/lib / > * @modules java.base/jdk.internal.misc > * @modules java.management/sun.management > + * @run main gc.g1.TestPeriodicLogMessages > */ > > import jdk.test.lib.process.OutputAnalyzer; > From thomas.schatzl at oracle.com Wed Jan 23 10:42:01 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 23 Jan 2019 11:42:01 +0100 Subject: 8217329: JTREG: Clean up, remove unused imports in gc folder In-Reply-To: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> References: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> Message-ID: Hi, On Thu, 2019-01-17 at 17:58 +0100, Leo Korinth wrote: > Hi, > > This fix removes unused imports and newlines in the jtreg/gc folder. > > This fix is somewhat based/dependent on "8214799: Add package > declaration to each JTREG test case in the gc folder". That fix is > out for review. I assume the work has been performed mostly mechanically with an IDE (Eclipse?) to make sure they are good :) Looks good. Thomas From thomas.schatzl at oracle.com Wed Jan 23 10:49:06 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 23 Jan 2019 11:49:06 +0100 Subject: RFR: 8217385: JTREG: Clean up, make sure to close resources In-Reply-To: References: Message-ID: Hi, On Fri, 2019-01-18 at 17:00 +0100, Leo Korinth wrote: > Hi, > > This clean up closes resources in some test cases in the jtreg/gc > folder. > > This fix is somewhat based/dependent on the rest of my "JTREG:" > webrevs. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8217385 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8217385/00 > > Testing: > passed locally: open/test/hotspot/jtreg/:hotspot_gc Seems good to me. Thanks, Thomas From thomas.schatzl at oracle.com Wed Jan 23 11:04:27 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 23 Jan 2019 12:04:27 +0100 Subject: RFR: 8217474: Remove WhiteBox.getConcurrentGCPhases() In-Reply-To: References: Message-ID: Hi, On Tue, 2019-01-22 at 14:39 -0500, Kim Barrett wrote: > Please review this change to remove a not really useful test and the > assocated infrastructure. The test really doesn't carry its weight. > > This is a step toward improving the WhiteBox control of concurrent > collection cycles, to make it more amenable for use by ZGC too. > > [I'll update copyrights before pushing.] > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217474 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8217474/open.00/ > > Testing: > mach5 tier1, which includes running the tests in > jtreg/gc/concurrent_phase_control. > > looks good. Thomas From leo.korinth at oracle.com Wed Jan 23 13:11:28 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 23 Jan 2019 14:11:28 +0100 Subject: 8217329: JTREG: Clean up, remove unused imports in gc folder In-Reply-To: References: <6294ac53-09c0-c31e-83a7-eceb6958c3b3@oracle.com> Message-ID: <88f0e27a-4878-ed6c-8e34-cba37e034524@oracle.com> On 23/01/2019 11:42, Thomas Schatzl wrote: > Hi, > > On Thu, 2019-01-17 at 17:58 +0100, Leo Korinth wrote: >> Hi, >> >> This fix removes unused imports and newlines in the jtreg/gc folder. >> >> This fix is somewhat based/dependent on "8214799: Add package >> declaration to each JTREG test case in the gc folder". That fix is >> out for review. > > I assume the work has been performed mostly mechanically with an IDE > (Eclipse?) to make sure they are good :) Yes, with packages, Eclipse is easy to set up. > Looks good. > > Thomas > > Thanks for the review! /Leo From leo.korinth at oracle.com Wed Jan 23 13:14:28 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 23 Jan 2019 14:14:28 +0100 Subject: RFR: 8217385: JTREG: Clean up, make sure to close resources In-Reply-To: References: Message-ID: <1ed9d4db-d0a5-b7fb-531c-b788b28c1c47@oracle.com> Thanks for your review! /Leo On 23/01/2019 11:49, Thomas Schatzl wrote: > Hi, > > On Fri, 2019-01-18 at 17:00 +0100, Leo Korinth wrote: >> Hi, >> >> This clean up closes resources in some test cases in the jtreg/gc >> folder. >> >> This fix is somewhat based/dependent on the rest of my "JTREG:" >> webrevs. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8217385 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8217385/00 >> >> Testing: >> passed locally: open/test/hotspot/jtreg/:hotspot_gc > > Seems good to me. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Wed Jan 23 13:48:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 23 Jan 2019 14:48:20 +0100 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> Message-ID: <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> Hi, On Thu, 2019-01-17 at 09:30 -0500, Zhengyu Gu wrote: > Ping! > > In addition to hotspot_gc tests (+/- UseOWSTTaskTerminator) on Linux > 64, also ran vmTestbase_vm_gc (+/- UseOWSTTaskterminator) and submit > tests. currently running it through our test suite. > > Thanks, > > -Zhengyu > > On 1/3/19 10:49 AM, zgu at redhat.com wrote: > > Threads that enter termination protocol, should always see the same > > termination result, terminated or aborted. And terminator should > > always complete in one of two following states: > > > > Terminated: _offered_termination == _n_threads (all threads arrived > > and terminated) > > Aborted: _offered_termination = 0 (none of threads completed) > > > > Current implementation does not guarantee that, so that, it can > > leave terminator in inconsistent states. The inconsistent states > > can trigger assertion failure when reset the terminator for reuse > > (vs. reset_for_reuse() method) Nice catch. Thanks. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215047 > > Webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.00/index.htm > > l initial comments: - taskqueue.hpp: I recommend adding an empty virtual destructor in any case. - owstTaskTerminator.cpp:69: s/returnning/returning/ I will think a bit more about the change while waiting for the test results. Thanks, Thomas From zgu at redhat.com Wed Jan 23 14:32:45 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 23 Jan 2019 09:32:45 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> Message-ID: <1548253965.31327.2.camel@redhat.com> Hi Thomas, Thanks for getting the review started. > initial comments: > > - taskqueue.hpp: I recommend adding an empty virtual destructor in > any > case. > > - owstTaskTerminator.cpp:69: s/returnning/returning/ > Updated based on your comments: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.01/index.html Thanks, -Zhengyu > I will think a bit more about the change while waiting for the test > results. > > Thanks, > Thomas > From kim.barrett at oracle.com Thu Jan 24 04:07:43 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 23 Jan 2019 23:07:43 -0500 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> Message-ID: <72D53764-202B-48FB-B77B-476C60A7027D@oracle.com> > On Jan 22, 2019, at 5:02 AM, Thomas Schatzl wrote: > > Hi all, > > On Sat, 2019-01-12 at 04:52 -0500, Kim Barrett wrote: >>> On Jan 11, 2019, at 9:51 PM, Kim Barrett >>> wrote: >>> >>>> On Jan 10, 2019, at 3:46 PM, Thomas Schatzl < >>>> thomas.schatzl at oracle.com> wrote: >>>> [?] >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8213229 >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ >>>> Testing: >>>> hs-tier1-6, performance checking with our performance suite >>>> showed no particular performance differences before/after > > Updated webrev at > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1_to_2 (diff) > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2/ (full) > > implementing the notification of the ServiceThread and applying Kim's > naming suggestion. > > Thanks, > Thomas General question: There are various places that now unconditionally report or log information about various string dedup passes, even when string dedup is disabled. I've questioned at least some of them below, but it's so common that now I'm wondering if perhaps this is intentional? ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.cpp 3397 // Ideally we would use a StringDedupCleaningTask here, but since we want to 3398 // take the time we need to copy the code here. Maybe s/take the time/record the time/ ? I found the current wording confusing. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.hpp 1335 // Partial cleaning of VM internal data structures. 1336 // Let the caller choose what structures to clean out: 1337 // - StringDeduplication structures 1338 void partial_cleaning(BoolObjectClosure* is_alive, 1339 OopClosure* keep_alive, 1340 bool process_dedup_table, 1341 G1GCPhaseTimes* phase_times = NULL); Now that there's just the one data structure involved, maybe this should be clean_dedup_table() or something like that? Unless you think there might be some more things to be added later? ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.hpp 1343 // Complete cleaning used when class unloading is enabled. 1344 // Cleans out all structures handled by partial_cleaning and also the CodeCache. 1345 void complete_cleaning(BoolObjectClosure* is_alive, bool class_unloading_occurred); [pre-existing] Comment here seems incorrect, since complete_cleaning also includes KlassCleaningTask. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.cpp 3962 { 3963 double cleaning_start = os::elapsedTime(); 3965 partial_cleaning(&is_alive, 3966 &keep_alive, 3967 G1StringDedup::is_enabled() /* process_dedup_table */, 3968 g1_policy()->phase_times()); 3969 3970 double cleaning_time_ms = (os::elapsedTime() - cleaning_start) * 1000.0; 3971 g1_policy()->phase_times()->record_string_deduplication_time(cleaning_time_ms); 3972 } This is now recording a time even if dedup is not enabled, where the old code made the whole thing, including time-recording, conditional on dedup being enabled. But in the old code it was manifestly obvious we were only dealing with dedup, while here it's somewhat hidden. It seems wrong to assume that the only contributor to "partial_cleaning" time is (conditional) dedup. But see earlier comment about the partial_cleaning name. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1FullCollector.cpp 228 GCTraceTime(Debug, gc, phases) debug("Phase 1: String Dedup Cleanup", scope()->timer()); 229 // If no class unloading just clean out string deduplication data. 230 _heap->partial_cleaning(&_is_alive, NULL, G1StringDedup::is_enabled()); Again here we're reporting time for a possibly disabled operation. The old code unconditionally also processed the string table, so unconditionally reporting the time was fine. And again we're assuming the only contributor to partial_cleaning time is (conditional) dedup. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp 431 debug_time("String Deduplication", _cur_string_deduplication_time_ms); 432 if (G1StringDedup::is_enabled()) { Why is dedup time now reported unconditionally? ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.inline.hpp 51 bool result = _inner->do_object_b(obj); 52 _num_dead += !result; 57 size_t num_dead() const { return _num_dead; } This calculates the number of recently deceased, and does not include entries that were nulled out by some previous collection but not yet removed by the service thread. But the calculations based on: 89 StringTable::inc_dead_counter(cl.num_dead()); want the number of nulled out entries. I don't see a convenient way to obtain the number that should be passed to inc_dead_counter here, at least not while using weak_oops_do. What I think needs to be passed to inc_dead_counter is the number of previously nulled entries + the number of newly dead entries. Using oops_do rather than weak_oops_do would allow getting the missing number. The serial WeakProcessor has the same problem. We talked about this offline last week, and I think we got it wrong. I was working with what I remembered of that part of the StringTable API, and it looks like my memory was faulty. Sorry about that. ------------------------------------------------------------------------------ From leihouyju at gmail.com Thu Jan 24 08:58:37 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Thu, 24 Jan 2019 16:58:37 +0800 Subject: [PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance In-Reply-To: References: Message-ID: Hi Kim, I have ported my patch to OpenJDK 13 according to your instructions in your last mail, and the patch is attached in this mail. The patch does not change much since PSGC is indeed pretty stable. Also, I evaluate the correctness and performance of PS full GC with benchmarks from DaCapo, SPECjvm2008, and JOlden suits on a machine with dual Intel Xeon E5-2618L v3 CPUs(16 physical cores), 64G DRAM and linux kernel 4.17. The evaluation result, indicating 1.9X GC throughput improvement on average, is attached, too. However, I have no idea how to further test this patch for both correctness and performance. Can I please get any guidance from you or some sponsor? Best Regrads, Haoyu Li, Institute of Parallel and Distributed Systems(IPADS), School of Software, Shanghai Jiao Tong University Kim Barrett ?2019?1?16??? ??12:33??? > > On Dec 23, 2018, at 12:38 PM, Haoyu Li wrote: > > > > Hi all? > > I have developed a patch to enhance the full GC performance of Parallel > Scavenge on OpenJDK 11, may I have some reviews? The patch is described as > follows and attached in this mail. > > > > [?] > > > > The patch and evaluation result are attached. > > > > Best Regrads, > > Haoyu Li, > > Institute of Parallel and Distributed Systems(IPADS), > > School of Software, > > Shanghai Jiao Tong University > > Thanks for offering to contribute to the OpenJDK project. Sorry it's > taken a while to respond, but holidays &etc intervened. > > The idea of the patch sounds interesting. However, before we can > proceed, there may be some process issues that need to be addressed. > > The first, and most critical: are you covered by an Oracle Contributor > Agreement (either individually or via an employer who is sponsoring > this work)? If not, that needs to be dealt with first. For details, > see https://openjdk.java.net/contribute/. > > Another is that current development is going into the jdk repo > http://hg.openjdk.java.net/jdk/jdk/ (which is currently targeting JDK > 13), while your email suggests your patch is against the OpenJDK 11 > release. This kind of change should be made in the current line of > development, and then perhaps considered for backporting. So the > patch will likely need to be updated. (It might not require all that > much modification though; ParallelGC has been pretty stable for a > while.) > > Since you don't appear to be an OpenJDK committer/author, you'll need > a sponsor to help with some of the other pieces of the puzzle: > > Each change requires an associated bug ID, from the OpenJDK bug > database. Without a username there (which requires OpenJDK author > status), your sponsor can create the CR there. > > Also, changes of more than some trivial extent generally get packaged > for review using the webrev tool, and published on cr.openjdk.java.net. > https://openjdk.java.net/guide/codeReview.html > Your sponsor can help you with that. > > Your change may need additional testing (both for correctness and > performance). For example, you don't mention what platforms you've > tested on, there are a lot of functional tests for OpenJDK, and there > are probably other performance tests that should be applied to a > change like this. > > For a change like this, your sponsor should be someone currently > involved in OpenJDK GC development, preferably in an area related to > the patch. It's not required that they be an Oracle employee, though > for some things that might help. I can help you find someone. (It > might be me, but I don't want to commit to that today.) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shadow-region.patch Type: text/x-patch Size: 24280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: performance.png Type: image/png Size: 22874 bytes Desc: not available URL: From rwestrel at redhat.com Thu Jan 24 09:23:59 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 24 Jan 2019 10:23:59 +0100 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> Message-ID: <87bm4676j4.fsf@redhat.com> http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.00/ That looks good to me. But don't you need a similar change for aarch64? Roland. From per.liden at oracle.com Thu Jan 24 11:05:54 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 24 Jan 2019 12:05:54 +0100 Subject: RFR: 8217717: ZGC: Broken oop map in C1 load barrier stub Message-ID: The C1 load barrier stub for ZGC can emit a patching area for a lea instruction. However, the call into the VM to do the patching at this site is not associated with a proper oop map. As a result, we can end up with a stable oop in the base pointer register if a GC safepoint happens when we enter the VM to patch. This problem is not super easy to reproduce by default, but is a serious bug when it happens. However, it is fairly easy to reproduce when also injecting a small delay in the ZNMethodTable::register_nmethod(). The proposed solution is to never allow patching to happen inside the load barrier stub. Instead, if patching is needed, we emit the lea instruction as part of the load preceding the load barrier. That will automatically generate the proper oop map for the patch site. Bug: https://bugs.openjdk.java.net/browse/JDK-8217717 Webrev: http://cr.openjdk.java.net/~pliden/8217717/webrev.0 Testing: Manual testing and inspection of generated code. Passes gc-test-suite. Currently running tier1-3 on all platforms, and tier1-7 on Linux/x86. /Per From shade at redhat.com Thu Jan 24 11:44:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 Jan 2019 12:44:20 +0100 Subject: RFR (XS) 8217471: [TESTBUG] gc/epsilon/TestClasses.java fails on some platforms - OOME Metaspace Message-ID: <21def557-2d46-9ddd-a34c-2a7f336f30f6@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8217471 Newly added test limits max metaspace size to 32M and then allocates lots of classes. Turns out, some machines just barely do not fit that limit. Many thanks to David Holmes for testing the change on the offending Solaris box. I also used the more aggressive options on x86_64 (e.g. -Xcomp lines provided by Mikael) to reproduce and test it locally. It seems the next step, 64M fits broken configurations well. Fix: diff -r 091ed8f2e7d7 test/hotspot/jtreg/gc/epsilon/TestClasses.java --- a/test/hotspot/jtreg/gc/epsilon/TestClasses.java Thu Jan 24 12:45:19 2019 +0530 +++ b/test/hotspot/jtreg/gc/epsilon/TestClasses.java Thu Jan 24 12:41:42 2019 +0100 @@ -28,11 +28,11 @@ * @summary Epsilon is able to allocate a lot of classes * * @modules java.base/jdk.internal.org.objectweb.asm * java.base/jdk.internal.misc * - * @run main/othervm -Xmx128m -XX:MetaspaceSize=1m -XX:MaxMetaspaceSize=32m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc -Xlog:gc+metaspace TestClasses + * @run main/othervm -Xmx128m -XX:MetaspaceSize=1m -XX:MaxMetaspaceSize=64m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc -Xlog:gc+metaspace TestClasses */ import jdk.internal.org.objectweb.asm.ClassWriter; import jdk.internal.org.objectweb.asm.Opcodes; Testing: Linux x86_64 gc/epsilon, jdk-submit (running) Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From per.liden at oracle.com Thu Jan 24 12:29:52 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 24 Jan 2019 13:29:52 +0100 Subject: RFR: 8217717: ZGC: Broken oop map in C1 load barrier stub In-Reply-To: References: Message-ID: <855f6ad9-f400-889d-86bb-be816f1a7cb3@oracle.com> On 1/24/19 12:05 PM, Per Liden wrote: > The C1 load barrier stub for ZGC can emit a patching area for a lea > instruction. However, the call into the VM to do the patching at this > site is not associated with a proper oop map. As a result, we can end up > with a stable oop in the base pointer register if a GC safepoint happens s/stable/stale/ ;) > when we enter the VM to patch. > > This problem is not super easy to reproduce by default, but is a serious > bug when it happens. However, it is fairly easy to reproduce when also > injecting a small delay in the ZNMethodTable::register_nmethod(). > > The proposed solution is to never allow patching to happen inside the > load barrier stub. Instead, if patching is needed, we emit the lea > instruction as part of the load preceding the load barrier. That will > automatically generate the proper oop map for the patch site. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217717 > Webrev: http://cr.openjdk.java.net/~pliden/8217717/webrev.0 > > Testing: Manual testing and inspection of generated code. Passes > gc-test-suite. Currently running tier1-3 on all platforms, and tier1-7 > on Linux/x86. > > /Per From thomas.schatzl at oracle.com Thu Jan 24 12:55:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 24 Jan 2019 13:55:20 +0100 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: <72D53764-202B-48FB-B77B-476C60A7027D@oracle.com> References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> <72D53764-202B-48FB-B77B-476C60A7027D@oracle.com> Message-ID: <6288740d1483e78e6bc3b8be6f1d3f52993611fb.camel@oracle.com> Hi, On Wed, 2019-01-23 at 23:07 -0500, Kim Barrett wrote: > > On Jan 22, 2019, at 5:02 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > On Sat, 2019-01-12 at 04:52 -0500, Kim Barrett wrote: > > > > On Jan 11, 2019, at 9:51 PM, Kim Barrett < > > > > kim.barrett at oracle.com> > > > > wrote: > > > > > > > > > On Jan 10, 2019, at 3:46 PM, Thomas Schatzl < > > > > > thomas.schatzl at oracle.com> wrote: > > > > > [?] > > > > > CR: > > > > > https://bugs.openjdk.java.net/browse/JDK-8213229 > > > > > Webrev: > > > > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/ > > > > > Testing: > > > > > hs-tier1-6, performance checking with our performance suite > > > > > showed no particular performance differences before/after > > > > Updated webrev at > > > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1_to_2 (diff) > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2/ (full) > > > > implementing the notification of the ServiceThread and applying > > Kim's naming suggestion. > > > > Thanks, > > Thomas > > General question: There are various places that now unconditionally > report or log information about various string dedup passes, even > when string dedup is disabled. I've questioned at least some of them > below, but it's so common that now I'm wondering if perhaps this is > intentional? I was already prototyping a change that moved more work into the PartialCleaningTask, and backed it out before proposing the change. Naturally it would have unconditional timing of the whole phase (like suggested e.g. in JDK-8040006 - including e.g. WeakProcessor handling and the card table clear in that phase too). When removing these changes, I kept parts of what I found somewhat useful to have - like always reporting (total) timing for this phase. Reconsidering, I think we should not cram this into this change. There is a new webrev that removes all that. > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1CollectedHeap.cpp > 3397 // Ideally we would use a StringDedupCleaningTask here, but > since we want to > 3398 // take the time we need to copy the code here. > > Maybe s/take the time/record the time/ ? > > I found the current wording confusing. This code is a duplicate of StringDedupCleaningTask (which ultimately calls StringDedup::parallel_unlink, which calls these two unlink_or_oops_do methods); however, I did not want to mess with the StringDedup* code introducing parameters for passing a container to hold the various subtimings here. How to collect timing information across gangtasks should imho be a different discussion. I would like to at least try to avoid having a separate "StringDedupTiming" class just for string dedup like done so (too?) often already (ref proc, weak processor, ...) That's why the change basically copy&pastes the code from StringDedup::parallel_unlink() here. I hope the new code is more understandable. [...] > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1CollectedHeap.hpp > 1343 // Complete cleaning used when class unloading is enabled. > 1344 // Cleans out all structures handled by partial_cleaning and > also the CodeCache. > 1345 void complete_cleaning(BoolObjectClosure* is_alive, bool > class_unloading_occurred); > > [pre-existing] Comment here seems incorrect, since complete_cleaning > also includes KlassCleaningTask. Fixed. [...] > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.inline.hpp > 51 bool result = _inner->do_object_b(obj); > 52 _num_dead += !result; > > 57 size_t num_dead() const { return _num_dead; } > > This calculates the number of recently deceased, and does not include > entries that were nulled out by some previous collection but not yet > removed by the service thread. But the calculations based on: > > 89 StringTable::inc_dead_counter(cl.num_dead()); > > want the number of nulled out entries. > > I don't see a convenient way to obtain the number that should be > passed to inc_dead_counter here, at least not while using > weak_oops_do. What I think needs to be passed to inc_dead_counter is > the number of previously nulled entries + the number of newly dead > entries. Using oops_do rather than weak_oops_do would allow getting > the missing number. > > The serial WeakProcessor has the same problem. > > We talked about this offline last week, and I think we got it wrong. > I was working with what I remembered of that part of the StringTable > API, and it looks like my memory was faulty. Sorry about that. >From what I understand this is actually an existing bug - the old code (in StringTable) also directly set StringTable::_uncleaned_items_count as returned by the count of the IsAliveClosure in weak_oops_do(). I would prefer fixing this separately as I believe the exact way to do this best will be another discussion. I can file a CR for that. New webrevs at: http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2_to_3/ (diff) http://cr.openjdk.java.net/~tschatzl/8213229/webrev.3/ (full) Testing: locally running gc/g1, started hs-tier1-5 Thanks, Thomas From erik.osterlund at oracle.com Thu Jan 24 13:49:32 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 24 Jan 2019 14:49:32 +0100 Subject: RFR: 8217717: ZGC: Broken oop map in C1 load barrier stub In-Reply-To: References: Message-ID: Hi Per, Looks good. Thanks, /Erik On 2019-01-24 12:05, Per Liden wrote: > The C1 load barrier stub for ZGC can emit a patching area for a lea > instruction. However, the call into the VM to do the patching at this > site is not associated with a proper oop map. As a result, we can end > up with a stable oop in the base pointer register if a GC safepoint > happens when we enter the VM to patch. > > This problem is not super easy to reproduce by default, but is a > serious bug when it happens. However, it is fairly easy to reproduce > when also injecting a small delay in the > ZNMethodTable::register_nmethod(). > > The proposed solution is to never allow patching to happen inside the > load barrier stub. Instead, if patching is needed, we emit the lea > instruction as part of the load preceding the load barrier. That will > automatically generate the proper oop map for the patch site. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217717 > Webrev: http://cr.openjdk.java.net/~pliden/8217717/webrev.0 > > Testing: Manual testing and inspection of generated code. Passes > gc-test-suite. Currently running tier1-3 on all platforms, and tier1-7 > on Linux/x86. > > /Per From per.liden at oracle.com Thu Jan 24 13:57:57 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 24 Jan 2019 14:57:57 +0100 Subject: RFR: 8217717: ZGC: Broken oop map in C1 load barrier stub In-Reply-To: References: Message-ID: <58b3d6ac-09e8-2af4-32ee-385bd336292f@oracle.com> Thanks Erik! /Per On 1/24/19 2:49 PM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-01-24 12:05, Per Liden wrote: >> The C1 load barrier stub for ZGC can emit a patching area for a lea >> instruction. However, the call into the VM to do the patching at this >> site is not associated with a proper oop map. As a result, we can end >> up with a stable oop in the base pointer register if a GC safepoint >> happens when we enter the VM to patch. >> >> This problem is not super easy to reproduce by default, but is a >> serious bug when it happens. However, it is fairly easy to reproduce >> when also injecting a small delay in the >> ZNMethodTable::register_nmethod(). >> >> The proposed solution is to never allow patching to happen inside the >> load barrier stub. Instead, if patching is needed, we emit the lea >> instruction as part of the load preceding the load barrier. That will >> automatically generate the proper oop map for the patch site. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217717 >> Webrev: http://cr.openjdk.java.net/~pliden/8217717/webrev.0 >> >> Testing: Manual testing and inspection of generated code. Passes >> gc-test-suite. Currently running tier1-3 on all platforms, and tier1-7 >> on Linux/x86. >> >> /Per > From shade at redhat.com Thu Jan 24 15:37:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 Jan 2019 16:37:55 +0100 Subject: RFR (XS) 8215221: Serial GC misreports young GC time In-Reply-To: <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> Message-ID: On 12/18/18 4:52 PM, Kim Barrett wrote: >> On Dec 11, 2018, at 3:23 PM, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215221 >> >> One of our guys pointed out the oddity in Serial GC logs: "Pause Young" includes the timing for Full >> collection, and wrecks up GCId order as well. This is because GCTraceTime-s are nested on those >> paths, and putting them in proper order, closer to collect_generation, fixes it. >> >> The downside is that some of the cleanup actions are now outside the GCTraceTime. Those look >> innocuous to omit to me, though. > > ClassLoaderDataGraph::purge() doesn?t look so innocuous. I haven?t > looked hard at other stuff being omitted from accounting by this change. > > It seems to me that fixing this reporting problem might require some > restructuring of this rather complicated and flag-filled function. Okay, another attempt. This restructures the code a little bit, which IMO makes the flow more understandable. It also eliminates a few flags. Then, the placement for GCTraceTime becomes natural. Well, almost, because it requires some dance around should_do_full_collection, if we want to include young-only epilog into timing. See: http://cr.openjdk.java.net/~shade/8215221/webrev.02/ This passes hotspot_tier1 and my ad-hoc tests. If this is the way to go, I would do jdk-submit, etc. then. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Thu Jan 24 15:45:06 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 24 Jan 2019 16:45:06 +0100 Subject: RFR (XS) 8217471: [TESTBUG] gc/epsilon/TestClasses.java fails on some platforms - OOME Metaspace In-Reply-To: <21def557-2d46-9ddd-a34c-2a7f336f30f6@redhat.com> References: <21def557-2d46-9ddd-a34c-2a7f336f30f6@redhat.com> Message-ID: <8efd136ab8ec38b9bd94bad9a06d31899b587992.camel@oracle.com> Hi, On Thu, 2019-01-24 at 12:44 +0100, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217471 > > Newly added test limits max metaspace size to 32M and then allocates > lots of classes. Turns out, some machines just barely do not fit that > limit. Many thanks to David Holmes for testing the change on the > offending Solaris box. I also used the more aggressive options > on x86_64 (e.g. -Xcomp lines provided by Mikael) to reproduce and > test it locally. It seems the next step, 64M fits broken > configurations well. > > Fix: change looks good. Thanks, Thomas From sangheon.kim at oracle.com Thu Jan 24 17:32:08 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Thu, 24 Jan 2019 09:32:08 -0800 Subject: RFR: 8216258: Make FreeIdSet semaphore-based In-Reply-To: References: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> Message-ID: <283db657-4e77-88d3-7865-bca46f7ad3fb@oracle.com> Hi Kim, On 1/8/19 5:25 PM, Kim Barrett wrote: >> On Jan 8, 2019, at 9:21 AM, Thomas Schatzl wrote: >> On Mon, 2019-01-07 at 19:58 -0500, Kim Barrett wrote: >>> Please review this replacement of the "private" FreeIdSet with >>> G1FreeIdSet, which has a new implementation using a semaphore rather >>> than a monitor. >>> >>> [?] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8216258 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8216258/open.00/ >>> >>> Testing: >>> mach5 tier1-5. >> thanks for the cleanup. > Thanks for looking at it. > >> Some notes: >> >> - is it possible to add a destructor that deletes the G1FreeIdSet >> instance? I am aware that currently the destructor of DirtyCardQueueSet >> is never called, but still it would be nice to clean up afterwards. > I was going to say "but it's right there", but then realized what you > were complaining about was the pre-existing lack of a delete of the > freeidset by the non-existent ~DirtyCardQueueSet. > >> - not sure exactly why uintx is used for G1FreeIdSet::_head_index_mask >> and _head: uintx are 32 bit on 32 bit machines, so the update counter >> will be constrained by 32 bit - bits(size) there anyway. >> >> On 64 bit uintx is 64 bit, so the update counter does have the full 32 >> bit range available, which is probably why uintx has been chosen >> anyway? >> >> I do think that even on 32 bits the remaining range should be >> sufficient so it seems okay. > uintx is used as the type for _head (which affects others, like > _head_index_mask) in order to maximize the size of the update counter. > There's also a check that the size of that counter is not "too small", > e.g. it must be at least BitsPerWord/2. > > Because the size is a thread count (and currently derived from the > number of processors), the assumption is that on a 32bit platform it > will be relatively small compared to a 32bit uintx, and on a 64bit > platform it will be relatively small compared to a 64bit uintx (though > possibly "largish" compared to a 32bit uint). > >> - maybe the cmpxchg loops in G1FreeIdSet::claim_par_id() and >> release_par_id() could be factored out into a helper somehow. > While the cmpxchg loops look structurally fairly similar (don't most > CAS loops look more or less like this?), they really are pretty > different in detail. I couldn't think of a way to produce a non-ugly, > non-obfuscating, common helper. > >> - I would prefer if the "claimed" constant were camel cased like static >> consts should be to make it more distinguishable to regular local >> variables. > Done. > >> - pre-existing: I have no idea what the documentation of G1FreeIdSet >> "// Represents a set of free small integer ids" is supposed to mean. >> Could you fix that comment for the G1FreeIdSet class please? > Changed it to: > > // Represents a set of small integer ids, from which elements can be > // temporarily allocated for exclusive use. The ids are in a > // contiguous range from 'start' to 'start + size'. Used to obtain a > // distinct worker_id value for a mutator thread that doesn't normally > // have such an id. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8216258/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8216258/open.01.inc/ Webrev.01 looks very nice. Sorry for the late review. Thanks, Sangheon > > From leo.korinth at oracle.com Thu Jan 24 18:04:37 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 24 Jan 2019 19:04:37 +0100 Subject: RFR (L): 8217330: Split CollectionSetChooser into collection set candidate container and the chooser algorithm In-Reply-To: References: Message-ID: <49d3c2a3-ee8d-f715-eb6d-833843c0b0f7@oracle.com> Hi Thomas. I think this looks really good, thanks for cleaning this up. Keep in mind my lack of experience. Minor nits: you need to update copyright years. There is an extra (unnecessary) line "bool this_pause_was_last_before_mixed = collector_state()->in_young_gc_before_mixed();" that can be removed. Thanks, Leo On 21/01/2019 12:35, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this cleanup change that splits > CollectionSetChooser into the container holding the collection set > candidates (named G1CollectionSetCandidates) and the > CollectionSetChooser (will be renamed in JDK-8217328) that only > contains static methods to create the candidate set? > > I think this improves readability of the code a lot given this > misnomer. > > Finally it removes some really ugly constructor hack (sorry D. > Detlefs!) with GrowableArray. > > (It actually, if you remove new file headers, reduces code size a bit > too) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217330 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217330/webrev/ > Testing: > hs-tier1-5 > > Thanks, > Thomas > From suenaga.yasumasa at nttcom.co.jp Fri Jan 25 02:35:40 2019 From: suenaga.yasumasa at nttcom.co.jp (Yasumasa Suenaga) Date: Fri, 25 Jan 2019 11:35:40 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> Message-ID: <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> PING: Could you review this? Yasumasa On 2019/01/21 17:52, Yasumasa Suenaga wrote: > Hi all, > > I filed this issue to JBS: > ? https://bugs.openjdk.java.net/browse/JDK-8217432 > > I investigated it, and I found that `minimum_desired_capacity` and > `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()` > might exceed MaxMetaspaceSize. > They shouldn't exceed MaxMetaspaceSize. > > I uploaded webrev for this bug. Could you review it? > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ > > This change has passed all tests on submit repo, :vmTestbase_vm_metaspace, > and :vmTestbase_nsk_sysdict jtreg tests. > > > Thanks, > > Yasumasa > > > On 2019/01/15 18:30, Yasumasa Suenaga wrote: >> PING: Did you read my email? >> >> I wrote the problem and suggested fix in it. >> Please tell me if you have question(s). >> >> I can file it to JBS if it is a bug. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/01/10 18:02, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I'm Yasumasa Suenaga (OpenJDK reviewer: ysuenaga) >>> >>> My customer uses OpenJDK 8u131 with following commandline arguments: >>> >>> ?? -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 >>> ?? -XX:CompressedClassSpaceSize=128m -Xms4500m -Xmx4500m >>> ?? -XX:MaxMetaspaceSize=256m -Xmn=768m -XX:MaxTenuringThreshold=15 >>> ?? -XX:OnOutOfMemoryError="/bin/kill -ABRT %p" >>> ?? -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC >>> >>> Their system has encountered OutOfMemoryError which is caused by Metaspace. >>> >>> I checked core image which was collected by OnOutOfMemoryError, and I saw >>> strange values in it as below: >>> >>> ------------------- >>> (gdb) p Metaspace::_space_list->_reserved_words >>> $67 = 31195136 >>> (gdb) p Metaspace::_class_space_list->_reserved_words >>> $68 = 16777216 >>> (gdb) p MetaspaceGC::_capacity_until_GC >>> $75 = 448045056 >>> ------------------- >>> >>> MaxMetaspaceSize and CompressedClassSpaceSize seem to affect Metaspace. >>> However, MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize. >>> Is it correct? >>> >>> I checked used and committed memory from the core, they seem to be enough >>> to allocate new objects as below: >>> >>> ------------------- >>> (gdb) p MetaspaceAux::_used_words >>> $62 = {1742673, 17905981} >>> (gdb) p Metaspace::_space_list->_committed_words >>> $64 = 30932992 >>> (gdb) p Metaspace::_class_space_list->_committed_words >>> $65 = 2621440 >>> ------------------- >>> >>> I guess the cause of OOME is invalid value in _capacity_until_GC. >>> _capacity_until_GC is used for expanding / shrinking Metaspace. >>> However it is not checked when it changes. >>> >>> So I think we need to add the code to check it as below: >>> (The change is for jdk/jdk) >>> ------------------- >>> diff -r 32c6cc430526 src/hotspot/share/memory/metaspace.cpp >>> --- a/src/hotspot/share/memory/metaspace.cpp??? Wed Jan 09 22:59:49 2019 +0100 >>> +++ b/src/hotspot/share/memory/metaspace.cpp??? Thu Jan 10 17:56:55 2019 +0900 >>> @@ -143,6 +143,10 @@ >>> ????? new_value = align_down(max_uintx, Metaspace::commit_alignment()); >>> ??? } >>> >>> +? if (new_value > MaxMetaspaceSize) { >>> +??? return false; >>> +? } >>> + >>> ??? size_t prev_value = Atomic::cmpxchg(new_value, &_capacity_until_GC, old_capacity_until_GC); >>> >>> ??? if (old_capacity_until_GC != prev_value) { >>> ------------------- >>> >>> _capacity_until_GC is set to MaxMetaspaceSize at MetaspaceGC::initialize(), >>> and it set to committed size or MetaspaceSize at MetaspaceGC::post_initialize(). >>> So I guess max value of it is MaxMetaspaceSize. >>> >>> >>> What do you think? >>> If it is a bug, I will file JBS and send review request. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> From kim.barrett at oracle.com Fri Jan 25 04:51:54 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Jan 2019 23:51:54 -0500 Subject: RFR: 8216258: Make FreeIdSet semaphore-based In-Reply-To: <283db657-4e77-88d3-7865-bca46f7ad3fb@oracle.com> References: <877698F4-E491-4B62-A16E-71D465DD9909@oracle.com> <283db657-4e77-88d3-7865-bca46f7ad3fb@oracle.com> Message-ID: > On Jan 24, 2019, at 12:32 PM, sangheon.kim at oracle.com wrote: > > Hi Kim, > > On 1/8/19 5:25 PM, Kim Barrett wrote: >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8216258/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8216258/open.01.inc/ > Webrev.01 looks very nice. > Sorry for the late review. > > Thanks, > Sangheon Thanks. From leo.korinth at oracle.com Fri Jan 25 09:56:20 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 25 Jan 2019 10:56:20 +0100 Subject: RFR: 8214799: Add package declaration to each JTREG test case in the gc folder In-Reply-To: <4df492e6b70edc553e81dcfb664f240354917f56.camel@oracle.com> References: <19bae948-ec2b-257e-d0fc-69ff95093642@oracle.com> <3899785E-F88A-4F4B-8DE7-9002F7835AD3@oracle.com> <02b75e14-ed77-d3ba-765e-9c1a726d6e98@oracle.com> <9cfe2165-0f2f-53e9-8c61-474d5fa5deeb@oracle.com> <2A5A69F0-0995-4E95-8EA9-2F90A4BD5A37@oracle.com> <5acce3ca-6fd1-9024-1946-e4d866d97bbf@oracle.com> <4df492e6b70edc553e81dcfb664f240354917f56.camel@oracle.com> Message-ID: <7f8f4aec-2123-5f46-a895-5609e883515f@oracle.com> Thanks for your review! /Leo On 23/01/2019 10:51, Thomas Schatzl wrote: > Hi, > > On Thu, 2019-01-17 at 16:58 +0100, Leo Korinth wrote: >> Hi, >> >> I have added package name to newly added >> TestPeriodicLogMessages.java. >> >> I would be happy for a review from a reviewer (for the whole change, >> not >> only this test). >> >> The updated test case has been tested. > > Good change to decrease the threshold to improve these :) > > .02 changes and below diff look good. > > Thomas > >> >> /Leo >> >> >> diff --git a/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java >> b/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java >> index 2cede583c45..bd02a6e1c0a 100644 >> --- a/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java >> +++ b/test/hotspot/jtreg/gc/g1/TestPeriodicLogMessages.java >> @@ -21,6 +21,8 @@ >> * questions. >> */ >> >> +package gc.g1; >> + >> /** >> * @test TestPeriodicLogMessages >> * @bug 8216490 >> @@ -29,6 +31,7 @@ >> * @library /test/lib / >> * @modules java.base/jdk.internal.misc >> * @modules java.management/sun.management >> + * @run main gc.g1.TestPeriodicLogMessages >> */ >> >> import jdk.test.lib.process.OutputAnalyzer; >> > From thomas.schatzl at oracle.com Fri Jan 25 10:15:38 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 25 Jan 2019 11:15:38 +0100 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <1548253965.31327.2.camel@redhat.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> Message-ID: Hi, On Wed, 2019-01-23 at 09:32 -0500, zgu at redhat.com wrote: > Hi Thomas, > > Thanks for getting the review started. > > > initial comments: > > > > - taskqueue.hpp: I recommend adding an empty virtual destructor in > > any > > case. > > > > - owstTaskTerminator.cpp:69: s/returnning/returning/ > > > > Updated based on your comments: > > http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.01/index.html > > Thanks, > > -Zhengyu > > > I will think a bit more about the change while waiting for the test > > results. > > Testing showed good results, no issues. I would like to ask if I understood the changes correctly: to me it seems that some of these changes are the actual fix, others seem to be enhancements. So the changes in owstTaskTerminator.cpp:68-74 seem to be the actual fix for the issue - it needs to recheck _offered_termination within the lock at that point because of the mentioned race. There are additional improvements to both terminators (owstTaskTerminator.cpp:171-174, taskqueue.cpp:220-232) that may result in potential needless additional rounds of offer_termination(). I.e. before returning a result that indicates to the caller to continue doing work for another round, instead if in the meantime everyone has offered termination, we are obviously done too. If I am correct, I would strongly prefer if these changes (the enhancements) would be changed separately. Also, the code in taskqueue.cpp:220-232 is worth an extra method with a description indicating why we can return true in offer_termination in that case (because obviously, if all threads are sure to have offered termination, between the evaluation of the condition and trying to decrement the _offer_termination variable, work has been completed. As an additional enhancement, it might be worth doing padding of the ParallelTaskTerminator::_offered_termination variable. Thanks, Thomas From thomas.schatzl at oracle.com Fri Jan 25 10:49:07 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 25 Jan 2019 11:49:07 +0100 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: <6288740d1483e78e6bc3b8be6f1d3f52993611fb.camel@oracle.com> References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> <72D53764-202B-48FB-B77B-476C60A7027D@oracle.com> <6288740d1483e78e6bc3b8be6f1d3f52993611fb.camel@oracle.com> Message-ID: Hi again, On Thu, 2019-01-24 at 13:55 +0100, Thomas Schatzl wrote: > On Wed, 2019-01-23 at 23:07 -0500, Kim Barrett wrote: > > > > > [...] > > src/hotspot/share/gc/shared/weakProcessor.inline.hpp > > 51 bool result = _inner->do_object_b(obj); > > 52 _num_dead += !result; > > > > 57 size_t num_dead() const { return _num_dead; } > > > > This calculates the number of recently deceased, and does not > > include entries that were nulled out by some previous collection > > but not yet removed by the service thread. But the calculations > > based on: > > > > 89 StringTable::inc_dead_counter(cl.num_dead()); > > > > want the number of nulled out entries. > > > > I don't see a convenient way to obtain the number that should be > > passed to inc_dead_counter here, at least not while using > > weak_oops_do. What I think needs to be passed to inc_dead_counter > > is the number of previously nulled entries + the number of newly > > dead entries. Using oops_do rather than weak_oops_do would allow > > getting the missing number. > > > > The serial WeakProcessor has the same problem. > > > > We talked about this offline last week, and I think we got it > > wrong. I was working with what I remembered of that part of the > > StringTable API, and it looks like my memory was faulty. Sorry > > about that. > > From what I understand this is actually an existing bug - the old > code (in StringTable) also directly set > StringTable::_uncleaned_items_count as returned by the count of the > IsAliveClosure in weak_oops_do(). > > I would prefer fixing this separately as I believe the exact way to > do this best will be another discussion. I can file a CR for that. While looking into this as part of JDK-8217778 I found that I forgot to remove the now unused StringTableIsAliveCounter class. Removed that as well and regenerated the webrevs at: > > New webrevs at: > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2_to_3/ (diff) > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.3/ (full) > Testing: > locally running gc/g1, started hs-tier1-5 > hs-tier1-5 passed w/o issues in the meantime. Thanks, Thomas From thomas.schatzl at oracle.com Fri Jan 25 13:31:49 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 25 Jan 2019 14:31:49 +0100 Subject: RFR: 8217332: JTREG: Clean up, use generics instead of raw types In-Reply-To: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> References: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> Message-ID: <20225d4cdb3b8cc49ae1f6fa377429f8a5bd4820.camel@oracle.com> Hi, On Fri, 2019-01-18 at 10:11 +0100, Leo Korinth wrote: > Hi, > > This webrev fixes lack of generics usage in the jtreg/gc folder. > > This fix is somewhat based/dependent on "8214799: Add package > declaration to each JTREG test case in the gc folder". That fix is > out > for review. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8217332 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8217332/00 > > Testing: > passed locally: open/test/hotspot/jtreg/:hotspot_gc > I assume this is, as some other reviews in this series, to remove some warnings in some code analysis tool. Fine with me to fix such problems in our jtreg code: so ship it. Thanks, Thomas From nils.eliasson at oracle.com Fri Jan 25 13:26:13 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 25 Jan 2019 14:26:13 +0100 Subject: RFR: 8217717: ZGC: Broken oop map in C1 load barrier stub In-Reply-To: <855f6ad9-f400-889d-86bb-be816f1a7cb3@oracle.com> References: <855f6ad9-f400-889d-86bb-be816f1a7cb3@oracle.com> Message-ID: <51c9a059-3abb-33cd-2af3-c3cd04aaccfe@oracle.com> Hi Per, Looks great! Regards, Nils On 2019-01-24 13:29, Per Liden wrote: > On 1/24/19 12:05 PM, Per Liden wrote: >> The C1 load barrier stub for ZGC can emit a patching area for a lea >> instruction. However, the call into the VM to do the patching at this >> site is not associated with a proper oop map. As a result, we can end >> up with a stable oop in the base pointer register if a GC safepoint >> happens > > s/stable/stale/ ;) > >> when we enter the VM to patch. >> >> This problem is not super easy to reproduce by default, but is a >> serious bug when it happens. However, it is fairly easy to reproduce >> when also injecting a small delay in the >> ZNMethodTable::register_nmethod(). >> >> The proposed solution is to never allow patching to happen inside the >> load barrier stub. Instead, if patching is needed, we emit the lea >> instruction as part of the load preceding the load barrier. That will >> automatically generate the proper oop map for the patch site. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217717 >> Webrev: http://cr.openjdk.java.net/~pliden/8217717/webrev.0 >> >> Testing: Manual testing and inspection of generated code. Passes >> gc-test-suite. Currently running tier1-3 on all platforms, and >> tier1-7 on Linux/x86. >> >> /Per From thomas.schatzl at oracle.com Fri Jan 25 14:11:23 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 25 Jan 2019 15:11:23 +0100 Subject: RFR (L): 8217330: Split CollectionSetChooser into collection set candidate container and the chooser algorithm In-Reply-To: <49d3c2a3-ee8d-f715-eb6d-833843c0b0f7@oracle.com> References: <49d3c2a3-ee8d-f715-eb6d-833843c0b0f7@oracle.com> Message-ID: Hi Leo, On Thu, 2019-01-24 at 19:04 +0100, Leo Korinth wrote: > Hi Thomas. > > I think this looks really good, thanks for cleaning this up. Keep in > mind my lack of experience. > > Minor nits: you need to update copyright years. There is an extra > (unnecessary) line "bool this_pause_was_last_before_mixed = > collector_state()->in_young_gc_before_mixed();" that can be removed. thanks for your review. All fixed in http://cr.openjdk.java.net/~tschatzl/8217330/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8217330/webrev.1 (full) Thanks, Thomas From per.liden at oracle.com Fri Jan 25 14:14:48 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 25 Jan 2019 15:14:48 +0100 Subject: RFR: 8217717: ZGC: Broken oop map in C1 load barrier stub In-Reply-To: <51c9a059-3abb-33cd-2af3-c3cd04aaccfe@oracle.com> References: <855f6ad9-f400-889d-86bb-be816f1a7cb3@oracle.com> <51c9a059-3abb-33cd-2af3-c3cd04aaccfe@oracle.com> Message-ID: Thanks for reviewing, Nils! /Per On 1/25/19 2:26 PM, Nils Eliasson wrote: > Hi Per, > > Looks great! > > Regards, > > Nils > > On 2019-01-24 13:29, Per Liden wrote: >> On 1/24/19 12:05 PM, Per Liden wrote: >>> The C1 load barrier stub for ZGC can emit a patching area for a lea >>> instruction. However, the call into the VM to do the patching at this >>> site is not associated with a proper oop map. As a result, we can end >>> up with a stable oop in the base pointer register if a GC safepoint >>> happens >> >> s/stable/stale/ ;) >> >>> when we enter the VM to patch. >>> >>> This problem is not super easy to reproduce by default, but is a >>> serious bug when it happens. However, it is fairly easy to reproduce >>> when also injecting a small delay in the >>> ZNMethodTable::register_nmethod(). >>> >>> The proposed solution is to never allow patching to happen inside the >>> load barrier stub. Instead, if patching is needed, we emit the lea >>> instruction as part of the load preceding the load barrier. That will >>> automatically generate the proper oop map for the patch site. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217717 >>> Webrev: http://cr.openjdk.java.net/~pliden/8217717/webrev.0 >>> >>> Testing: Manual testing and inspection of generated code. Passes >>> gc-test-suite. Currently running tier1-3 on all platforms, and >>> tier1-7 on Linux/x86. >>> >>> /Per From leo.korinth at oracle.com Fri Jan 25 14:28:01 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 25 Jan 2019 15:28:01 +0100 Subject: RFR: 8217332: JTREG: Clean up, use generics instead of raw types In-Reply-To: <20225d4cdb3b8cc49ae1f6fa377429f8a5bd4820.camel@oracle.com> References: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> <20225d4cdb3b8cc49ae1f6fa377429f8a5bd4820.camel@oracle.com> Message-ID: On 25/01/2019 14:31, Thomas Schatzl wrote: > Hi, > > On Fri, 2019-01-18 at 10:11 +0100, Leo Korinth wrote: >> Hi, >> >> This webrev fixes lack of generics usage in the jtreg/gc folder. >> >> This fix is somewhat based/dependent on "8214799: Add package >> declaration to each JTREG test case in the gc folder". That fix is >> out >> for review. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8217332 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8217332/00 >> >> Testing: >> passed locally: open/test/hotspot/jtreg/:hotspot_gc >> > > I assume this is, as some other reviews in this series, to remove > some warnings in some code analysis tool. Fine with me to fix such > problems in our jtreg code: so ship it. Yes, I am trying to remove all warnings from our GC test cases. I am using Eclipse but many of the warnings also effect javac, and my hope is that this will remove javac lint warnings in our test logs as well as actually help us find out when we write bad code. Thanks for the review Thomas. /Leo > > Thanks, > Thomas > From shade at redhat.com Fri Jan 25 14:49:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 25 Jan 2019 15:49:14 +0100 Subject: RFR (XS) 8217471: [TESTBUG] gc/epsilon/TestClasses.java fails on some platforms - OOME Metaspace In-Reply-To: <8efd136ab8ec38b9bd94bad9a06d31899b587992.camel@oracle.com> References: <21def557-2d46-9ddd-a34c-2a7f336f30f6@redhat.com> <8efd136ab8ec38b9bd94bad9a06d31899b587992.camel@oracle.com> Message-ID: On 1/24/19 4:45 PM, Thomas Schatzl wrote: > On Thu, 2019-01-24 at 12:44 +0100, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8217471 >> >> Newly added test limits max metaspace size to 32M and then allocates >> lots of classes. Turns out, some machines just barely do not fit that >> limit. Many thanks to David Holmes for testing the change on the >> offending Solaris box. I also used the more aggressive options >> on x86_64 (e.g. -Xcomp lines provided by Mikael) to reproduce and >> test it locally. It seems the next step, 64M fits broken >> configurations well. >> >> Fix: > > change looks good. Thanks, I am going to push it soon with one review then. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Fri Jan 25 16:59:13 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 25 Jan 2019 11:59:13 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> Message-ID: <1548435553.31327.38.camel@redhat.com> Hi, > > > I will think a bit more about the change while waiting for the > > > test > > > results. > > > > > Testing showed good results, no issues. Thanks! > > I would like to ask if I understood the changes correctly: to me it > seems that some of these changes are the actual fix, others seem to > be > enhancements. > > So the changes in owstTaskTerminator.cpp:68-74 seem to be the actual > fix for the issue - it needs to recheck _offered_termination within > the > lock at that point because of the mentioned race. I would say that this is actually an enhancement. Without it, merely delays the termination of this particular thread. Filed RFE: https://bugs.openjdk.java.net/browse/JDK-8217794 > > There are additional improvements to both terminators > (owstTaskTerminator.cpp:171-174, taskqueue.cpp:220-232) that may > result > in potential needless additional rounds of offer_termination(). > I.e. before returning a result that indicates to the caller to > continue > doing work for another round, instead if in the meantime everyone has > offered termination, we are obviously done too. > > If I am correct, I would strongly prefer if these changes (the > enhancements) would be changed separately. > > Also, the code in taskqueue.cpp:220-232 is worth an extra method with > a > description indicating why we can return true in offer_termination in > that case (because obviously, if all threads are sure to have offered > termination, between the evaluation of the condition and trying to > decrement the _offer_termination variable, work has been completed. Okay. But I want to point out that it is not necessary a race, because TerminatorTerminator may decide to request an abort based on external conditions, which may have nothing to do with the progress of the termination. Updated Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.02/i ndex.html Passed hotspot_gc test, will rerun all other tests. > As an additional enhancement, it might be worth doing padding of the > ParallelTaskTerminator::_offered_termination variable. > I filed a separate RFE: https://bugs.openjdk.java.net/browse/JDK-821778 5 -Zhengyu > Thanks, > Thomas > > From rkennke at redhat.com Sat Jan 26 00:23:54 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 26 Jan 2019 01:23:54 +0100 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: <87bm4676j4.fsf@redhat.com> References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> <87bm4676j4.fsf@redhat.com> Message-ID: <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> > http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.00/ > > That looks good to me. But don't you need a similar change for aarch64? Right. This update implements the same thing in aarch64: http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.01/ It causes no regressions in hotspot_gc_shenandoah (we have a few failures, but none of them are related to the patch and are pre-existing). Good? Thanks, Roman From zgu at redhat.com Sat Jan 26 02:44:06 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 25 Jan 2019 21:44:06 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <1548435553.31327.38.camel@redhat.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> <1548435553.31327.38.camel@redhat.com> Message-ID: <1548470646.31327.40.camel@redhat.com> > Updated Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.02 > /i > ndex.html > > Passed hotspot_gc test, will rerun all other tests. Passed hotspot_gc and vmTestbase_vm_gc on Linux x64 (fastdebug and release), also submit tests. Thanks, -Zhengyu > > > As an additional enhancement, it might be worth doing padding of > > the > > ParallelTaskTerminator::_offered_termination variable. > > > > I filed a separate RFE: https://bugs.openjdk.java.net/browse/JDK-8217 > 78 > 5 > > > -Zhengyu > > > > Thanks, > > Thomas > > > > From sangheon.kim at oracle.com Sat Jan 26 15:35:49 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Sat, 26 Jan 2019 07:35:49 -0800 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers Message-ID: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> Hi all, Can I have reviews that excludes gc/nvdimm jtreg tests? Those tests were introduced by? JDK-8202286 (Allocation of old generation of Java heap on alternate memory devices) and tried to exclude all tests from all tiers. But it was incomplete so one of the tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java failure) was filed recently. The patch includes to exclude gc/nvdimm from TEST.groups, hotspot_misc group(which is the reason why JDK-8217406 occurred). In addition, added @requires to gc/nvdimm tests to avoid running the tests. CR: https://bugs.openjdk.java.net/browse/JDK-8217666 webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. Thanks, Sangheon From manc at google.com Sun Jan 27 00:35:35 2019 From: manc at google.com (Man Cao) Date: Sat, 26 Jan 2019 16:35:35 -0800 Subject: RFR (M): 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC overhead In-Reply-To: References: <6b1e59ec7f4746e8e071fd44ec91ca966fac8d78.camel@oracle.com> <7e0c775d-86c1-b80c-b1a6-373ca21206ba@oracle.com> Message-ID: Friendly ping. Could anyone give a second "looks good"? As for the develop flag AdaptiveSizePolicyGCTimeLimitThreshold/GCOverheadLimitThreshold, I added a note about it in https://bugs.openjdk.java.net/browse/JDK-8212084. -Man On Tue, Jan 15, 2019 at 6:41 PM Man Cao wrote: > Hi, > > I rebased the patch to tip and updated year in some headers to 2019, > without making any real change: > http://cr.openjdk.java.net/~manc/8212206/webrev.02/ > > > I don't foresee that this will be implemented, or even makes sense, for >> ZGC. As I see it, this is only a thing STW collectors. For that reason, >> I don't think it belongs in CollectedHeap. Keeping it as a separate >> utility class for collectors that want to use it sounds better. >> > Sounds good to keep this patch in the current state, without further > changing the CollectedHeap class. > > I haven't looked very closely at the patch, but couldn't help to notice >> that the option is called "GCOverheapLimitThreshold" (and >> "AdaptiveSizePolicyGCTimeLimitThreshold" before that), which is a >> tautology and a not very good description of what it is. >> How about we take the opportunity to clean this up and completely ditch >> the "gc_overhead_limit_count" thing and get rid of this option? It's a >> "develop" option, so it's not available to normal users anyway. Has >> anyone of you ever used this option and actually find it valuable? > > I didn't find any users inside Google that require changing this option. > That said, some users did complain that UseGCOverheadLimit for ParallelGC > or CMS is too difficult to get > triggered, because of the requirement for 5 consecutive full GCs, which is > set by this option. > I think if it were a normal "product" option, there will definitely be > users setting it. > I never understand why it is a "develop" option. I think we could either > remove it, > or make it an "experimental" option. > I'm leaning towards not removing it for now, as I'm not sure if 5 is still > a reasonable > default value for UseGCOverheadLimit for G1. > How about we decide whether to keep or remove this option after > JDK-8212084 (UseGCOverheadLimit for G1) is fixed? > > Also for the hsperfdata counter change, I created > https://bugs.openjdk.java.net/browse/JDK-8217221. I will draft a CSR for > it later. > > -Man > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Mon Jan 28 07:53:47 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 28 Jan 2019 08:53:47 +0100 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> <87bm4676j4.fsf@redhat.com> <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> Message-ID: <87womp2p6c.fsf@redhat.com> > http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.01/ Looks good to me. Roland. From rkennke at redhat.com Mon Jan 28 08:07:36 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 28 Jan 2019 09:07:36 +0100 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: <87womp2p6c.fsf@redhat.com> References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> <87bm4676j4.fsf@redhat.com> <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> <87womp2p6c.fsf@redhat.com> Message-ID: >> http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.01/ > > Looks good to me. Thank you, Roland, for reviewing! Roman From per.liden at oracle.com Mon Jan 28 08:54:33 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 09:54:33 +0100 Subject: RFR: 8217745: ZGC: Simplify ZLoadBarrierStubC1 Message-ID: We can simplify ZLoadBarrierStubC1 a little bit since we know that _ref_addr is always a LIR_Address and never a Register. In the ZLoadBarrierStubC1 constructor we can just assert that this is always true. Later, when emitting code, we can just use the presence of the tmp register as indicator that we need to load the effective address. Bug: https://bugs.openjdk.java.net/browse/JDK-8217745 Webrev: http://cr.openjdk.java.net/~pliden/8217745/webrev.0 /Per From per.liden at oracle.com Mon Jan 28 08:56:22 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 09:56:22 +0100 Subject: RFR: 8217747: ZGC: Minor optimization of ZLoadBarrierStubC1 Message-ID: In the C1 load barrier stub for ZGC we currently save/restore rax unless it's the stub result register. However, we can also avoid this save/restore of rax if it's the tmp register. Avoiding a push/pop in the stub isn't really an important optimization, but since we already do it for the result register we can just as well do it for the tmp register too, without making the code more complex. Bug: https://bugs.openjdk.java.net/browse/JDK-8217747 Webrev: http://cr.openjdk.java.net/~pliden/8217747/webrev.0 /Per From per.liden at oracle.com Mon Jan 28 08:59:30 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 09:59:30 +0100 Subject: RFR: 8217855: ZGC: Clean up ZReferenceProcessor Message-ID: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> Various structural and naming cleanups in ZReferenceProcessor. Bug: https://bugs.openjdk.java.net/browse/JDK-8217855 Webrev: http://cr.openjdk.java.net/~pliden/8217855/webrev.0 /Per From per.liden at oracle.com Mon Jan 28 09:00:26 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 10:00:26 +0100 Subject: RFR: 8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer Message-ID: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> Move instanciation of SvcGCMarker to ZServiceabilityTracer, where it belongs. Bug: https://bugs.openjdk.java.net/browse/JDK-8217857 Webrev: http://cr.openjdk.java.net/~pliden/8217857/webrev.0 /Per From per.liden at oracle.com Mon Jan 28 09:01:30 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 10:01:30 +0100 Subject: RFR: 8217858: ZGC: Clean up ZDriver Message-ID: Various structural and naming cleanups in ZDriver. Most notably, the ZOperationClosure types were replaced by true VM operation types. Bug: https://bugs.openjdk.java.net/browse/JDK-8217858 Webrev: http://cr.openjdk.java.net/~pliden/8217858/webrev.0 /Per From per.liden at oracle.com Mon Jan 28 09:04:49 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 10:04:49 +0100 Subject: RFR: 8217856: ZGC: Break out C2 matching rules into separate AD file Message-ID: <1b6c2fd2-d273-31d5-8cdd-5ba4f8f408d0@oracle.com> Break out ZGC specific C2 matching rules into separate AD file. This patch also introduces the z_load_barrier_slow_reg() function to avoid some code duplication. Bug: https://bugs.openjdk.java.net/browse/JDK-8217856 Webrev: http://cr.openjdk.java.net/~pliden/8217856/webrev.0 /Per From stefan.karlsson at oracle.com Mon Jan 28 09:17:16 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 28 Jan 2019 10:17:16 +0100 Subject: RFR: 8217855: ZGC: Clean up ZReferenceProcessor In-Reply-To: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> References: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> Message-ID: Looks good. StefanK On 2019-01-28 09:59, Per Liden wrote: > Various structural and naming cleanups in ZReferenceProcessor. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217855 > Webrev: http://cr.openjdk.java.net/~pliden/8217855/webrev.0 > > /Per From stefan.karlsson at oracle.com Mon Jan 28 09:18:26 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 28 Jan 2019 10:18:26 +0100 Subject: RFR: 8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer In-Reply-To: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> References: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> Message-ID: <0b2c853c-c2c6-159e-56c5-24def296f359@oracle.com> Looks good. StefanK On 2019-01-28 10:00, Per Liden wrote: > Move instanciation of SvcGCMarker to ZServiceabilityTracer, where it > belongs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217857 > Webrev: http://cr.openjdk.java.net/~pliden/8217857/webrev.0 > > /Per From stefan.karlsson at oracle.com Mon Jan 28 09:24:43 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 28 Jan 2019 10:24:43 +0100 Subject: RFR: 8217858: ZGC: Clean up ZDriver In-Reply-To: References: Message-ID: <5abd69e4-f6bb-00f2-bf81-3147d46117d5@oracle.com> Looks good. StefanK On 2019-01-28 10:01, Per Liden wrote: > Various structural and naming cleanups in ZDriver. Most notably, the > ZOperationClosure types were replaced by true VM operation types. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217858 > Webrev: http://cr.openjdk.java.net/~pliden/8217858/webrev.0 > > /Per From aph at redhat.com Mon Jan 28 09:30:33 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Jan 2019 09:30:33 +0000 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> <87bm4676j4.fsf@redhat.com> <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> Message-ID: <7020457a-7fd5-c4f4-f8cc-8fc47114bfce@redhat.com> On 1/26/19 12:23 AM, Roman Kennke wrote: > Right. This update implements the same thing in aarch64: > > http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.01/ > > It causes no regressions in hotspot_gc_shenandoah (we have a few > failures, but none of them are related to the patch and are pre-existing). > > Good? I can't make any sense of the code. It looks like we're disabling the generation of CAS instructions in ShenandoahBarrierSetAssembler::cmpxchg_oop. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nils.eliasson at oracle.com Mon Jan 28 09:26:54 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 28 Jan 2019 10:26:54 +0100 Subject: RFR: 8217856: ZGC: Break out C2 matching rules into separate AD file In-Reply-To: <1b6c2fd2-d273-31d5-8cdd-5ba4f8f408d0@oracle.com> References: <1b6c2fd2-d273-31d5-8cdd-5ba4f8f408d0@oracle.com> Message-ID: Hi Per, Looks good! // Nils On 2019-01-28 10:04, Per Liden wrote: > Break out ZGC specific C2 matching rules into separate AD file. This > patch also introduces the z_load_barrier_slow_reg() function to avoid > some code duplication. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217856 > Webrev: http://cr.openjdk.java.net/~pliden/8217856/webrev.0 > > /Per From nils.eliasson at oracle.com Mon Jan 28 09:29:31 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 28 Jan 2019 10:29:31 +0100 Subject: RFR: 8217745: ZGC: Simplify ZLoadBarrierStubC1 In-Reply-To: References: Message-ID: Looks good, // Nils On 2019-01-28 09:54, Per Liden wrote: > We can simplify ZLoadBarrierStubC1 a little bit since we know that > _ref_addr is always a LIR_Address and never a Register. In the > ZLoadBarrierStubC1 constructor we can just assert that this is always > true. Later, when emitting code, we can just use the presence of the > tmp register as indicator that we need to load the effective address. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217745 > Webrev: http://cr.openjdk.java.net/~pliden/8217745/webrev.0 > > /Per From nils.eliasson at oracle.com Mon Jan 28 09:27:49 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 28 Jan 2019 10:27:49 +0100 Subject: RFR: 8217747: ZGC: Minor optimization of ZLoadBarrierStubC1 In-Reply-To: References: Message-ID: <83894b08-1eaf-cec6-549c-a2ab76391781@oracle.com> Looks good, // Nils On 2019-01-28 09:56, Per Liden wrote: > In the C1 load barrier stub for ZGC we currently save/restore rax > unless it's the stub result register. However, we can also avoid this > save/restore of rax if it's the tmp register. Avoiding a push/pop in > the stub isn't really an important optimization, but since we already > do it for the result register we can just as well do it for the tmp > register too, without making the code more complex. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217747 > Webrev: http://cr.openjdk.java.net/~pliden/8217747/webrev.0 > > /Per From rkennke at redhat.com Mon Jan 28 09:38:15 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 28 Jan 2019 10:38:15 +0100 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: <7020457a-7fd5-c4f4-f8cc-8fc47114bfce@redhat.com> References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> <87bm4676j4.fsf@redhat.com> <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> <7020457a-7fd5-c4f4-f8cc-8fc47114bfce@redhat.com> Message-ID: >> Right. This update implements the same thing in aarch64: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.01/ >> >> It causes no regressions in hotspot_gc_shenandoah (we have a few >> failures, but none of them are related to the patch and are pre-existing). >> >> Good? > > I can't make any sense of the code. It looks like we're disabling the generation > of CAS instructions in ShenandoahBarrierSetAssembler::cmpxchg_oop. Why? Because of removal of this block: - if (!ShenandoahCASBarrier) { ... - } ? This block has only been there because we haven't been strict on generating the Shenandoah-CAS only with +ShenandoahCASBarrier. This has been fixed, and we should never actually get there when -ShenandoahCASBarrier. The rest of the patch is refactoring the code such that all C1-specific code is only done in shenandoahBarrierSetC1_aarch64.cpp. The C1-specific paths have previously been under 'if (encode) {.. }' paths, which was completely un-obvious unless you knew it. Another change is that cset that follows the compare-and-swap-path is now consistently generated at the end of cmpxchg_oop(). Before that, C1 would first generate a compare-and-exchange (?!) and then put a cmove() in LIR behind it, which assumes correct flags out of cmpxchg_oop() assembly, which is kindof odd. Does that make more sense? Roman From aph at redhat.com Mon Jan 28 10:02:35 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Jan 2019 10:02:35 +0000 Subject: RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers In-Reply-To: References: <418ae27e-dd78-9932-7488-06a4af82df9c@redhat.com> <87bm4676j4.fsf@redhat.com> <7087e4cc-acd5-4a27-b4fb-2b6db911da75@redhat.com> <7020457a-7fd5-c4f4-f8cc-8fc47114bfce@redhat.com> Message-ID: <1fbdd871-541c-2321-465a-7e17ae8ce90f@redhat.com> On 1/28/19 9:38 AM, Roman Kennke wrote: > This block has only been there because we haven't been strict on > generating the Shenandoah-CAS only with +ShenandoahCASBarrier. This has > been fixed, and we should never actually get there when > -ShenandoahCASBarrier. >> The rest of the patch is refactoring the code such that all C1-specific > code is only done in shenandoahBarrierSetC1_aarch64.cpp. The C1-specific > paths have previously been under 'if (encode) {.. }' paths, which was > completely un-obvious unless you knew it. > > Another change is that cset that follows the compare-and-swap-path is > now consistently generated at the end of cmpxchg_oop(). Before that, C1 > would first generate a compare-and-exchange (?!) and then put a cmove() > in LIR behind it, which assumes correct flags out of cmpxchg_oop() > assembly, which is kindof odd. > > Does that make more sense? OK. It's a bit odd to see explicit use of load/store exclusive in the Shenandoah code, but that isn't something your patch changes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From per.liden at oracle.com Mon Jan 28 10:25:55 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 11:25:55 +0100 Subject: RFR: 8217745: ZGC: Simplify ZLoadBarrierStubC1 In-Reply-To: References: Message-ID: <6590b304-740b-5dd0-1650-b539e01f82bf@oracle.com> Thanks Nils! /Per On 01/28/2019 10:29 AM, Nils Eliasson wrote: > Looks good, > > // Nils > > On 2019-01-28 09:54, Per Liden wrote: >> We can simplify ZLoadBarrierStubC1 a little bit since we know that >> _ref_addr is always a LIR_Address and never a Register. In the >> ZLoadBarrierStubC1 constructor we can just assert that this is always >> true. Later, when emitting code, we can just use the presence of the >> tmp register as indicator that we need to load the effective address. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217745 >> Webrev: http://cr.openjdk.java.net/~pliden/8217745/webrev.0 >> >> /Per From leo.korinth at oracle.com Mon Jan 28 10:25:52 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 28 Jan 2019 11:25:52 +0100 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> Message-ID: <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> Hi Sangheon, a few questions on the webrev: 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? 2) most of the *Enabled() functions in VMProps.java read properties, but here we read the environment, why is that? 3) maybe the property should be "vm.gc" prefixed instead of "vm" prefixed, maybe not. What do you think? Thanks for disabling these test cases! /Leo On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: > Hi all, > > Can I have reviews that excludes gc/nvdimm jtreg tests? > > Those tests were introduced by? JDK-8202286 (Allocation of old > generation of Java heap on alternate memory devices) and tried to > exclude all tests from all tiers. But it was incomplete so one of the > tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java > failure) was filed recently. > > The patch includes to exclude gc/nvdimm from TEST.groups, hotspot_misc > group(which is the reason why JDK-8217406 occurred). In addition, added > @requires to gc/nvdimm tests to avoid running the tests. > > CR: https://bugs.openjdk.java.net/browse/JDK-8217666 > webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ > Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. > > Thanks, > Sangheon From per.liden at oracle.com Mon Jan 28 10:26:05 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 11:26:05 +0100 Subject: RFR: 8217747: ZGC: Minor optimization of ZLoadBarrierStubC1 In-Reply-To: <83894b08-1eaf-cec6-549c-a2ab76391781@oracle.com> References: <83894b08-1eaf-cec6-549c-a2ab76391781@oracle.com> Message-ID: Thanks Nils! /Per On 01/28/2019 10:27 AM, Nils Eliasson wrote: > Looks good, > > // Nils > > On 2019-01-28 09:56, Per Liden wrote: >> In the C1 load barrier stub for ZGC we currently save/restore rax >> unless it's the stub result register. However, we can also avoid this >> save/restore of rax if it's the tmp register. Avoiding a push/pop in >> the stub isn't really an important optimization, but since we already >> do it for the result register we can just as well do it for the tmp >> register too, without making the code more complex. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217747 >> Webrev: http://cr.openjdk.java.net/~pliden/8217747/webrev.0 >> >> /Per From per.liden at oracle.com Mon Jan 28 10:26:12 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 11:26:12 +0100 Subject: RFR: 8217856: ZGC: Break out C2 matching rules into separate AD file In-Reply-To: References: <1b6c2fd2-d273-31d5-8cdd-5ba4f8f408d0@oracle.com> Message-ID: <6a67de22-b832-88c2-c63a-654a32b16adc@oracle.com> Thanks Nils! /Per On 01/28/2019 10:26 AM, Nils Eliasson wrote: > Hi Per, > > Looks good! > > // Nils > > On 2019-01-28 10:04, Per Liden wrote: >> Break out ZGC specific C2 matching rules into separate AD file. This >> patch also introduces the z_load_barrier_slow_reg() function to avoid >> some code duplication. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217856 >> Webrev: http://cr.openjdk.java.net/~pliden/8217856/webrev.0 >> >> /Per From per.liden at oracle.com Mon Jan 28 10:26:25 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 11:26:25 +0100 Subject: RFR: 8217858: ZGC: Clean up ZDriver In-Reply-To: <5abd69e4-f6bb-00f2-bf81-3147d46117d5@oracle.com> References: <5abd69e4-f6bb-00f2-bf81-3147d46117d5@oracle.com> Message-ID: <79d93c2d-845b-4290-21ec-6de66fd586a1@oracle.com> Thanks Stefan! /Per On 01/28/2019 10:24 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-01-28 10:01, Per Liden wrote: >> Various structural and naming cleanups in ZDriver. Most notably, the >> ZOperationClosure types were replaced by true VM operation types. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217858 >> Webrev: http://cr.openjdk.java.net/~pliden/8217858/webrev.0 >> >> /Per > From per.liden at oracle.com Mon Jan 28 10:26:30 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 11:26:30 +0100 Subject: RFR: 8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer In-Reply-To: <0b2c853c-c2c6-159e-56c5-24def296f359@oracle.com> References: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> <0b2c853c-c2c6-159e-56c5-24def296f359@oracle.com> Message-ID: Thanks Stefan! /Per On 01/28/2019 10:18 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-01-28 10:00, Per Liden wrote: >> Move instanciation of SvcGCMarker to ZServiceabilityTracer, where it >> belongs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217857 >> Webrev: http://cr.openjdk.java.net/~pliden/8217857/webrev.0 >> >> /Per > From per.liden at oracle.com Mon Jan 28 10:26:45 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 11:26:45 +0100 Subject: RFR: 8217855: ZGC: Clean up ZReferenceProcessor In-Reply-To: References: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> Message-ID: <0cc7ef65-7d3c-a8ce-9713-6cb25acddd3a@oracle.com> Thanks Stefan! /Per On 01/28/2019 10:17 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-01-28 09:59, Per Liden wrote: >> Various structural and naming cleanups in ZReferenceProcessor. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217855 >> Webrev: http://cr.openjdk.java.net/~pliden/8217855/webrev.0 >> >> /Per > From thomas.schatzl at oracle.com Mon Jan 28 10:36:43 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Jan 2019 11:36:43 +0100 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <1548470646.31327.40.camel@redhat.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> <1548435553.31327.38.camel@redhat.com> <1548470646.31327.40.camel@redhat.com> Message-ID: <1c3c9b13300d13c590027e7e75edb1b3f5ce7e19.camel@oracle.com> Hi, On Fri, 2019-01-25 at 21:44 -0500, zgu at redhat.com wrote: > > Updated Webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.02 > > /i > > ndex.html > > > > Passed hotspot_gc test, will rerun all other tests. > > Passed hotspot_gc and vmTestbase_vm_gc on Linux x64 (fastdebug and > release), also submit tests. > refactoring looks good. Thomas From thomas.schatzl at oracle.com Mon Jan 28 11:43:54 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Jan 2019 12:43:54 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects Message-ID: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> Hi all, can I have reviews for this change that tries to fix the issue with the string table reporting too low "dead" numbers to the ServiceThread notification mechanism in the review for JDK-8213229, potentially causing C heap memory being kept live for longer than necessary? This change implements one option for fixing this, in particular that the WeakProcessor calls OopStorage::oops_do() instead of ::weak_oops_do, counting the number of NULL entries manually. There is another, let weak_oops_do() return the number of NULL entries as function return value. However the return value of the used iterate_safepoint() is already in use in some I'd consider interesting test case. I did not want to add another out-parameter either. Since the WeakProcessor has been the main user of the weak_oops_do() method, I would suggest to clean this up preferably in an extra CR: there is still one use of the OopStorage::weak_oops_do() method that could be easily removed. If you think we should not remove it, I strongly suggest to rename the weak_oops_do() methods to better indicate what they actually do instead of giving a very strong (wrong) suggestion where/when they should be used. CR: https://bugs.openjdk.java.net/browse/JDK-8217778 Webrev: http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ Testing: hs-tier1-5 Thanks, Thomas From thomas.schatzl at oracle.com Mon Jan 28 11:45:58 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Jan 2019 12:45:58 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> Message-ID: <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> Hi again, cc'ed hotspot-runtime-dev since it concerns the string table. Also, this patch is based on the changes for JDK-8213229. Thanks, Thomas On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that tries to fix the issue with > the string table reporting too low "dead" numbers to the > ServiceThread notification mechanism in the review for JDK-8213229, > potentially causing C heap memory being kept live for longer than > necessary? > > This change implements one option for fixing this, in particular that > the WeakProcessor calls OopStorage::oops_do() instead of > ::weak_oops_do, counting the number of NULL entries manually. > > There is another, let weak_oops_do() return the number of NULL > entries as function return value. However the return value of the > used iterate_safepoint() is already in use in some I'd consider > interesting test case. I did not want to add another out-parameter > either. > > Since the WeakProcessor has been the main user of the weak_oops_do() > method, I would suggest to clean this up preferably in an extra CR: > there is still one use of the OopStorage::weak_oops_do() method that > could be easily removed. If you think we should not remove it, I > strongly suggest to rename the weak_oops_do() methods to better > indicate what they actually do instead of giving a very strong > (wrong) suggestion where/when they should be used. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217778 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ > Testing: > hs-tier1-5 > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Jan 28 13:55:08 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Jan 2019 14:55:08 +0100 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> Message-ID: <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> Hi Yasumasa, On Fri, 2019-01-25 at 11:35 +0900, Yasumasa Suenaga wrote: > PING: Could you review this? > > > Yasumasa > > > On 2019/01/21 17:52, Yasumasa Suenaga wrote: > > Hi all, > > > > I filed this issue to JBS: > > https://bugs.openjdk.java.net/browse/JDK-8217432 > > > > I investigated it, and I found that `minimum_desired_capacity` and > > `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()` > > might exceed MaxMetaspaceSize. > > They shouldn't exceed MaxMetaspaceSize. > > > > I uploaded webrev for this bug. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ > > > > This change has passed all tests on submit repo, > > :vmTestbase_vm_metaspace, > > and :vmTestbase_nsk_sysdict jtreg tests. The suggested change does not work - you can't return false from MetaspaceGC::inc_capacity_until_gc() because the return value indicates whether it was possible to change the value, not whether the value passed sense. The code before that must make sure that the resulting value is within limits (that could be a good assert in inc_capacity_until_GC()) from my understanding, without being an expert here. So with the current change, the assert in metaspace.cpp:260 would simply fire in this case. Making sure that the HWM does not go over MaxMetaspaceSize could be achieved by limiting expand_bytes passed to the method; I *think*, without following where minimum_desired_capacity is also used in that method, clamping it via 241: minimum_desired_capacity = MIN2(MAX2(minimum_desired_capacity, MetaspaceSize), MaxMetaspaceSize); would achieve the desired effect. Could you also provide a test case for this change (i.e. failing before, good after) as Aleksey suggested? Note that my suggestion only fixes the call to inc_capacity_until_gc() in MetaspaceGC::compute_new_size(). I very much believe it is required to add another guard in ClassLoaderMetaspace::expand_and_allocate(). (Please add the assert in inc_capacity_until_gc() I mentioned above!). Maybe Thomas St?fe can comment on this a bit because he looks to be having done a lot in that area. ;) Thanks, Thomas From zgu at redhat.com Mon Jan 28 14:33:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 28 Jan 2019 09:33:00 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <1c3c9b13300d13c590027e7e75edb1b3f5ce7e19.camel@oracle.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> <1548435553.31327.38.camel@redhat.com> <1548470646.31327.40.camel@redhat.com> <1c3c9b13300d13c590027e7e75edb1b3f5ce7e19.camel@oracle.com> Message-ID: <1548685980.31327.43.camel@redhat.com> Thanks, Thomas. -Zhengyu On Mon, 2019-01-28 at 11:36 +0100, Thomas Schatzl wrote: > Hi, > > On Fri, 2019-01-25 at 21:44 -0500, zgu at redhat.com wrote: > > > Updated Webrev: > > > http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.02 > > > /i > > > ndex.html > > > > > > Passed hotspot_gc test, will rerun all other tests. > > > > Passed hotspot_gc and vmTestbase_vm_gc on Linux x64 (fastdebug and > > release), also submit tests. > > > > refactoring looks good. > > Thomas > > From zgu at redhat.com Mon Jan 28 14:56:09 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 28 Jan 2019 09:56:09 -0500 Subject: RFR(XXS) 8217794: Improve termination detection in owstTaskTerminator Message-ID: <1548687369.31327.52.camel@redhat.com> Hi, Could I get review for this small enhancement, that may improve termination dectection? This is *not* a correctness issue, but latency improvement. Since it already holds lock, it is worth a quick check for termination condition. Bug: https://bugs.openjdk.java.net/browse/JDK-8217794 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217794/webrev.00/ Test: hotspot_gc on Linux x64 (fastdebug and release) Submit tests Thanks, -Zhengyu From thomas.schatzl at oracle.com Mon Jan 28 15:04:21 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Jan 2019 16:04:21 +0100 Subject: RFR(XXS) 8217794: Improve termination detection in owstTaskTerminator In-Reply-To: <1548687369.31327.52.camel@redhat.com> References: <1548687369.31327.52.camel@redhat.com> Message-ID: <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> Hi, On Mon, 2019-01-28 at 09:56 -0500, zgu at redhat.com wrote: > Hi, > > Could I get review for this small enhancement, that may improve > termination dectection? > > This is *not* a correctness issue, but latency improvement. Since it > already holds lock, it is worth a quick check for termination > condition. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217794 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217794/webrev.00/ > > Test: > hotspot_gc on Linux x64 (fastdebug and release) > Submit tests looks good. Fyi (for other reviewers) I tested (and reviewed) this change already as part of some early version of JDK-8215047. Thanks, Thomas From zgu at redhat.com Mon Jan 28 15:13:55 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 28 Jan 2019 10:13:55 -0500 Subject: RFR(XXS) 8217794: Improve termination detection in owstTaskTerminator In-Reply-To: <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> References: <1548687369.31327.52.camel@redhat.com> <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> Message-ID: <1548688435.31327.53.camel@redhat.com> Thanks for reviewing and additional info. -Zhengyu On Mon, 2019-01-28 at 16:04 +0100, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-01-28 at 09:56 -0500, zgu at redhat.com wrote: > > Hi, > > > > Could I get review for this small enhancement, that may improve > > termination dectection? > > > > This is *not* a correctness issue, but latency improvement. Since > > it > > already holds lock, it is worth a quick check for termination > > condition. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217794 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217794/webrev.00/ > > > > Test: > > hotspot_gc on Linux x64 (fastdebug and release) > > Submit tests > > looks good. > > Fyi (for other reviewers) I tested (and reviewed) this change already > as part of some early version of JDK-8215047. > > Thanks, > Thomas > > From vladimir.kozlov at oracle.com Mon Jan 28 17:40:21 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Jan 2019 09:40:21 -0800 Subject: RFR: 8217856: ZGC: Break out C2 matching rules into separate AD file In-Reply-To: References: <1b6c2fd2-d273-31d5-8cdd-5ba4f8f408d0@oracle.com> Message-ID: <226fb0ff-5c25-26bf-2b18-555353022c59@oracle.com> +1 Thanks, Vladimir On 1/28/19 1:26 AM, Nils Eliasson wrote: > Hi Per, > > Looks good! > > // Nils > > On 2019-01-28 10:04, Per Liden wrote: >> Break out ZGC specific C2 matching rules into separate AD file. This patch also introduces the >> z_load_barrier_slow_reg() function to avoid some code duplication. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217856 >> Webrev: http://cr.openjdk.java.net/~pliden/8217856/webrev.0 >> >> /Per From sangheon.kim at oracle.com Mon Jan 28 19:09:59 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Mon, 28 Jan 2019 11:09:59 -0800 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> Message-ID: <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> Hi Leo, Thank you for reviewing this. On 1/28/19 2:25 AM, Leo Korinth wrote: > Hi Sangheon, > > a few questions on the webrev: > 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? vm.nvdimm.test.enabled is added at the requires.properties list at TEST.ROOT and this is necessary for its work flow. FYI, without that change, we will see 'Syntax error in @requires expression: invalid name: vm.nvdimm.test.enabled'. > 2) most of the *Enabled() functions in VMProps.java read properties, > but here we read the environment, why is that? I think the env. variable approach seems clearer to use considering those tests will be tested on limited situations. JTREG and VM which runs requires.VMProps will be affected. JTREG doesn't propagate env variables to JDK under test unless they are specified via -e flag. I considered adding a property as well, but I ended up with the environment variable. > 3) maybe the property should be "vm.gc" prefixed instead of "vm" > prefixed, maybe not. What do you think? I'm okay with 'vm.gc' prefix. 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) Let me post the updated webrev after getting more comments. Thanks, Sangheon > > Thanks for disabling these test cases! > /Leo > > On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >> Hi all, >> >> Can I have reviews that excludes gc/nvdimm jtreg tests? >> >> Those tests were introduced by? JDK-8202286 (Allocation of old >> generation of Java heap on alternate memory devices) and tried to >> exclude all tests from all tiers. But it was incomplete so one of the >> tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java >> failure) was filed recently. >> >> The patch includes to exclude gc/nvdimm from TEST.groups, >> hotspot_misc group(which is the reason why JDK-8217406 occurred). In >> addition, added @requires to gc/nvdimm tests to avoid running the tests. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >> >> Thanks, >> Sangheon From leo.korinth at oracle.com Mon Jan 28 19:31:26 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 28 Jan 2019 20:31:26 +0100 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> Message-ID: On 28/01/2019 20:09, sangheon.kim at oracle.com wrote: > Hi Leo, > > Thank you for reviewing this. > > On 1/28/19 2:25 AM, Leo Korinth wrote: >> Hi Sangheon, >> >> a few questions on the webrev: >> 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? > vm.nvdimm.test.enabled is added at the requires.properties list at > TEST.ROOT and this is necessary for its work flow. > FYI, without that change, we will see 'Syntax error in @requires > expression: invalid name: vm.nvdimm.test.enabled'. > Thank you for the explanation. >> 2) most of the *Enabled() functions in VMProps.java read properties, >> but here we read the environment, why is that? > I think the env. variable approach seems clearer to use considering > those tests will be tested on limited situations. > JTREG and VM which runs requires.VMProps will be affected. > JTREG doesn't propagate env variables to JDK under test unless they are > specified via -e flag. > I considered adding a property as well, but I ended up with the > environment variable. Okay, I just wanted to know that it was not by accident. > >> 3) maybe the property should be "vm.gc" prefixed instead of "vm" >> prefixed, maybe not. What do you think? > I'm okay with 'vm.gc' prefix. > 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) > Let me post the updated webrev after getting more comments. I am fine with either. Your change looks good to me, and thanks a lot for fixing this problem. Keep in mind that I am just a commiter. Thanks, Leo > > Thanks, > Sangheon > >> >> Thanks for disabling these test cases! >> /Leo >> >> On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >>> Hi all, >>> >>> Can I have reviews that excludes gc/nvdimm jtreg tests? >>> >>> Those tests were introduced by? JDK-8202286 (Allocation of old >>> generation of Java heap on alternate memory devices) and tried to >>> exclude all tests from all tiers. But it was incomplete so one of the >>> tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java >>> failure) was filed recently. >>> >>> The patch includes to exclude gc/nvdimm from TEST.groups, >>> hotspot_misc group(which is the reason why JDK-8217406 occurred). In >>> addition, added @requires to gc/nvdimm tests to avoid running the tests. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >>> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >>> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >>> >>> Thanks, >>> Sangheon > From per.liden at oracle.com Mon Jan 28 21:22:48 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Jan 2019 22:22:48 +0100 Subject: RFR: 8217856: ZGC: Break out C2 matching rules into separate AD file In-Reply-To: <226fb0ff-5c25-26bf-2b18-555353022c59@oracle.com> References: <1b6c2fd2-d273-31d5-8cdd-5ba4f8f408d0@oracle.com> <226fb0ff-5c25-26bf-2b18-555353022c59@oracle.com> Message-ID: <61d65c95-9de5-a008-c214-6e14a25ee039@oracle.com> Thanks Vladimir! /Per On 01/28/2019 06:40 PM, Vladimir Kozlov wrote: > +1 > > Thanks, > Vladimir > > On 1/28/19 1:26 AM, Nils Eliasson wrote: >> Hi Per, >> >> Looks good! >> >> // Nils >> >> On 2019-01-28 10:04, Per Liden wrote: >>> Break out ZGC specific C2 matching rules into separate AD file. This >>> patch also introduces the z_load_barrier_slow_reg() function to avoid >>> some code duplication. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217856 >>> Webrev: http://cr.openjdk.java.net/~pliden/8217856/webrev.0 >>> >>> /Per From coleen.phillimore at oracle.com Mon Jan 28 21:46:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 16:46:21 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> Message-ID: <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Hi Thomas,? Can you forward the review thread for JDK-8213229? I wonder if we could just trigger_unloading after any GC has run and ignore dead string counts.? Are they ever zero? Thanks, Coleen On 1/28/19 6:45 AM, Thomas Schatzl wrote: > Hi again, > > cc'ed hotspot-runtime-dev since it concerns the string table. > > Also, this patch is based on the changes for JDK-8213229. > > Thanks, > Thomas > > On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that tries to fix the issue with >> the string table reporting too low "dead" numbers to the >> ServiceThread notification mechanism in the review for JDK-8213229, >> potentially causing C heap memory being kept live for longer than >> necessary? >> >> This change implements one option for fixing this, in particular that >> the WeakProcessor calls OopStorage::oops_do() instead of >> ::weak_oops_do, counting the number of NULL entries manually. >> >> There is another, let weak_oops_do() return the number of NULL >> entries as function return value. However the return value of the >> used iterate_safepoint() is already in use in some I'd consider >> interesting test case. I did not want to add another out-parameter >> either. >> >> Since the WeakProcessor has been the main user of the weak_oops_do() >> method, I would suggest to clean this up preferably in an extra CR: >> there is still one use of the OopStorage::weak_oops_do() method that >> could be easily removed. If you think we should not remove it, I >> strongly suggest to rename the weak_oops_do() methods to better >> indicate what they actually do instead of giving a very strong >> (wrong) suggestion where/when they should be used. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8217778 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ >> Testing: >> hs-tier1-5 >> >> Thanks, >> Thomas >> >> > From yumin.qi at gmail.com Mon Jan 28 23:03:42 2019 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 29 Jan 2019 07:03:42 +0800 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: <1548435553.31327.38.camel@redhat.com> References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> <1548435553.31327.38.camel@redhat.com> Message-ID: Zhengyu, It looks good to me. Thanks Yumin On Sat, Jan 26, 2019 at 12:59 AM wrote: > Hi, > > > > > I will think a bit more about the change while waiting for the > > > > test > > > > results. > > > > > > > > Testing showed good results, no issues. > > Thanks! > > > > > I would like to ask if I understood the changes correctly: to me it > > seems that some of these changes are the actual fix, others seem to > > be > > enhancements. > > > > So the changes in owstTaskTerminator.cpp:68-74 seem to be the actual > > fix for the issue - it needs to recheck _offered_termination within > > the > > lock at that point because of the mentioned race. > I would say that this is actually an enhancement. Without it, merely > delays the termination of this particular thread. > > Filed RFE: https://bugs.openjdk.java.net/browse/JDK-8217794 > > > > > There are additional improvements to both terminators > > (owstTaskTerminator.cpp:171-174, taskqueue.cpp:220-232) that may > > result > > in potential needless additional rounds of offer_termination(). > > I.e. before returning a result that indicates to the caller to > > continue > > doing work for another round, instead if in the meantime everyone has > > offered termination, we are obviously done too. > > > > > If I am correct, I would strongly prefer if these changes (the > > enhancements) would be changed separately. > > > > Also, the code in taskqueue.cpp:220-232 is worth an extra method with > > a > > description indicating why we can return true in offer_termination in > > that case (because obviously, if all threads are sure to have offered > > termination, between the evaluation of the condition and trying to > > decrement the _offer_termination variable, work has been completed. > > Okay. But I want to point out that it is not necessary a race, because > TerminatorTerminator may decide to request an abort based on external > conditions, which may have nothing to do with the progress of the > termination. > > Updated Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.02/i > ndex.html > > > Passed hotspot_gc test, will rerun all other tests. > > > As an additional enhancement, it might be worth doing padding of the > > ParallelTaskTerminator::_offered_termination variable. > > > I filed a separate RFE: https://bugs.openjdk.java.net/browse/JDK-821778 > 5 > > > -Zhengyu > > > > Thanks, > > Thomas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Tue Jan 29 02:03:49 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 21:03:49 -0500 Subject: RFR: 8217855: ZGC: Clean up ZReferenceProcessor In-Reply-To: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> References: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> Message-ID: > On Jan 28, 2019, at 3:59 AM, Per Liden wrote: > > Various structural and naming cleanups in ZReferenceProcessor. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217855 > Webrev: http://cr.openjdk.java.net/~pliden/8217855/webrev.0 > > /Per Looks good. A couple minor comments. I don't need a new webrev if you decide to make these changes. ------------------------------------------------------------------------------ src/hotspot/share/gc/z/zReferenceProcessor.cpp 74 static void reference_set_referent(oop reference, oop referent) { This function is only ever called with a NULL referent. And it would probably be a bad idea to change the referent in any other way. So I think it would be better to have reference_clear_referent or something like that. ------------------------------------------------------------------------------ src/hotspot/share/gc/z/zReferenceProcessor.cpp 264 if (!should_discover(reference, type)) { 265 // Not discovered 266 return false; 267 } 268 269 discover(reference, type); 270 271 // Discovered 272 return true; Perhaps clearer would be if (should_discover(reference, type)) { discover(reference, type); return true; } else { return false; } ------------------------------------------------------------------------------ From igor.ignatyev at oracle.com Tue Jan 29 02:32:33 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 28 Jan 2019 18:32:33 -0800 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> Message-ID: <5DF3743E-DDB5-459C-AC50-D6E9F744B124@oracle.com> Hi Sangheon, the code looks good to me. joining bikeshedding around the property name, I'd recommend not to use 'vm.' at all, as it was intended to mean "VM under test can/have/...", so I'd go w/ something like 'test.vm.nvdimm' or 'test.vm.gc.nvdimm'. if you really want you can have ".enabled" prefix, but in this case, it seems to be redundant. -- Igor > On Jan 28, 2019, at 11:31 AM, Leo Korinth wrote: > > > > On 28/01/2019 20:09, sangheon.kim at oracle.com wrote: >> Hi Leo, >> Thank you for reviewing this. >> On 1/28/19 2:25 AM, Leo Korinth wrote: >>> Hi Sangheon, >>> >>> a few questions on the webrev: >>> 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? >> vm.nvdimm.test.enabled is added at the requires.properties list at TEST.ROOT and this is necessary for its work flow. >> FYI, without that change, we will see 'Syntax error in @requires expression: invalid name: vm.nvdimm.test.enabled'. > > Thank you for the explanation. > >>> 2) most of the *Enabled() functions in VMProps.java read properties, but here we read the environment, why is that? >> I think the env. variable approach seems clearer to use considering those tests will be tested on limited situations. >> JTREG and VM which runs requires.VMProps will be affected. >> JTREG doesn't propagate env variables to JDK under test unless they are specified via -e flag. >> I considered adding a property as well, but I ended up with the environment variable. > Okay, I just wanted to know that it was not by accident. > >>> 3) maybe the property should be "vm.gc" prefixed instead of "vm" prefixed, maybe not. What do you think? >> I'm okay with 'vm.gc' prefix. >> 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) > Let me post the updated webrev after getting more comments. > I am fine with either. Your change looks good to me, and thanks a lot for fixing this problem. Keep in mind that I am just a commiter. > > Thanks, > Leo >> Thanks, >> Sangheon >>> >>> Thanks for disabling these test cases! >>> /Leo >>> >>> On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >>>> Hi all, >>>> >>>> Can I have reviews that excludes gc/nvdimm jtreg tests? >>>> >>>> Those tests were introduced by JDK-8202286 (Allocation of old generation of Java heap on alternate memory devices) and tried to exclude all tests from all tiers. But it was incomplete so one of the tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java failure) was filed recently. >>>> >>>> The patch includes to exclude gc/nvdimm from TEST.groups, hotspot_misc group(which is the reason why JDK-8217406 occurred). In addition, added @requires to gc/nvdimm tests to avoid running the tests. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >>>> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >>>> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >>>> >>>> Thanks, >>>> Sangheon From kim.barrett at oracle.com Tue Jan 29 02:39:41 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 21:39:41 -0500 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: <6288740d1483e78e6bc3b8be6f1d3f52993611fb.camel@oracle.com> References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> <72D53764-202B-48FB-B77B-476C60A7027D@oracle.com> <6288740d1483e78e6bc3b8be6f1d3f52993611fb.camel@oracle.com> Message-ID: > On Jan 24, 2019, at 7:55 AM, Thomas Schatzl wrote: > On Wed, 2019-01-23 at 23:07 -0500, Kim Barrett wrote: >> >> General question: There are various places that now unconditionally >> report or log information about various string dedup passes, even >> when string dedup is disabled. I've questioned at least some of them >> below, but it's so common that now I'm wondering if perhaps this is >> intentional? > > I was already prototyping a change that moved more work into the > PartialCleaningTask, and backed it out before proposing the change. > Naturally it would have unconditional timing of the whole phase (like > suggested e.g. in JDK-8040006 - including e.g. WeakProcessor handling > and the card table clear in that phase too). When removing these > changes, I kept parts of what I found somewhat useful to have - like > always reporting (total) timing for this phase. > > Reconsidering, I think we should not cram this into this change. There > is a new webrev that removes all that. OK. >> src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> 3397 // Ideally we would use a StringDedupCleaningTask here, but >> since we want to >> 3398 // take the time we need to copy the code here. >> >> Maybe s/take the time/record the time/ ? >> >> I found the current wording confusing. > > This code is a duplicate of StringDedupCleaningTask (which ultimately > calls StringDedup::parallel_unlink, which calls these two > unlink_or_oops_do methods); however, I did not want to mess with the > StringDedup* code introducing parameters for passing a container to > hold the various subtimings here. > > How to collect timing information across gangtasks should imho be a > different discussion. I would like to at least try to avoid having a > separate "StringDedupTiming" class just for string dedup like done so > (too?) often already (ref proc, weak processor, ...) > > That's why the change basically copy&pastes the code from > StringDedup::parallel_unlink() here. I hope the new code is more > understandable. I understood that. It was just the comment wording that gave me trouble. ?take the time? := use time or expend effort. The new code is good though, and addresses the comment problem. >> src/hotspot/share/gc/shared/weakProcessor.inline.hpp >> 51 bool result = _inner->do_object_b(obj); >> 52 _num_dead += !result; >> >> 57 size_t num_dead() const { return _num_dead; } >> >> This calculates the number of recently deceased, and does not include >> entries that were nulled out by some previous collection but not yet >> removed by the service thread. But the calculations based on: >> >> 89 StringTable::inc_dead_counter(cl.num_dead()); >> >> want the number of nulled out entries. >> >> I don't see a convenient way to obtain the number that should be >> passed to inc_dead_counter here, at least not while using >> weak_oops_do. What I think needs to be passed to inc_dead_counter is >> the number of previously nulled entries + the number of newly dead >> entries. Using oops_do rather than weak_oops_do would allow getting >> the missing number. >> >> The serial WeakProcessor has the same problem. >> >> We talked about this offline last week, and I think we got it wrong. >> I was working with what I remembered of that part of the StringTable >> API, and it looks like my memory was faulty. Sorry about that. > > From what I understand this is actually an existing bug - the old code > (in StringTable) also directly set StringTable::_uncleaned_items_count > as returned by the count of the IsAliveClosure in weak_oops_do(). > > I would prefer fixing this separately as I believe the exact way to do > this best will be another discussion. I can file a CR for that. OK. > New webrevs at: > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2_to_3/ (diff) > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.3/ (full) > Testing: > locally running gc/g1, started hs-tier1-5 Looks good. One very minor formatting nit, for which I don?t need a new webrev. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.hpp 1336 void string_dedup_cleaning(BoolObjectClosure* is_alive, 1337 OopClosure* keep_alive, 1338 G1GCPhaseTimes* phase_times = NULL); Second and third parameters are not indented consistently with other code; should be aligned with the first parameter. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Jan 29 03:24:23 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 22:24:23 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> Message-ID: <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that tries to fix the issue with > the string table reporting too low "dead" numbers to the > ServiceThread notification mechanism in the review for JDK-8213229, > potentially causing C heap memory being kept live for longer than > necessary? > > This change implements one option for fixing this, in particular that > the WeakProcessor calls OopStorage::oops_do() instead of > ::weak_oops_do, counting the number of NULL entries manually. I think this is the right approach to take. > There is another, let weak_oops_do() return the number of NULL > entries as function return value. However the return value of the > used iterate_safepoint() is already in use in some I'd consider > interesting test case. I did not want to add another out-parameter > either. That short-circuiting behavior and result is to support some places in JVMTI that have not (yet) been modified to make use of the feature. There might be other places that could benefit. > Since the WeakProcessor has been the main user of the weak_oops_do() > method, I would suggest to clean this up preferably in an extra CR: > there is still one use of the OopStorage::weak_oops_do() method that > could be easily removed. If you think we should not remove it, I > strongly suggest to rename the weak_oops_do() methods to better > indicate what they actually do instead of giving a very strong > (wrong) suggestion where/when they should be used. Where is the remaining weak_oops_do? I don't have any objection to it being removed, as it exists only for convenience of callers. If there aren't any callers... As I said privately, OopStorage::weak_oops_do is just following a common idiom used elsewhere, where it's a shorthand for an oops_do with a closure that does if-nonnull-then-if-isalive-then-keepalive-else-clear There is nothing wrong with applying oops_do to an OopStorage containing weak oops, and in fact there are various places that do exactly that. Or said differently, it is not necessary to use weak_oops_do to iterate over an OopStorage containing weak oops. > CR: > https://bugs.openjdk.java.net/browse/JDK-8217778 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ > Testing: > hs-tier1-5 > > Thanks, > Thomas Looks good. A couple minor cleanup suggestions. I don't need another webrev if you decide to do these. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.cpp 41 CountingIsAliveClosure cl(is_alive); Why are we counting here? We don't do anything with the resulting count. (I missed this when reviewing JDK-8213229.) Similarly here, when !is_stringtable(phase): 44 CountingSkippedIsAliveClosure cl(is_alive, keep_alive); There could instead be a separate is_stringtable(phase) clause which had the calls to StringTable::(reset|finish)_dead_counter() and the counting closure stuff all close together and associated only with the stringtable storage iteration. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.inline.hpp 74 if (obj == NULL) { 75 _num_skipped++; 76 return; 77 } 78 if (_counting_is_alive.do_object_b(obj)) { 79 _keep_alive->do_oop(p); 80 } else { 81 *p = NULL; 82 } This would be simpler if the line 76 "return" were removed and the line 78 "if" were an "else if", having a single if-ladder. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Jan 29 03:58:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 22:58:35 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> Message-ID: <406D82B0-803C-4998-8237-9902B82FB763@oracle.com> > On Jan 28, 2019, at 10:24 PM, Kim Barrett wrote: > >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8217778 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ >> Testing: >> hs-tier1-5 >> >> Thanks, >> Thomas > > Looks good. > > A couple minor cleanup suggestions. I don't need another webrev if > you decide to do these. > Sorry, I missed this: ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.cpp 44 CountingSkippedIsAliveClosure cl(is_alive, keep_alive); A different approach is possible in this serial case. We could wrap the keep_alive closure for counting, as the number we want to pass to inc_dead_counter is also available here as storage->allocation_count() - ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Jan 29 04:02:14 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 23:02:14 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Message-ID: > On Jan 28, 2019, at 4:46 PM, coleen.phillimore at oracle.com wrote: > > > Hi Thomas, Can you forward the review thread for JDK-8213229? > > I wonder if we could just trigger_unloading after any GC has run and ignore dead string counts. Are they ever zero? We?re trying to only trigger the ServiceThread?s StringTable cleanup when there are enough nulled-out entries to make it worth the effort. My guess would be that interned strings rarely die young. In which case that approach would probably trigger the ServiceThread unnecessarily frequently. Maybe instead avoid the counting and unconditionally trigger after a (possibly concurrent) full collection? That doesn?t do so well for the (possibly rare?) application that does frequently intern and then drop strings though. Or don?t trigger the ServiceThread more often than some (perhaps configurable? Ugh! A new CLOption) frequency. Also, I wonder if the SymbolTable has the same miscalculation. The SymbolTable code was somewhat cribbed from StringTable, after all. From sangheon.kim at oracle.com Tue Jan 29 05:08:20 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Mon, 28 Jan 2019 21:08:20 -0800 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: <5DF3743E-DDB5-459C-AC50-D6E9F744B124@oracle.com> References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> <5DF3743E-DDB5-459C-AC50-D6E9F744B124@oracle.com> Message-ID: Hi Igor, On 1/28/19 6:32 PM, Igor Ignatyev wrote: > Hi Sangheon, > > the code looks good to me. Thank you for your review! Forgot to mention, thank you for providing the idea of using @requires as well. > > joining bikeshedding around the property name, I'd recommend not to use 'vm.' at all, as it was intended to mean "VM under test can/have/...", so I'd go w/ something like 'test.vm.nvdimm' or 'test.vm.gc.nvdimm'. if you really want you can have ".enabled" prefix, but in this case, it seems to be redundant. I changed to 'test.vm.gc.nvdimm'. http://cr.openjdk.java.net/~sangheki/8217666/webrev.1/ (as I feel incremental webrev doesn't help, didn't generated) Thanks, Sangheon > > -- Igor > >> On Jan 28, 2019, at 11:31 AM, Leo Korinth wrote: >> >> >> >> On 28/01/2019 20:09, sangheon.kim at oracle.com wrote: >>> Hi Leo, >>> Thank you for reviewing this. >>> On 1/28/19 2:25 AM, Leo Korinth wrote: >>>> Hi Sangheon, >>>> >>>> a few questions on the webrev: >>>> 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? >>> vm.nvdimm.test.enabled is added at the requires.properties list at TEST.ROOT and this is necessary for its work flow. >>> FYI, without that change, we will see 'Syntax error in @requires expression: invalid name: vm.nvdimm.test.enabled'. >> Thank you for the explanation. >> >>>> 2) most of the *Enabled() functions in VMProps.java read properties, but here we read the environment, why is that? >>> I think the env. variable approach seems clearer to use considering those tests will be tested on limited situations. >>> JTREG and VM which runs requires.VMProps will be affected. >>> JTREG doesn't propagate env variables to JDK under test unless they are specified via -e flag. >>> I considered adding a property as well, but I ended up with the environment variable. >> Okay, I just wanted to know that it was not by accident. >> >>>> 3) maybe the property should be "vm.gc" prefixed instead of "vm" prefixed, maybe not. What do you think? >>> I'm okay with 'vm.gc' prefix. >>> 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) > Let me post the updated webrev after getting more comments. >> I am fine with either. Your change looks good to me, and thanks a lot for fixing this problem. Keep in mind that I am just a commiter. >> >> Thanks, >> Leo >>> Thanks, >>> Sangheon >>>> Thanks for disabling these test cases! >>>> /Leo >>>> >>>> On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >>>>> Hi all, >>>>> >>>>> Can I have reviews that excludes gc/nvdimm jtreg tests? >>>>> >>>>> Those tests were introduced by JDK-8202286 (Allocation of old generation of Java heap on alternate memory devices) and tried to exclude all tests from all tiers. But it was incomplete so one of the tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java failure) was filed recently. >>>>> >>>>> The patch includes to exclude gc/nvdimm from TEST.groups, hotspot_misc group(which is the reason why JDK-8217406 occurred). In addition, added @requires to gc/nvdimm tests to avoid running the tests. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >>>>> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >>>>> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >>>>> >>>>> Thanks, >>>>> Sangheon From per.liden at oracle.com Tue Jan 29 07:51:26 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 29 Jan 2019 08:51:26 +0100 Subject: RFR: 8217855: ZGC: Clean up ZReferenceProcessor In-Reply-To: References: <0913e3cb-e458-320b-7d42-7d69dbbd7ba6@oracle.com> Message-ID: <968ef54c-de71-6b3f-9242-49c85496a9ee@oracle.com> Thanks for reviewing Kim. /Per On 01/29/2019 03:03 AM, Kim Barrett wrote: >> On Jan 28, 2019, at 3:59 AM, Per Liden wrote: >> >> Various structural and naming cleanups in ZReferenceProcessor. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217855 >> Webrev: http://cr.openjdk.java.net/~pliden/8217855/webrev.0 >> >> /Per > > Looks good. > > A couple minor comments. I don't need a new webrev if you decide to > make these changes. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/z/zReferenceProcessor.cpp > 74 static void reference_set_referent(oop reference, oop referent) { > > This function is only ever called with a NULL referent. And it would > probably be a bad idea to change the referent in any other way. So I > think it would be better to have reference_clear_referent or something > like that. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/z/zReferenceProcessor.cpp > 264 if (!should_discover(reference, type)) { > 265 // Not discovered > 266 return false; > 267 } > 268 > 269 discover(reference, type); > 270 > 271 // Discovered > 272 return true; > > Perhaps clearer would be > > if (should_discover(reference, type)) { > discover(reference, type); > return true; > } else { > return false; > } > > ------------------------------------------------------------------------------ > From leo.korinth at oracle.com Tue Jan 29 09:15:29 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 29 Jan 2019 10:15:29 +0100 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> <5DF3743E-DDB5-459C-AC50-D6E9F744B124@oracle.com> Message-ID: <6e72908f-f5d9-6778-f405-56ebaabf2686@oracle.com> Still looks good. Thanks, Leo On 29/01/2019 06:08, sangheon.kim at oracle.com wrote: > Hi Igor, > > On 1/28/19 6:32 PM, Igor Ignatyev wrote: >> Hi Sangheon, >> >> the code looks good to me. > Thank you for your review! > Forgot to mention, thank you for providing the idea of using @requires > as well. > >> >> joining bikeshedding around the property name, I'd recommend not to >> use 'vm.' at all, as it was intended to mean "VM under test >> can/have/...", so I'd go w/ something like 'test.vm.nvdimm' or >> 'test.vm.gc.nvdimm'. if you really want you can have ".enabled" >> prefix, but in this case, it seems to be redundant. > I changed to 'test.vm.gc.nvdimm'. > > http://cr.openjdk.java.net/~sangheki/8217666/webrev.1/ > (as I feel incremental webrev doesn't help, didn't generated) > > Thanks, > Sangheon > > >> >> -- Igor >> >>> On Jan 28, 2019, at 11:31 AM, Leo Korinth >>> wrote: >>> >>> >>> >>> On 28/01/2019 20:09, sangheon.kim at oracle.com wrote: >>>> Hi Leo, >>>> Thank you for reviewing this. >>>> On 1/28/19 2:25 AM, Leo Korinth wrote: >>>>> Hi Sangheon, >>>>> >>>>> a few questions on the webrev: >>>>> 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? >>>> vm.nvdimm.test.enabled is added at the requires.properties list at >>>> TEST.ROOT and this is necessary for its work flow. >>>> FYI, without that change, we will see 'Syntax error in @requires >>>> expression: invalid name: vm.nvdimm.test.enabled'. >>> Thank you for the explanation. >>> >>>>> 2) most of the *Enabled() functions in VMProps.java read >>>>> properties, but here we read the environment, why is that? >>>> I think the env. variable approach seems clearer to use considering >>>> those tests will be tested on limited situations. >>>> JTREG and VM which runs requires.VMProps will be affected. >>>> JTREG doesn't propagate env variables to JDK under test unless they >>>> are specified via -e flag. >>>> I considered adding a property as well, but I ended up with the >>>> environment variable. >>> Okay, I just wanted to know that it was not by accident. >>> >>>>> 3) maybe the property should be "vm.gc" prefixed instead of "vm" >>>>> prefixed, maybe not. What do you think? >>>> I'm okay with 'vm.gc' prefix. >>>> 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) > Let me >>>> post the updated webrev after getting more comments. >>> I am fine with either. Your change looks good to me, and thanks a lot >>> for fixing this problem. Keep in mind that I am just a commiter. >>> >>> Thanks, >>> Leo >>>> Thanks, >>>> Sangheon >>>>> Thanks for disabling these test cases! >>>>> /Leo >>>>> >>>>> On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >>>>>> Hi all, >>>>>> >>>>>> Can I have reviews that excludes gc/nvdimm jtreg tests? >>>>>> >>>>>> Those tests were introduced by? JDK-8202286 (Allocation of old >>>>>> generation of Java heap on alternate memory devices) and tried to >>>>>> exclude all tests from all tiers. But it was incomplete so one of >>>>>> the tests failed and JDK-8217406 >>>>>> (gc/nvdimm/TestOldObjectsOnNvdimm.java failure) was filed recently. >>>>>> >>>>>> The patch includes to exclude gc/nvdimm from TEST.groups, >>>>>> hotspot_misc group(which is the reason why JDK-8217406 occurred). >>>>>> In addition, added @requires to gc/nvdimm tests to avoid running >>>>>> the tests. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >>>>>> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >>>>>> >>>>>> Thanks, >>>>>> Sangheon > From erik.osterlund at oracle.com Tue Jan 29 09:23:29 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Jan 2019 10:23:29 +0100 Subject: RFR: 8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer In-Reply-To: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> References: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> Message-ID: <5f4b5359-2fb3-8a8c-70e5-745e868762e4@oracle.com> +1 On 2019-01-28 10:00, Per Liden wrote: > Move instanciation of SvcGCMarker to ZServiceabilityTracer, where it > belongs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217857 > Webrev: http://cr.openjdk.java.net/~pliden/8217857/webrev.0 > > /Per From erik.osterlund at oracle.com Tue Jan 29 09:23:26 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Jan 2019 10:23:26 +0100 Subject: RFR: 8217858: ZGC: Clean up ZDriver In-Reply-To: References: Message-ID: <8ce15d6f-6ca4-0511-95e1-3f1954e8f7dc@oracle.com> +1 On 2019-01-28 10:01, Per Liden wrote: > Various structural and naming cleanups in ZDriver. Most notably, the > ZOperationClosure types were replaced by true VM operation types. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217858 > Webrev: http://cr.openjdk.java.net/~pliden/8217858/webrev.0 > > /Per From erik.osterlund at oracle.com Tue Jan 29 09:24:33 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Jan 2019 10:24:33 +0100 Subject: RFR: 8217747: ZGC: Minor optimization of ZLoadBarrierStubC1 In-Reply-To: References: Message-ID: <86d64ca0-75da-a043-06e1-fe01b4e932a9@oracle.com> Hi Per, While I think this optimization is going to be completely invisible in all profiles, I don't mind it either. Looks good. Thanks, /Erik On 2019-01-28 09:56, Per Liden wrote: > In the C1 load barrier stub for ZGC we currently save/restore rax unless > it's the stub result register. However, we can also avoid this > save/restore of rax if it's the tmp register. Avoiding a push/pop in the > stub isn't really an important optimization, but since we already do it > for the result register we can just as well do it for the tmp register > too, without making the code more complex. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217747 > Webrev: http://cr.openjdk.java.net/~pliden/8217747/webrev.0 > > /Per From erik.osterlund at oracle.com Tue Jan 29 09:26:50 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Jan 2019 10:26:50 +0100 Subject: RFR: 8217745: ZGC: Simplify ZLoadBarrierStubC1 In-Reply-To: References: Message-ID: <436bdfd1-12cc-066c-3f9c-b48e503ed19e@oracle.com> +1 On 2019-01-28 09:54, Per Liden wrote: > We can simplify ZLoadBarrierStubC1 a little bit since we know that > _ref_addr is always a LIR_Address and never a Register. In the > ZLoadBarrierStubC1 constructor we can just assert that this is always > true. Later, when emitting code, we can just use the presence of the tmp > register as indicator that we need to load the effective address. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217745 > Webrev: http://cr.openjdk.java.net/~pliden/8217745/webrev.0 > > /Per From per.liden at oracle.com Tue Jan 29 09:28:00 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 29 Jan 2019 10:28:00 +0100 Subject: RFR: 8217747: ZGC: Minor optimization of ZLoadBarrierStubC1 In-Reply-To: <86d64ca0-75da-a043-06e1-fe01b4e932a9@oracle.com> References: <86d64ca0-75da-a043-06e1-fe01b4e932a9@oracle.com> Message-ID: On 01/29/2019 10:24 AM, Erik ?sterlund wrote: > Hi Per, > > While I think this optimization is going to be completely invisible in > all profiles, I don't mind it either. Looks good. Thanks for reviewing, Erik. I agree, I mostly just found it annoying to see those push/pop when inspecting the generated code. /Per > > Thanks, > /Erik > > On 2019-01-28 09:56, Per Liden wrote: >> In the C1 load barrier stub for ZGC we currently save/restore rax >> unless it's the stub result register. However, we can also avoid this >> save/restore of rax if it's the tmp register. Avoiding a push/pop in >> the stub isn't really an important optimization, but since we already >> do it for the result register we can just as well do it for the tmp >> register too, without making the code more complex. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217747 >> Webrev: http://cr.openjdk.java.net/~pliden/8217747/webrev.0 >> >> /Per From per.liden at oracle.com Tue Jan 29 09:29:52 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 29 Jan 2019 10:29:52 +0100 Subject: RFR: 8217858: ZGC: Clean up ZDriver In-Reply-To: <8ce15d6f-6ca4-0511-95e1-3f1954e8f7dc@oracle.com> References: <8ce15d6f-6ca4-0511-95e1-3f1954e8f7dc@oracle.com> Message-ID: <116c1bf2-64b4-ecfc-8eb4-e2735549723e@oracle.com> Thanks Erik! /Per On 01/29/2019 10:23 AM, Erik ?sterlund wrote: > +1 > > On 2019-01-28 10:01, Per Liden wrote: >> Various structural and naming cleanups in ZDriver. Most notably, the >> ZOperationClosure types were replaced by true VM operation types. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217858 >> Webrev: http://cr.openjdk.java.net/~pliden/8217858/webrev.0 >> >> /Per From per.liden at oracle.com Tue Jan 29 09:29:40 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 29 Jan 2019 10:29:40 +0100 Subject: RFR: 8217745: ZGC: Simplify ZLoadBarrierStubC1 In-Reply-To: <436bdfd1-12cc-066c-3f9c-b48e503ed19e@oracle.com> References: <436bdfd1-12cc-066c-3f9c-b48e503ed19e@oracle.com> Message-ID: Thanks Erik! /Per On 01/29/2019 10:26 AM, Erik ?sterlund wrote: > +1 > > On 2019-01-28 09:54, Per Liden wrote: >> We can simplify ZLoadBarrierStubC1 a little bit since we know that >> _ref_addr is always a LIR_Address and never a Register. In the >> ZLoadBarrierStubC1 constructor we can just assert that this is always >> true. Later, when emitting code, we can just use the presence of the >> tmp register as indicator that we need to load the effective address. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217745 >> Webrev: http://cr.openjdk.java.net/~pliden/8217745/webrev.0 >> >> /Per From per.liden at oracle.com Tue Jan 29 09:29:47 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 29 Jan 2019 10:29:47 +0100 Subject: RFR: 8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer In-Reply-To: <5f4b5359-2fb3-8a8c-70e5-745e868762e4@oracle.com> References: <09470526-ba00-f735-0c23-28574216f2f2@oracle.com> <5f4b5359-2fb3-8a8c-70e5-745e868762e4@oracle.com> Message-ID: Thanks Erik! /Per On 01/29/2019 10:23 AM, Erik ?sterlund wrote: > +1 > > On 2019-01-28 10:00, Per Liden wrote: >> Move instanciation of SvcGCMarker to ZServiceabilityTracer, where it >> belongs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217857 >> Webrev: http://cr.openjdk.java.net/~pliden/8217857/webrev.0 >> >> /Per From thomas.schatzl at oracle.com Tue Jan 29 09:34:13 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 29 Jan 2019 10:34:13 +0100 Subject: RFR (L): 8213229: Investigate treating StringTable as weak in young collections In-Reply-To: References: <40C56EAA-BACB-4437-9C5F-2675786E8E57@oracle.com> <27163d961f9b0ab1f13ebe4d64a05c0b60e06bb8.camel@oracle.com> <72D53764-202B-48FB-B77B-476C60A7027D@oracle.com> <6288740d1483e78e6bc3b8be6f1d3f52993611fb.camel@oracle.com> Message-ID: <4deeeb866cca3f5e2e1834d7780f4aacce99e229.camel@oracle.com> Hi Kim, On Mon, 2019-01-28 at 21:39 -0500, Kim Barrett wrote: > > On Jan 24, 2019, at 7:55 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > On Wed, 2019-01-23 at 23:07 -0500, Kim Barrett wrote: > > > > > > [...] > > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp > > > 3397 // Ideally we would use a StringDedupCleaningTask here, > > > but since we want to > > > 3398 // take the time we need to copy the code here. > > > > > > Maybe s/take the time/record the time/ ? > > > > > > I found the current wording confusing. > > > > > [...] > > I understood that. It was just the comment wording that gave me > trouble. > ?take the time? := use time or expend effort. Oooh, thanks! [...] > > > New webrevs at: > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.2_to_3/ (diff) > > http://cr.openjdk.java.net/~tschatzl/8213229/webrev.3/ (full) > > Testing: > > locally running gc/g1, started hs-tier1-5 > > Looks good. > > One very minor formatting nit, for which I don?t need a new webrev. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1CollectedHeap.hpp > 1336 void string_dedup_cleaning(BoolObjectClosure* is_alive, > 1337 OopClosure* keep_alive, > 1338 G1GCPhaseTimes* phase_times = NULL); > Second and third parameters are not indented consistently with other > code; should be aligned with the first parameter. > > ------------------------------------------------------------------- > ----------- > Fixed. Thanks for your review. Thomas From thomas.schatzl at oracle.com Tue Jan 29 09:51:31 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 29 Jan 2019 10:51:31 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Message-ID: <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> Hi, On Mon, 2019-01-28 at 16:46 -0500, coleen.phillimore at oracle.com wrote: > Hi Thomas, Can you forward the review thread for JDK-8213229? the thread starts at http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024474.html , but the interesting part is probably starting here http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024649.html . > I wonder if we could just trigger_unloading after any GC has run and > ignore dead string counts. Are they ever zero? That seems to be a waste of cpu cycles assuming that interned strings typically have a "long" lifetime. Thanks, Thomas From yasuenag at gmail.com Tue Jan 29 12:39:53 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 29 Jan 2019 21:39:53 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> Message-ID: Thank you for your comment. I uploaded new webrev (it passed all tests on submit repo): http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.01/ I write reply based on it as below. On 2019/01/28 22:55, Thomas Schatzl wrote: > Hi Yasumasa, > > On Fri, 2019-01-25 at 11:35 +0900, Yasumasa Suenaga wrote: >> PING: Could you review this? >> >> >> Yasumasa >> >> >> On 2019/01/21 17:52, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I filed this issue to JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8217432 >>> >>> I investigated it, and I found that `minimum_desired_capacity` and >>> `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()` >>> might exceed MaxMetaspaceSize. >>> They shouldn't exceed MaxMetaspaceSize. >>> >>> I uploaded webrev for this bug. Could you review it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ >>> >>> This change has passed all tests on submit repo, >>> :vmTestbase_vm_metaspace, >>> and :vmTestbase_nsk_sysdict jtreg tests. > > The suggested change does not work - you can't return false from > MetaspaceGC::inc_capacity_until_gc() because the return value indicates > whether it was possible to change the value, not whether the value > passed sense. > > The code before that must make sure that the resulting value is within > limits (that could be a good assert in inc_capacity_until_GC()) from my > understanding, without being an expert here. > > So with the current change, the assert in metaspace.cpp:260 would > simply fire in this case. I added assert() to inc_capacity_until_GC() because _capacity_until_GC shouldn't exceed MaxMetaspaceSize. This function will not return false when _capacity_until_GC attempt to be exceeded MaxMetaspaceSize. > Making sure that the HWM does not go over MaxMetaspaceSize could be > achieved by limiting expand_bytes passed to the method; I *think*, > without following where minimum_desired_capacity is also used in that > method, clamping it via > > 241: minimum_desired_capacity = MIN2(MAX2(minimum_desired_capacity, > MetaspaceSize), MaxMetaspaceSize); > > would achieve the desired effect. Your suggestion seems to be equivalent to my change. ------------- const double min_tmp = used_after_gc / maximum_used_percentage; size_t minimum_desired_capacity = - (size_t)MIN2(min_tmp, double(max_uintx)); + (size_t)MIN2(min_tmp, double(MaxMetaspaceSize)); // Don't shrink less than the initial generation size minimum_desired_capacity = MAX2(minimum_desired_capacity, MetaspaceSize); ------------- I don't understand why current implementation use `max_uintx` at this. I guess it means "max value of Metaspace", so I think it should use MaxMetaspaceSize rather than max_uintx. > Could you also provide a test case for this change (i.e. failing > before, good after) as Aleksey suggested? It is hard to reproduce this problem because this issue is caused by C++ member variable (MetaspaceGC::_capacity_until_GC). It can be tested with WhiteBox test (incMetaspaceCapacityUntilGC()), however it tests inc_capacity_until_GC() call only. OTOH we might test as Aleksey said, but we can't estimate precise commit memory size of Metaspace, and evaluate why OOME is occurred. (memory consumption or invalid _capacity_until_GC) As I said before, I added assert() to inc_capacity_until_GC(). It will fail without other change in this webrev. So I think we can evaluate it via vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java . > Note that my suggestion only fixes the call to inc_capacity_until_gc() > in MetaspaceGC::compute_new_size(). I very much believe it is required > to add another guard in ClassLoaderMetaspace::expand_and_allocate(). > > (Please add the assert in inc_capacity_until_gc() I mentioned above!). I added the code to check total amount of _capacity_until_GC before inc_capacity_until_GC() call. But I concern the check and increment are not atomically. Is it okay? > Maybe Thomas St?fe can comment on this a bit because he looks to be > having done a lot in that area. ;) Comments are welcome! Thanks, Yasumasa > Thanks, > Thomas > > From zgu at redhat.com Tue Jan 29 13:23:05 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 29 Jan 2019 08:23:05 -0500 Subject: RFR 8215047: Task terminators do not complete termination in consistent state In-Reply-To: References: <1546530552.3477.31.camel@redhat.com> <4113a2d2-5608-9df5-40a0-2bc0cfbab538@redhat.com> <5ecde8ae8ae7b7600ef614c880ed912e264ad00b.camel@oracle.com> <1548253965.31327.2.camel@redhat.com> <1548435553.31327.38.camel@redhat.com> Message-ID: <1548768185.31327.62.camel@redhat.com> Thank you for the review, Yumin. -Zhengyu On Tue, 2019-01-29 at 07:03 +0800, yumin qi wrote: > Zhengyu, > > It looks good to me. > > Thanks > Yumin > > On Sat, Jan 26, 2019 at 12:59 AM wrote: > > Hi, > > > > > > > I will think a bit more about the change while waiting for > > the > > > > > test > > > > > results. > > > > > > > > > > > Testing showed good results, no issues. > > > > Thanks! > > > > > > > > I would like to ask if I understood the changes correctly: to me > > it > > > seems that some of these changes are the actual fix, others seem > > to > > > be > > > enhancements. > > > > > > So the changes in owstTaskTerminator.cpp:68-74 seem to be the > > actual > > > fix for the issue - it needs to recheck _offered_termination > > within > > > the > > > lock at that point because of the mentioned race. > > I would say that this is actually an enhancement. Without it, > > merely > > delays the termination of this particular thread. > > > > Filed RFE: https://bugs.openjdk.java.net/browse/JDK-8217794 > > > > > > > > There are additional improvements to both terminators > > > (owstTaskTerminator.cpp:171-174, taskqueue.cpp:220-232) that may > > > result > > > in potential needless additional rounds of offer_termination(). > > > I.e. before returning a result that indicates to the caller to > > > continue > > > doing work for another round, instead if in the meantime everyone > > has > > > offered termination, we are obviously done too. > > > > > > > > If I am correct, I would strongly prefer if these changes (the > > > enhancements) would be changed separately. > > > > > > Also, the code in taskqueue.cpp:220-232 is worth an extra method > > with > > > a > > > description indicating why we can return true in > > offer_termination in > > > that case (because obviously, if all threads are sure to have > > offered > > > termination, between the evaluation of the condition and trying > > to > > > decrement the _offer_termination variable, work has been > > completed. > > > > Okay. But I want to point out that it is not necessary a race, > > because > > TerminatorTerminator may decide to request an abort based on > > external > > conditions, which may have nothing to do with the progress of the > > termination. > > > > Updated Webrev: http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev. > > 02/i > > ndex.html > > > > Passed hotspot_gc test, will rerun all other tests. > > > > > As an additional enhancement, it might be worth doing padding of > > the > > > ParallelTaskTerminator::_offered_termination variable. > > > > > I filed a separate RFE: https://bugs.openjdk.java.net/browse/JDK-82 > > 1778 > > 5 > > > > > > -Zhengyu > > > > > > > Thanks, > > > Thomas > > > > > > From zgu at redhat.com Tue Jan 29 16:54:06 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 29 Jan 2019 11:54:06 -0500 Subject: RFR(XXS) 8217794: Improve termination detection in owstTaskTerminator In-Reply-To: <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> References: <1548687369.31327.52.camel@redhat.com> <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> Message-ID: <1548780846.31327.69.camel@redhat.com> Hi, It turns out to be a bug after it was split from JDK-8215047. Please see the bug for details. I changed bug synopsis to "Missing termination check results violation of termination invariant" and updated Prirority to P2. Could I get a second reivew ASAP, so it can unbreak the mainline. There is no change to the fix. Thanks, -Zhengyu On Mon, 2019-01-28 at 16:04 +0100, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-01-28 at 09:56 -0500, zgu at redhat.com wrote: > > Hi, > > > > Could I get review for this small enhancement, that may improve > > termination dectection? > > > > This is *not* a correctness issue, but latency improvement. Since > > it > > already holds lock, it is worth a quick check for termination > > condition. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217794 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217794/webrev.00/ > > > > Test: > > hotspot_gc on Linux x64 (fastdebug and release) > > Submit tests > > looks good. > > Fyi (for other reviewers) I tested (and reviewed) this change already > as part of some early version of JDK-8215047. > > Thanks, > Thomas > > From shade at redhat.com Tue Jan 29 17:04:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 29 Jan 2019 18:04:14 +0100 Subject: RFR(XXS) 8217794: Improve termination detection in owstTaskTerminator In-Reply-To: <1548780846.31327.69.camel@redhat.com> References: <1548687369.31327.52.camel@redhat.com> <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> <1548780846.31327.69.camel@redhat.com> Message-ID: <2b1d2320-ff63-1f80-9dca-e4f44ed4b018@redhat.com> On 1/29/19 5:54 PM, zgu at redhat.com wrote: > It turns out to be a bug after it was split from JDK-8215047. > Please see the bug for details. So, this failure is actually caught by assert, right? > I changed bug synopsis to "Missing termination check results violation > of termination invariant" and updated Prirority to P2. > > Could I get a second reivew ASAP, so it can unbreak the mainline. You have it now. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217794 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217794/webrev.00/ Looks good. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Tue Jan 29 17:08:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 29 Jan 2019 12:08:00 -0500 Subject: RFR(XXS) 8217794: Improve termination detection in owstTaskTerminator In-Reply-To: <2b1d2320-ff63-1f80-9dca-e4f44ed4b018@redhat.com> References: <1548687369.31327.52.camel@redhat.com> <603c6a66b871029b5b1d766eb81ee56258400b9c.camel@oracle.com> <1548780846.31327.69.camel@redhat.com> <2b1d2320-ff63-1f80-9dca-e4f44ed4b018@redhat.com> Message-ID: <1548781680.31327.74.camel@redhat.com> On Tue, 2019-01-29 at 18:04 +0100, Aleksey Shipilev wrote: > On 1/29/19 5:54 PM, zgu at redhat.com wrote: > > It turns out to be a bug after it was split from JDK-8215047. > > Please see the bug for details. > > So, this failure is actually caught by assert, right? Yes. Got one from post checkin Mach 5 test. > > > I changed bug synopsis to "Missing termination check results > > violation > > of termination invariant" and updated Prirority to P2. > > > > Could I get a second reivew ASAP, so it can unbreak the mainline. > > You have it now. > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217794 > > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217794/webrev.00/ > > Looks good. Thanks! -Zhengyu > > -Aleksey > > > > From igor.ignatyev at oracle.com Tue Jan 29 18:07:54 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 29 Jan 2019 10:07:54 -0800 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: <6e72908f-f5d9-6778-f405-56ebaabf2686@oracle.com> References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> <5DF3743E-DDB5-459C-AC50-D6E9F744B124@oracle.com> <6e72908f-f5d9-6778-f405-56ebaabf2686@oracle.com> Message-ID: <7FDE51DD-FEC2-402F-B970-8B5C93D15637@oracle.com> Sangheon, another nit: env. variables usually use 1 or just any value to indicate that something is enabled, however I also saw people using YES/NO or TRUE/FALSE, so you can leave it is. -- Igor > On Jan 29, 2019, at 1:15 AM, Leo Korinth wrote: > > Still looks good. > > Thanks, > Leo > > On 29/01/2019 06:08, sangheon.kim at oracle.com wrote: >> Hi Igor, >> On 1/28/19 6:32 PM, Igor Ignatyev wrote: >>> Hi Sangheon, >>> >>> the code looks good to me. >> Thank you for your review! >> Forgot to mention, thank you for providing the idea of using @requires as well. >>> >>> joining bikeshedding around the property name, I'd recommend not to use 'vm.' at all, as it was intended to mean "VM under test can/have/...", so I'd go w/ something like 'test.vm.nvdimm' or 'test.vm.gc.nvdimm'. if you really want you can have ".enabled" prefix, but in this case, it seems to be redundant. >> I changed to 'test.vm.gc.nvdimm'. >> http://cr.openjdk.java.net/~sangheki/8217666/webrev.1/ >> (as I feel incremental webrev doesn't help, didn't generated) >> Thanks, >> Sangheon >>> >>> -- Igor >>> >>>> On Jan 28, 2019, at 11:31 AM, Leo Korinth >>>> wrote: >>>> >>>> >>>> >>>> On 28/01/2019 20:09, sangheon.kim at oracle.com wrote: >>>>> Hi Leo, >>>>> Thank you for reviewing this. >>>>> On 1/28/19 2:25 AM, Leo Korinth wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> a few questions on the webrev: >>>>>> 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? >>>>> vm.nvdimm.test.enabled is added at the requires.properties list at TEST.ROOT and this is necessary for its work flow. >>>>> FYI, without that change, we will see 'Syntax error in @requires expression: invalid name: vm.nvdimm.test.enabled'. >>>> Thank you for the explanation. >>>> >>>>>> 2) most of the *Enabled() functions in VMProps.java read properties, but here we read the environment, why is that? >>>>> I think the env. variable approach seems clearer to use considering those tests will be tested on limited situations. >>>>> JTREG and VM which runs requires.VMProps will be affected. >>>>> JTREG doesn't propagate env variables to JDK under test unless they are specified via -e flag. >>>>> I considered adding a property as well, but I ended up with the environment variable. >>>> Okay, I just wanted to know that it was not by accident. >>>> >>>>>> 3) maybe the property should be "vm.gc" prefixed instead of "vm" prefixed, maybe not. What do you think? >>>>> I'm okay with 'vm.gc' prefix. >>>>> 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) > Let me post the updated webrev after getting more comments. >>>> I am fine with either. Your change looks good to me, and thanks a lot for fixing this problem. Keep in mind that I am just a commiter. >>>> >>>> Thanks, >>>> Leo >>>>> Thanks, >>>>> Sangheon >>>>>> Thanks for disabling these test cases! >>>>>> /Leo >>>>>> >>>>>> On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Can I have reviews that excludes gc/nvdimm jtreg tests? >>>>>>> >>>>>>> Those tests were introduced by JDK-8202286 (Allocation of old generation of Java heap on alternate memory devices) and tried to exclude all tests from all tiers. But it was incomplete so one of the tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java failure) was filed recently. >>>>>>> >>>>>>> The patch includes to exclude gc/nvdimm from TEST.groups, hotspot_misc group(which is the reason why JDK-8217406 occurred). In addition, added @requires to gc/nvdimm tests to avoid running the tests. >>>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >>>>>>> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon From coleen.phillimore at oracle.com Tue Jan 29 18:12:08 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Jan 2019 13:12:08 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> Message-ID: <5a9a5170-f5d5-f337-865c-6ae1c2e99241@oracle.com> On 1/29/19 4:51 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-01-28 at 16:46 -0500, coleen.phillimore at oracle.com wrote: >> Hi Thomas, Can you forward the review thread for JDK-8213229? > the thread starts at > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024474.html > , but the interesting part is probably starting here > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024649.html > . So this moves StringTable processing into the WeakProcessor.? good! Not a review though. http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.inline.hpp.frames.html If these Counting closures are only used in the weakProcessor.cpp file, they should be defined there.? It looks like their use was moved. http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.cpp.frames.html I don't know what "is_serial does but it doesn't look like you're using the num_dead() count when calling processor. 40 if (WeakProcessorPhases::is_serial(phase)) { 41 CountingIsAliveClosure cl(is_alive); 42 WeakProcessorPhases::processor(phase)(&cl, keep_alive); 43 } else { 44 CountingSkippedIsAliveClosure cl(is_alive, keep_alive); 45 WeakProcessorPhases::oop_storage(phase)->oops_do(&cl); 46 if (WeakProcessorPhases::is_stringtable(phase)) { 47 StringTable::inc_dead_counter(cl.num_dead() + cl.num_skipped()); 48 } 49 } Thanks, Coleen >> I wonder if we could just trigger_unloading after any GC has run and >> ignore dead string counts. Are they ever zero? > That seems to be a waste of cpu cycles assuming that interned strings > typically have a "long" lifetime. Since the VM has to intern any strings in the JVM_CONSTANT_String in the classfile, class unloading probably should trigger_unloading unconditionally if any classes are unloaded.? It seems very likely there would be unreferenced strings. But we may need the ServiceThread to unlink reclaimed entries even if classes aren't unloaded, which may be infrequent but there may have been stressful applications that have required it in the past. Can you log if the count is ever too low to process the StringTable? The change for this looks reasonable, but not a full review.? I kind of like keeping the concept of weak_oops_do() because it's a well known idiom but as Kim says, it's not necessary to call weak_oops_do on something that contains weak oops. CR: https://bugs.openjdk.java.net/browse/JDK-8217778 Webrev: http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ Thanks, Coleen > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Jan 29 18:22:50 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Jan 2019 13:22:50 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Message-ID: <00150fef-35af-b5fc-dd8e-ae7c305fd928@oracle.com> On 1/28/19 11:02 PM, Kim Barrett wrote: >> On Jan 28, 2019, at 4:46 PM, coleen.phillimore at oracle.com wrote: >> >> >> Hi Thomas, Can you forward the review thread for JDK-8213229? >> >> I wonder if we could just trigger_unloading after any GC has run and ignore dead string counts. Are they ever zero? > We?re trying to only trigger the ServiceThread?s StringTable cleanup when there > are enough nulled-out entries to make it worth the effort. My guess would be that > interned strings rarely die young. In which case that approach would probably > trigger the ServiceThread unnecessarily frequently. Maybe instead avoid the > counting and unconditionally trigger after a (possibly concurrent) full collection? > That doesn?t do so well for the (possibly rare?) application that does frequently > intern and then drop strings though. Or don?t trigger the ServiceThread more > often than some (perhaps configurable? Ugh! A new CLOption) frequency. I definitely don't want another command line option, but triggering after a collection that might do class unloading makes sense.? But yeah, some cases might have lots of interned strings outside of class loading.? I thought that the stringTable insert code noted dead entries on the way, but that's only used by the symbolTable. > > Also, I wonder if the SymbolTable has the same miscalculation. The SymbolTable > code was somewhat cribbed from StringTable, after all. > Yes, the SymbolTable code was similar but the Symbols are 90-99% brought in by class loading, so triggering during unloading unconditionally make sense there.?? And even when we counted, if there was 1 Symbol free, we'd clean the table.? It's concurrent, and hasn't been seen to cause undo slowdown on the applications we've benchmarked, so this is good. See:? 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread I should split this RFE because this also moves SymbolTable cleaning to only trigger during unloading. Coleen From sangheon.kim at oracle.com Tue Jan 29 18:37:59 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Tue, 29 Jan 2019 10:37:59 -0800 Subject: RFR (S)[12]: 8217666: gc/nvdimm/* should not be included any tiers In-Reply-To: <7FDE51DD-FEC2-402F-B970-8B5C93D15637@oracle.com> References: <20e98fe7-af49-5e4c-5778-6343e367066e@oracle.com> <0ea6fd6c-705a-e01e-4566-b4cd58a278ac@oracle.com> <66d3d560-dd10-8c2f-e6f6-7daa1c105660@oracle.com> <5DF3743E-DDB5-459C-AC50-D6E9F744B124@oracle.com> <6e72908f-f5d9-6778-f405-56ebaabf2686@oracle.com> <7FDE51DD-FEC2-402F-B970-8B5C93D15637@oracle.com> Message-ID: Hi Igor and Leo, Thanks for your review! On 1/29/19 10:07 AM, Igor Ignatyev wrote: > Sangheon, > > another nit: env. variables usually use 1 or just any value to indicate that something is enabled, however I also saw people using YES/NO or TRUE/FALSE, so you can leave it is. Okay, thanks for reminding me. Thanks, Sangheon > > -- Igor > >> On Jan 29, 2019, at 1:15 AM, Leo Korinth wrote: >> >> Still looks good. >> >> Thanks, >> Leo >> >> On 29/01/2019 06:08, sangheon.kim at oracle.com wrote: >>> Hi Igor, >>> On 1/28/19 6:32 PM, Igor Ignatyev wrote: >>>> Hi Sangheon, >>>> >>>> the code looks good to me. >>> Thank you for your review! >>> Forgot to mention, thank you for providing the idea of using @requires as well. >>>> joining bikeshedding around the property name, I'd recommend not to use 'vm.' at all, as it was intended to mean "VM under test can/have/...", so I'd go w/ something like 'test.vm.nvdimm' or 'test.vm.gc.nvdimm'. if you really want you can have ".enabled" prefix, but in this case, it seems to be redundant. >>> I changed to 'test.vm.gc.nvdimm'. >>> http://cr.openjdk.java.net/~sangheki/8217666/webrev.1/ >>> (as I feel incremental webrev doesn't help, didn't generated) >>> Thanks, >>> Sangheon >>>> -- Igor >>>> >>>>> On Jan 28, 2019, at 11:31 AM, Leo Korinth >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 28/01/2019 20:09, sangheon.kim at oracle.com wrote: >>>>>> Hi Leo, >>>>>> Thank you for reviewing this. >>>>>> On 1/28/19 2:25 AM, Leo Korinth wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> a few questions on the webrev: >>>>>>> 1) what does the added vm.nvdimm.test.enabled line in TEST.ROOT do? >>>>>> vm.nvdimm.test.enabled is added at the requires.properties list at TEST.ROOT and this is necessary for its work flow. >>>>>> FYI, without that change, we will see 'Syntax error in @requires expression: invalid name: vm.nvdimm.test.enabled'. >>>>> Thank you for the explanation. >>>>> >>>>>>> 2) most of the *Enabled() functions in VMProps.java read properties, but here we read the environment, why is that? >>>>>> I think the env. variable approach seems clearer to use considering those tests will be tested on limited situations. >>>>>> JTREG and VM which runs requires.VMProps will be affected. >>>>>> JTREG doesn't propagate env variables to JDK under test unless they are specified via -e flag. >>>>>> I considered adding a property as well, but I ended up with the environment variable. >>>>> Okay, I just wanted to know that it was not by accident. >>>>> >>>>>>> 3) maybe the property should be "vm.gc" prefixed instead of "vm" prefixed, maybe not. What do you think? >>>>>> I'm okay with 'vm.gc' prefix. >>>>>> 'vm.gc.nvdimm.test.enabled' unless others dislike it. :) > Let me post the updated webrev after getting more comments. >>>>> I am fine with either. Your change looks good to me, and thanks a lot for fixing this problem. Keep in mind that I am just a commiter. >>>>> >>>>> Thanks, >>>>> Leo >>>>>> Thanks, >>>>>> Sangheon >>>>>>> Thanks for disabling these test cases! >>>>>>> /Leo >>>>>>> >>>>>>> On 26/01/2019 16:35, sangheon.kim at oracle.com wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Can I have reviews that excludes gc/nvdimm jtreg tests? >>>>>>>> >>>>>>>> Those tests were introduced by JDK-8202286 (Allocation of old generation of Java heap on alternate memory devices) and tried to exclude all tests from all tiers. But it was incomplete so one of the tests failed and JDK-8217406 (gc/nvdimm/TestOldObjectsOnNvdimm.java failure) was filed recently. >>>>>>>> >>>>>>>> The patch includes to exclude gc/nvdimm from TEST.groups, hotspot_misc group(which is the reason why JDK-8217406 occurred). In addition, added @requires to gc/nvdimm tests to avoid running the tests. >>>>>>>> >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8217666 >>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8217666/webrev.0/ >>>>>>>> Testing: manual tests w/, w/o VM_NVDIMM_TEST environmental variable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon From thomas.schatzl at oracle.com Tue Jan 29 18:37:21 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 29 Jan 2019 19:37:21 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <5a9a5170-f5d5-f337-865c-6ae1c2e99241@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> <5a9a5170-f5d5-f337-865c-6ae1c2e99241@oracle.com> Message-ID: <7783a75b6d4b187e066e2b0838abf46366015f6a.camel@oracle.com> Hi, On Tue, 2019-01-29 at 13:12 -0500, coleen.phillimore at oracle.com wrote: > > > On 1/29/19 4:51 AM, Thomas Schatzl wrote: > > Hi, > > > > On Mon, 2019-01-28 at 16:46 -0500, coleen.phillimore at oracle.com > > wrote: > > > Hi Thomas, Can you forward the review thread for JDK-8213229? > > > > the thread starts at > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024474.html > > , but the interesting part is probably starting here > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024649.html > > . > > So this moves StringTable processing into the WeakProcessor. good! > Not a review though. > > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.inline.hpp.frames.html > > If these Counting closures are only used in the weakProcessor.cpp > file, they should be defined there. It looks like their use was > moved. They are also used in the inline.hpp file. > > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.cpp.frames.html > > I don't know what "is_serial does but it doesn't look like you're > using the num_dead() count when calling processor. > > 40 if (WeakProcessorPhases::is_serial(phase)) { > 41 CountingIsAliveClosure cl(is_alive); > 42 WeakProcessorPhases::processor(phase)(&cl, keep_alive); > 43 } else { > 44 CountingSkippedIsAliveClosure OopClosure> cl(is_alive, keep_alive); > 45 WeakProcessorPhases::oop_storage(phase)->oops_do(&cl); > 46 if (WeakProcessorPhases::is_stringtable(phase)) { > 47 StringTable::inc_dead_counter(cl.num_dead() + > cl.num_skipped()); > 48 } > 49 } I cleaned this up already, Kim had the same comment. Only need to send out another webrev for 8217778. Thanks, Thomas From zgu at redhat.com Tue Jan 29 20:56:52 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 29 Jan 2019 15:56:52 -0500 Subject: FRF(S) 8216072: Remove TaskTerminator's assignment operator Message-ID: <1548795412.31327.93.camel@redhat.com> The assignment operator was a workaround for issues since resolved by JDK-8215047, JDK-8215299 and JDK-8215220. It is time to remove it and use ParallelTaskTerminator::reset_for_reuse() instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8216072 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216072/webrev.00/index.htm l Test: hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug and release) Thanks, -Zhengyu From thomas.schatzl at oracle.com Wed Jan 30 09:57:05 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 30 Jan 2019 10:57:05 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> Message-ID: <3c8788099fdda94a32e91153a44ace8e8f29f2c6.camel@oracle.com> Hi Kim and Coleen, On Mon, 2019-01-28 at 22:24 -0500, Kim Barrett wrote: > On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for this change that tries to fix the issue > > with the string table reporting too low "dead" numbers to the > > ServiceThread notification mechanism in the review for JDK-8213229, > > potentially causing C heap memory being kept live for longer than > > necessary? > > > > This change implements one option for fixing this, in particular > > that the WeakProcessor calls OopStorage::oops_do() instead of > > ::weak_oops_do, counting the number of NULL entries manually. > > I think this is the right approach to take. > Good. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8217778 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ > > Testing: > > hs-tier1-5 > > > > Thanks, > > Thomas > > Looks good. > > A couple minor cleanup suggestions. I don't need another webrev if > you decide to do these. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.cpp > 41 CountingIsAliveClosure cl(is_alive); > > Why are we counting here? We don't do anything with the resulting > count. (I missed this when reviewing JDK-8213229.) Fixed. > > Similarly here, when !is_stringtable(phase): > 44 CountingSkippedIsAliveClosure OopClosure> cl(is_alive, keep_alive); > > There could instead be a separate is_stringtable(phase) clause which > had the calls to StringTable::(reset|finish)_dead_counter() and the > counting closure stuff all close together and associated only with > the stringtable storage iteration. Done. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.inline.hpp > 74 if (obj == NULL) { > 75 _num_skipped++; > 76 return; > 77 } > 78 if (_counting_is_alive.do_object_b(obj)) { > 79 _keep_alive->do_oop(p); > 80 } else { > 81 *p = NULL; > 82 } > > This would be simpler if the line 76 "return" were removed and the > line 78 "if" were an "else if", having a single if-ladder. Done. > > ------------------------------------------------------------------- > ----------- (from the other email) > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.cpp > 44 CountingSkippedIsAliveClosure OopClosure> cl(is_alive, keep_alive); > > A different approach is possible in this serial case. We could wrap > the keep_alive closure for counting, as the number we want to pass to > inc_dead_counter is also available here as > > storage->allocation_count() - > > ------------------------------------------------------------------- > I did not implement that. It seems to look too different from the parallel case with no difference in actual work done. And we need the CountingSkipped.. closure anyway for the parallel case. New webrevs: http://cr.openjdk.java.net/~tschatzl/8217778/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8217778/webrev.1 (full) Thanks, Thomas From thomas.schatzl at oracle.com Wed Jan 30 11:04:17 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 30 Jan 2019 12:04:17 +0100 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> Message-ID: <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> Hi Yasumasa, On Tue, 2019-01-29 at 21:39 +0900, Yasumasa Suenaga wrote: > Thank you for your comment. > I uploaded new webrev (it passed all tests on submit repo): > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.01/ > > I write reply based on it as below. internal testing shows no issues with the patch. > On 2019/01/28 22:55, Thomas Schatzl wrote: > > Hi Yasumasa, > > > > On Fri, 2019-01-25 at 11:35 +0900, Yasumasa Suenaga wrote: > > > PING: Could you review this? > > > > > > > > > Yasumasa > > > > > > > > > On 2019/01/21 17:52, Yasumasa Suenaga wrote: > > > > Hi all, > > > > > > > > I filed this issue to JBS: > > > > https://bugs.openjdk.java.net/browse/JDK-8217432 > > > > > > > > I investigated it, and I found that `minimum_desired_capacity` > > > > and `maximum_desired_capacity` in > > > > `MetaspaceGC::compute_new_size()` > > > > might exceed MaxMetaspaceSize. > > > > They shouldn't exceed MaxMetaspaceSize. > > > > > > > > I uploaded webrev for this bug. Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ > > > > > > > > This change has passed all tests on submit repo, > > > > :vmTestbase_vm_metaspace, > > > > and :vmTestbase_nsk_sysdict jtreg tests. > > > > The suggested change does not work - you can't return false from > > MetaspaceGC::inc_capacity_until_gc() because the return value > > indicates whether it was possible to change the value, not whether > > the value passed sense. > > > > The code before that must make sure that the resulting value is > > within limits (that could be a good assert in > > inc_capacity_until_GC()) from my understanding, without being an > > expert here. > > > > So with the current change, the assert in metaspace.cpp:260 would > > simply fire in this case. > > I added assert() to inc_capacity_until_GC() because > _capacity_until_GC shouldn't exceed MaxMetaspaceSize. > This function will not return false when _capacity_until_GC attempt > to be exceeded MaxMetaspaceSize. > > > > Making sure that the HWM does not go over MaxMetaspaceSize could be > > achieved by limiting expand_bytes passed to the method; I *think*, > > without following where minimum_desired_capacity is also used in > > that method, clamping it via > > > > 241: minimum_desired_capacity = > > MIN2(MAX2(minimum_desired_capacity, > > MetaspaceSize), MaxMetaspaceSize); > > > > would achieve the desired effect. > > Your suggestion seems to be equivalent to my change. Okay :) > ------------- > const double min_tmp = used_after_gc / maximum_used_percentage; > size_t minimum_desired_capacity = > - (size_t)MIN2(min_tmp, double(max_uintx)); > + (size_t)MIN2(min_tmp, double(MaxMetaspaceSize)); > // Don't shrink less than the initial generation size > minimum_desired_capacity = MAX2(minimum_desired_capacity, > MetaspaceSize); > ------------- > > I don't understand why current implementation use `max_uintx` at > this. > I guess it means "max value of Metaspace", so I think it should use > MaxMetaspaceSize rather than max_uintx. I agree. > > Could you also provide a test case for this change (i.e. failing > > before, good after) as Aleksey suggested? > > It is hard to reproduce this problem because this issue is caused by > C++ member variable (MetaspaceGC::_capacity_until_GC). > > It can be tested with WhiteBox test (incMetaspaceCapacityUntilGC()), > however it tests inc_capacity_until_GC() call only. > > OTOH we might test as Aleksey said, but we can't estimate precise > commit memory size of Metaspace, and evaluate why OOME is occurred. > (memory consumption or invalid _capacity_until_GC) > > As I said before, I added assert() to inc_capacity_until_GC(). > It will fail without other change in this webrev. So I think we can > evaluate it via > vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java . Okay, I guess that's enough. Please add a @bugid with this CR number to the test then. > > Note that my suggestion only fixes the call to > > inc_capacity_until_gc() in MetaspaceGC::compute_new_size(). I very > > much believe it is required to add another guard in > > ClassLoaderMetaspace::expand_and_allocate(). > > > > (Please add the assert in inc_capacity_until_gc() I mentioned > > above!). > > I added the code to check total amount of _capacity_until_GC > before inc_capacity_until_GC() call. > But I concern the check and increment are not atomically. Is it okay? If the check were located after the Atomic::cmpxchg() and after the check whether it had been this thread to change the value it would be fine :) Please add a comment like "Check after the increment that we did not go over the maximum. We can not do this earlier due to potential races" before it to explain its location. Thanks, Thomas From thomas.schatzl at oracle.com Wed Jan 30 12:27:40 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 30 Jan 2019 13:27:40 +0100 Subject: RFR (S) 8216072: Remove TaskTerminator's assignment operator In-Reply-To: <1548795412.31327.93.camel@redhat.com> References: <1548795412.31327.93.camel@redhat.com> Message-ID: Hi, On Tue, 2019-01-29 at 15:56 -0500, zgu at redhat.com wrote: > The assignment operator was a workaround for issues since resolved by > JDK-8215047, JDK-8215299 and JDK-8215220. It is time to remove it and > use ParallelTaskTerminator::reset_for_reuse() instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216072 > Webrev: > http://cr.openjdk.java.net/~zgu/JDK-8216072/webrev.00/index.html looks good to me. Thanks for cleaning this up. > Test: > > hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug and > release) hs-tier1-5 passed. Thanks, Thomas From yasuenag at gmail.com Wed Jan 30 12:49:25 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Jan 2019 21:49:25 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> Message-ID: <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> Hi Thomas, >> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.01/ >> >> I write reply based on it as below. > > internal testing shows no issues with the patch. Thanks! >> As I said before, I added assert() to inc_capacity_until_GC(). >> It will fail without other change in this webrev. So I think we can >> evaluate it via >> vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java . > > Okay, I guess that's enough. Please add a @bugid with this CR number to > the test then. I will add it. >> I added the code to check total amount of _capacity_until_GC >> before inc_capacity_until_GC() call. >> But I concern the check and increment are not atomically. Is it okay? > > If the check were located after the Atomic::cmpxchg() and after the > check whether it had been this thread to change the value it would be > fine :) Do you suggest as following code? ------------------ @@ -1478,6 +1482,12 @@ // have incremented the HWM and therefore the allocation might still succeed. do { incremented = MetaspaceGC::inc_capacity_until_GC(delta_bytes, &after, &before); + // Check after the increment that we did not go over the maximum. + // We can not do this earlier due to potential races. + if (!incremented && (after > MaxMetaspaceSize)) { + MetaspaceGC::dec_capacity_until_GC(delta_bytes); + return false; + } res = allocate(word_size, mdtype); } while (!incremented && res == NULL); ------------------ If so, assert() in inc_capacity_until_GC() might be failed because _capacity_until_GC + delta_bytes might exceed MaxMetaspaceSize. If we can change arguments of inc_capacity_until_GC(), we can pass expected value to it (_capacity_until_GC + delta_bytes). If so, we can compliant MaxMetaspaceSize via cmpxchg. Thanks, Yasumasa On 2019/01/30 20:04, Thomas Schatzl wrote: > Hi Yasumasa, > > On Tue, 2019-01-29 at 21:39 +0900, Yasumasa Suenaga wrote: >> Thank you for your comment. >> I uploaded new webrev (it passed all tests on submit repo): >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.01/ >> >> I write reply based on it as below. > > internal testing shows no issues with the patch. > >> On 2019/01/28 22:55, Thomas Schatzl wrote: >>> Hi Yasumasa, >>> >>> On Fri, 2019-01-25 at 11:35 +0900, Yasumasa Suenaga wrote: >>>> PING: Could you review this? >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/01/21 17:52, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I filed this issue to JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8217432 >>>>> >>>>> I investigated it, and I found that `minimum_desired_capacity` >>>>> and `maximum_desired_capacity` in >>>>> `MetaspaceGC::compute_new_size()` >>>>> might exceed MaxMetaspaceSize. >>>>> They shouldn't exceed MaxMetaspaceSize. >>>>> >>>>> I uploaded webrev for this bug. Could you review it? >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/ >>>>> >>>>> This change has passed all tests on submit repo, >>>>> :vmTestbase_vm_metaspace, >>>>> and :vmTestbase_nsk_sysdict jtreg tests. >>> >>> The suggested change does not work - you can't return false from >>> MetaspaceGC::inc_capacity_until_gc() because the return value >>> indicates whether it was possible to change the value, not whether >>> the value passed sense. >>> >>> The code before that must make sure that the resulting value is >>> within limits (that could be a good assert in >>> inc_capacity_until_GC()) from my understanding, without being an >>> expert here. >>> >>> So with the current change, the assert in metaspace.cpp:260 would >>> simply fire in this case. >> >> I added assert() to inc_capacity_until_GC() because >> _capacity_until_GC shouldn't exceed MaxMetaspaceSize. >> This function will not return false when _capacity_until_GC attempt >> to be exceeded MaxMetaspaceSize. >> >> >>> Making sure that the HWM does not go over MaxMetaspaceSize could be >>> achieved by limiting expand_bytes passed to the method; I *think*, >>> without following where minimum_desired_capacity is also used in >>> that method, clamping it via >>> >>> 241: minimum_desired_capacity = >>> MIN2(MAX2(minimum_desired_capacity, >>> MetaspaceSize), MaxMetaspaceSize); >>> >>> would achieve the desired effect. >> >> Your suggestion seems to be equivalent to my change. > > Okay :) > >> ------------- >> const double min_tmp = used_after_gc / maximum_used_percentage; >> size_t minimum_desired_capacity = >> - (size_t)MIN2(min_tmp, double(max_uintx)); >> + (size_t)MIN2(min_tmp, double(MaxMetaspaceSize)); >> // Don't shrink less than the initial generation size >> minimum_desired_capacity = MAX2(minimum_desired_capacity, >> MetaspaceSize); >> ------------- >> >> I don't understand why current implementation use `max_uintx` at >> this. >> I guess it means "max value of Metaspace", so I think it should use >> MaxMetaspaceSize rather than max_uintx. > > I agree. > >>> Could you also provide a test case for this change (i.e. failing >>> before, good after) as Aleksey suggested? >> >> It is hard to reproduce this problem because this issue is caused by >> C++ member variable (MetaspaceGC::_capacity_until_GC). >> >> It can be tested with WhiteBox test (incMetaspaceCapacityUntilGC()), >> however it tests inc_capacity_until_GC() call only. >> >> OTOH we might test as Aleksey said, but we can't estimate precise >> commit memory size of Metaspace, and evaluate why OOME is occurred. >> (memory consumption or invalid _capacity_until_GC) >> >> As I said before, I added assert() to inc_capacity_until_GC(). >> It will fail without other change in this webrev. So I think we can >> evaluate it via >> vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java . > > Okay, I guess that's enough. Please add a @bugid with this CR number to > the test then. > >>> Note that my suggestion only fixes the call to >>> inc_capacity_until_gc() in MetaspaceGC::compute_new_size(). I very >>> much believe it is required to add another guard in >>> ClassLoaderMetaspace::expand_and_allocate(). >>> >>> (Please add the assert in inc_capacity_until_gc() I mentioned >>> above!). >> >> I added the code to check total amount of _capacity_until_GC >> before inc_capacity_until_GC() call. >> But I concern the check and increment are not atomically. Is it okay? > > If the check were located after the Atomic::cmpxchg() and after the > check whether it had been this thread to change the value it would be > fine :) > > Please add a comment like "Check after the increment that we did not go > over the maximum. We can not do this earlier due to potential races" > before it to explain its location. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Wed Jan 30 12:55:52 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 30 Jan 2019 13:55:52 +0100 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> Message-ID: <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> On Wed, 2019-01-30 at 21:49 +0900, Yasumasa Suenaga wrote: > Hi Thomas, > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.01/ > > > > > > I write reply based on it as below. > > > > I added the code to check total amount of _capacity_until_GC > > > before inc_capacity_until_GC() call. > > > But I concern the check and increment are not atomically. Is it > > > okay? > > > > If the check were located after the Atomic::cmpxchg() and after the > > check whether it had been this thread to change the value it would > > be > > fine :) > > Do you suggest as following code? No, in MetaspaceGC::inc_capacity_until_GC() after the cmpxchg and the check whether this thread has been the one incrementing the watermark. I.e. " size_t prev_value = Atomic::cmpxchg(new_value, ...); if (old_capacity_until_gc != prev_value) { return false; // Somebody else incremented the counter } assert(new_value <= MaxMetaspaceSize, "... " At that point in execution we are sure this thread set "new_value" to a new value, that should obviously not exceed MaxMetaspaceSize. Please use a meaningful assert text containing the increment, new value and threshold. Thanks, Thomas From yasuenag at gmail.com Wed Jan 30 13:16:36 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Jan 2019 22:16:36 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> Message-ID: <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> Thanks Thomas! I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.02/ But I guess we can remove the following change: -------------- @@ -1477,6 +1483,9 @@ // the HWM, an allocation is still attempted. This is because another thread must then // have incremented the HWM and therefore the allocation might still succeed. do { + if (MetaspaceGC::capacity_until_GC() + delta_bytes > MaxMetaspaceSize) { + return NULL; + } incremented = MetaspaceGC::inc_capacity_until_GC(delta_bytes, &after, &before); res = allocate(word_size, mdtype); } while (!incremented && res == NULL); -------------- OTOH inc_capacity_until_GC() shouldn't be passed the value which exceeds MaxMetaspaceSize. Should we keep this change? Thanks, Yasumasa On 2019/01/30 21:55, Thomas Schatzl wrote: > On Wed, 2019-01-30 at 21:49 +0900, Yasumasa Suenaga wrote: >> Hi Thomas, >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.01/ >>>> >>>> I write reply based on it as below. >> >>>> I added the code to check total amount of _capacity_until_GC >>>> before inc_capacity_until_GC() call. >>>> But I concern the check and increment are not atomically. Is it >>>> okay? >>> >>> If the check were located after the Atomic::cmpxchg() and after the >>> check whether it had been this thread to change the value it would >>> be >>> fine :) >> >> Do you suggest as following code? > > No, in MetaspaceGC::inc_capacity_until_GC() after the cmpxchg and the > check whether this thread has been the one incrementing the watermark. > > I.e. " > > size_t prev_value = Atomic::cmpxchg(new_value, ...); > > if (old_capacity_until_gc != prev_value) { > return false; // Somebody else incremented the counter > } > > assert(new_value <= MaxMetaspaceSize, "... > > " > > At that point in execution we are sure this thread set "new_value" to a > new value, that should obviously not exceed MaxMetaspaceSize. > > Please use a meaningful assert text containing the increment, new value > and threshold. > > Thanks, > Thomas > > From zgu at redhat.com Wed Jan 30 13:22:20 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 30 Jan 2019 08:22:20 -0500 Subject: RFR (S) 8216072: Remove TaskTerminator's assignment operator In-Reply-To: References: <1548795412.31327.93.camel@redhat.com> Message-ID: <1548854540.31327.94.camel@redhat.com> Hi Thomas, Thanks for reviewing and testing. -Zhengyu On Wed, 2019-01-30 at 13:27 +0100, Thomas Schatzl wrote: > Hi, > > On Tue, 2019-01-29 at 15:56 -0500, zgu at redhat.com wrote: > > The assignment operator was a workaround for issues since resolved > > by > > JDK-8215047, JDK-8215299 and JDK-8215220. It is time to remove it > > and > > use ParallelTaskTerminator::reset_for_reuse() instead. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216072 > > Webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8216072/webrev.00/index.html > > looks good to me. Thanks for cleaning this up. > > > Test: > > > > hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug and > > release) > > hs-tier1-5 passed. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Wed Jan 30 14:55:53 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 30 Jan 2019 15:55:53 +0100 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> Message-ID: <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> Hi, On Wed, 2019-01-30 at 22:16 +0900, Yasumasa Suenaga wrote: > Thanks Thomas! > > I uploaded new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.02/ > > But I guess we can remove the following change: > > -------------- > @@ -1477,6 +1483,9 @@ > // the HWM, an allocation is still attempted. This is because > another thread must then > // have incremented the HWM and therefore the allocation might > still succeed. > do { > + if (MetaspaceGC::capacity_until_GC() + delta_bytes > > MaxMetaspaceSize) { > + return NULL; > + } > incremented = MetaspaceGC::inc_capacity_until_GC(delta_bytes, > &after, &before); > res = allocate(word_size, mdtype); > } while (!incremented && res == NULL); > -------------- > > OTOH inc_capacity_until_GC() shouldn't be passed the value which > exceeds MaxMetaspaceSize. > Should we keep this change? Actually this code (either my suggestion or yours) does not work either - if we read capacity_until_GC() here and do the check, in the re-read in inc_capacity_until_gc() to calculate the new value may be different (may have been updated in the meantime). I was not looking at the loop in detail which is broken as well, assuming like other code we just fixed that allocation is always possible. One option would be to have inc_capacity_until_gc() return an additional bool value whether MaxMetaspaceSize has already been exceeded (i.e. there is a chance that any further attempt is successful), and exit this this loop if not so. This is different to the initial approach where the method returned false as result because the code can fail to set a new value due to races anyway, but still be able to retry. Another option would be to have inc_capacity_until_gc() return true to fake a successful increment if MaxMetaSpaceSize had already been reached. This is a bit sneaky though so I would prefer the former option. What do you think? Thanks, Thomas From shade at redhat.com Wed Jan 30 15:40:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 30 Jan 2019 16:40:29 +0100 Subject: RFR (XS) 8215221: Serial GC misreports young GC time In-Reply-To: References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> Message-ID: <6531a332-af3e-fdc4-7b9a-1f2e7cedc73a@redhat.com> On 1/24/19 4:37 PM, Aleksey Shipilev wrote: > Okay, another attempt. This restructures the code a little bit, which IMO makes the flow more > understandable. It also eliminates a few flags. Then, the placement for GCTraceTime becomes natural. > Well, almost, because it requires some dance around should_do_full_collection, if we want to include > young-only epilog into timing. > > See: > http://cr.openjdk.java.net/~shade/8215221/webrev.02/ > > This passes hotspot_tier1 and my ad-hoc tests. If this is the way to go, I would do jdk-submit, etc. > then. The webrev above passes jdk-submit. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Wed Jan 30 16:26:17 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 30 Jan 2019 17:26:17 +0100 Subject: FRF(S) 8216072: Remove TaskTerminator's assignment operator In-Reply-To: <1548795412.31327.93.camel@redhat.com> References: <1548795412.31327.93.camel@redhat.com> Message-ID: <79cc911b-7a6a-9acc-6271-575771be1f52@redhat.com> Looks good to me! Thanks, Roman > The assignment operator was a workaround for issues since resolved by > JDK-8215047, JDK-8215299 and JDK-8215220. It is time to remove it and > use ParallelTaskTerminator::reset_for_reuse() instead. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216072 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216072/webrev.00/index.htm > l > > > Test: > > hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug and > release) > > Thanks, > > -Zhengyu > From zgu at redhat.com Wed Jan 30 16:37:30 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 30 Jan 2019 11:37:30 -0500 Subject: FRF(S) 8216072: Remove TaskTerminator's assignment operator In-Reply-To: <79cc911b-7a6a-9acc-6271-575771be1f52@redhat.com> References: <1548795412.31327.93.camel@redhat.com> <79cc911b-7a6a-9acc-6271-575771be1f52@redhat.com> Message-ID: <1548866250.31327.112.camel@redhat.com> On Wed, 2019-01-30 at 17:26 +0100, Roman Kennke wrote: > Looks good to me! > Thanks, Roman. -Zhengyu > Thanks, > Roman > > > The assignment operator was a workaround for issues since resolved > > by > > JDK-8215047, JDK-8215299 and JDK-8215220. It is time to remove it > > and > > use ParallelTaskTerminator::reset_for_reuse() instead. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216072 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216072/webrev.00/index > > .htm > > l > > > > > > Test: > > > > hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug > > and > > release) > > > > Thanks, > > > > -Zhengyu > > From kim.barrett at oracle.com Wed Jan 30 19:59:36 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Jan 2019 14:59:36 -0500 Subject: FRF(S) 8216072: Remove TaskTerminator's assignment operator In-Reply-To: <1548795412.31327.93.camel@redhat.com> References: <1548795412.31327.93.camel@redhat.com> Message-ID: > On Jan 29, 2019, at 3:56 PM, zgu at redhat.com wrote: > > The assignment operator was a workaround for issues since resolved by > JDK-8215047, JDK-8215299 and JDK-8215220. It is time to remove it and > use ParallelTaskTerminator::reset_for_reuse() instead. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216072 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216072/webrev.00/index.htm > l > > > Test: > > hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug and > release) > > Thanks, > > -Zhengyu Looks good. From zgu at redhat.com Wed Jan 30 20:19:53 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 30 Jan 2019 15:19:53 -0500 Subject: FRF(S) 8216072: Remove TaskTerminator's assignment operator In-Reply-To: References: <1548795412.31327.93.camel@redhat.com> Message-ID: <1548879593.31327.130.camel@redhat.com> Thanks, Kim. -Zhengyu > > hotspot_gc (+/-UseOWSTTaskTerminator) on Linux x64 (fastdebug and > > release) > > > > Thanks, > > > > -Zhengyu > > Looks good. > From kim.barrett at oracle.com Wed Jan 30 22:16:41 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Jan 2019 17:16:41 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <3c8788099fdda94a32e91153a44ace8e8f29f2c6.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> <3c8788099fdda94a32e91153a44ace8e8f29f2c6.camel@oracle.com> Message-ID: > On Jan 30, 2019, at 4:57 AM, Thomas Schatzl wrote: > New webrevs: > http://cr.openjdk.java.net/~tschatzl/8217778/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8217778/webrev.1 (full) > > Thanks, > Thomas Looks good. From yasuenag at gmail.com Thu Jan 31 05:09:22 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Jan 2019 14:09:22 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> Message-ID: Hi Thomas, I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.03/ I agree with you that inc_capacity_until_GC() returns additional bool value whether new HWM is exceeded MaxMetaspaceSize. I added `can_retry` to argument of inc_capacity_until_GC(). It will be set to false if `new_value` exceeds MaxMetaspaceSize. Then inc_capacity_until_GC() returns false, but it is not break assert() in compute_new_size() because inc_capacity_until_GC() is called with `expand_bytes` which is limited by MaxMetaspaceSize. (It is ensured by this change) This change has passed vmTestbase/metaspace, gc/metaspace, and submit repo tests. Thanks, Yasumasa 2019?1?30?(?) 23:55 Thomas Schatzl : > > Hi, > > On Wed, 2019-01-30 at 22:16 +0900, Yasumasa Suenaga wrote: > > Thanks Thomas! > > > > I uploaded new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.02/ > > > > But I guess we can remove the following change: > > > > -------------- > > @@ -1477,6 +1483,9 @@ > > // the HWM, an allocation is still attempted. This is because > > another thread must then > > // have incremented the HWM and therefore the allocation might > > still succeed. > > do { > > + if (MetaspaceGC::capacity_until_GC() + delta_bytes > > > MaxMetaspaceSize) { > > + return NULL; > > + } > > incremented = MetaspaceGC::inc_capacity_until_GC(delta_bytes, > > &after, &before); > > res = allocate(word_size, mdtype); > > } while (!incremented && res == NULL); > > -------------- > > > > OTOH inc_capacity_until_GC() shouldn't be passed the value which > > exceeds MaxMetaspaceSize. > > Should we keep this change? > > Actually this code (either my suggestion or yours) does not work either > - if we read capacity_until_GC() here and do the check, in the re-read > in inc_capacity_until_gc() to calculate the new value may be different > (may have been updated in the meantime). > > I was not looking at the loop in detail which is broken as well, > assuming like other code we just fixed that allocation is always > possible. > > One option would be to have inc_capacity_until_gc() return an > additional bool value whether MaxMetaspaceSize has already been > exceeded (i.e. there is a chance that any further attempt is > successful), and exit this this loop if not so. > > This is different to the initial approach where the method returned > false as result because the code can fail to set a new value due to > races anyway, but still be able to retry. > > Another option would be to have inc_capacity_until_gc() return true to > fake a successful increment if MaxMetaSpaceSize had already been > reached. This is a bit sneaky though so I would prefer the former > option. What do you think? > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Thu Jan 31 09:16:08 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 31 Jan 2019 10:16:08 +0100 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> Message-ID: <45386bc559484f78ec07e16b63a51eb38240fe57.camel@oracle.com> Hi Yasumasa, On Thu, 2019-01-31 at 14:09 +0900, Yasumasa Suenaga wrote: > Hi Thomas, > > I uploaded new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.03/ > > I agree with you that inc_capacity_until_GC() returns additional > bool value whether new HWM is exceeded MaxMetaspaceSize. > > I added `can_retry` to argument of inc_capacity_until_GC(). > It will be set to false if `new_value` exceeds MaxMetaspaceSize. > Then inc_capacity_until_GC() returns false, but it is not break > assert() in compute_new_size() because inc_capacity_until_GC() > is called with `expand_bytes` which is limited by MaxMetaspaceSize. > (It is ensured by this change) > > This change has passed vmTestbase/metaspace, gc/metaspace, and > submit repo tests. looks good to me. Can you add some documentation to the declaration of inc_capacity_until_GC() like: // Try to increase metaspace size by v bytes. Returns true if // succeeded, false if not due to competing threads trying. // Optionally returns new and old metaspace capacity in // new_cap_until_GC and old_cap_until_GC respectively. // Optionally sets can_retry to indicate whether if there is actually // enough space remaining to satisfy the request. No need for a re-review for that (or something similar potentially better worded description. Thanks, Thomas From chihiro.ito at oracle.com Thu Jan 31 13:13:04 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Thu, 31 Jan 2019 22:13:04 +0900 Subject: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> Message-ID: <9c46c1ca-5723-2306-647c-3d3dcea2ee38@oracle.com> Hi Thomas and Per, I renamed counter names as follows referencing jstat. Could you review these? -XX:+UseSerialGC sun.gc.collector.0.name="Serial young collection pauses" sun.gc.collector.1.name="Serial full collection pauses" -XX:+UseParallelGC sun.gc.collector.0.name="Parallel young collection pauses" sun.gc.collector.1.name="Parallel full collection pauses" -XX:+UseParallelGC -XX:-UseParallelOldGC sun.gc.collector.0.name="Parallel young collection pauses" sun.gc.collector.1.name="Serial full collection pauses" -XX:+UseConcMarkSweepGC sun.gc.collector.0.name="CMS young collection pauses" sun.gc.collector.1.name="CMS full collection pauses" sun.gc.collector.2.name="CMS concurrent cycle pauses" -XX:+UseG1GC sun.gc.collector.0.name="G1 young collection pauses" sun.gc.collector.1.name="G1 full collection pauses" sun.gc.collector.2.name="G1 concurrent cycle pauses" -XX:+UnlockExperimentalVMOptions -XX:+UseZGC sun.gc.collector.2.name="Z concurrent cycle pauses" I uploaded webrev. I already have run the changes through test-tier1 test sets and saw no sign of regression. webrev: http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.02/ JBS: https://bugs.openjdk.java.net/browse/JDK-8214236 Regards, Chihiro On 2019/01/16 23:49, Chihiro Ito wrote: > Hi Thomas, > > I try to rename for all collections. > > Regards, > Chihiro > > On 2019/01/16 22:41, Thomas Schatzl wrote: >> Hi Chihiro, >> >> On Wed, 2019-01-16 at 00:30 +0900, Chihiro Ito wrote: >>> Hi Thomas and Per, >>> >>> I fixed counter name in G1, CMS and Z. >>> Could you review it ? >>> >>> http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ >>> >>> >>> For your information, output of PerfCounter.print is following. >>> >>> G1GC: >>> sun.gc.collector.0.name="G1 incremental collection pauses" >>> sun.gc.collector.1.name="G1 full collection pauses" >>> sun.gc.collector.2.name="G1 concurrent cycle pauses" >>> >>> CMS: >>> sun.gc.collector.2.name="CMS concurrent cycle pauses" >>> >>> ZGC: >>> sun.gc.collector.2.name="Z concurrent cycle pauses" >> Fine with me - since we are there, maybe you are interested in >> revisiting the names for the other CollectorCounters too? >> >> I found the following: >> >> Parallel GC: >> >> "PSScavenge" >> "PSParallelCompact" >> "PSMarkSweep" >> >> CMS: >> >> "CMS" >> "MSC" >> >> Serial: >> >> "PCopy" (I have no idea what this is supposed to be; this is serial >> young gc) >> >> We can skip them too if we can't find better names. >> >> Thanks, >> Thomas >> >> >> > > From yasuenag at gmail.com Thu Jan 31 14:00:20 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Jan 2019 23:00:20 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <45386bc559484f78ec07e16b63a51eb38240fe57.camel@oracle.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> <45386bc559484f78ec07e16b63a51eb38240fe57.camel@oracle.com> Message-ID: <59e0668c-11f5-7b3f-d4a4-da83a9a609ab@gmail.com> Thanks Thomas! I will add the comment to inc_capacity_until_GC() declaration. I'm waiting for second reviewer. Yasumasa On 2019/01/31 18:16, Thomas Schatzl wrote: > Hi Yasumasa, > > On Thu, 2019-01-31 at 14:09 +0900, Yasumasa Suenaga wrote: >> Hi Thomas, >> >> I uploaded new webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.03/ >> >> I agree with you that inc_capacity_until_GC() returns additional >> bool value whether new HWM is exceeded MaxMetaspaceSize. >> >> I added `can_retry` to argument of inc_capacity_until_GC(). >> It will be set to false if `new_value` exceeds MaxMetaspaceSize. >> Then inc_capacity_until_GC() returns false, but it is not break >> assert() in compute_new_size() because inc_capacity_until_GC() >> is called with `expand_bytes` which is limited by MaxMetaspaceSize. >> (It is ensured by this change) >> >> This change has passed vmTestbase/metaspace, gc/metaspace, and >> submit repo tests. > > looks good to me. Can you add some documentation to the declaration > of inc_capacity_until_GC() like: > > // Try to increase metaspace size by v bytes. Returns true if > // succeeded, false if not due to competing threads trying. > // Optionally returns new and old metaspace capacity in > // new_cap_until_GC and old_cap_until_GC respectively. > // Optionally sets can_retry to indicate whether if there is actually > // enough space remaining to satisfy the request. > > No need for a re-review for that (or something similar potentially > better worded description. > > Thanks, > Thomas > >