From thomas.schatzl at oracle.com Mon Dec 2 16:45:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 2 Dec 2019 17:45:20 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> Message-ID: <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> Hi, On 30.11.19 12:52, Haoyu Li wrote: > Hi Stefan, > > Thanks for your reviewing. If there are any further problems in the > code, please feel free to contact me! I am always more than happy to > improve the code. Looks good, with the following minor issues: > > >> - I think there is a missed optimization opportunity in (now) > > >> PSParallelCompact::initialize_shadow_regions(). There, the code > > >> initializes the "free" region ids to region_at_top+1 to > > >> end_region of a particular space. > > >> > > >> If the top for a given space is at a region boundary (e.g. if > > >> a space is empty, which is probably common for one of the > > >> survivor spaces), you loose a single region per space. > > >> > > >> One reason might that the code uses region "0" as sentinel to > > >> indicate "there is no shadow region available" in > > >> ParCompactionManager::acquire_shadow_region(). > > >> > > >> This could be fixed by improving the code in > > >> PSParallelCompact::initialize_shadow_regions() and use a sentinel > > >> region value of (size_t)~0 (as an explicit constant). > > >> > > >> Even if you do not change this, please introduce an explicit > > >> onstant for this sentinel value. This makes the code more self- > > >> explanatory. > > >> > > >> Sorry for the misleading +1 operation. The +1 can be safely > > >> removed. The sentinel value 0 does not cause this design because > > >> the first region (in old space) cannot be a shadow region. I was trying to come up for a reason that "the first region cannot be a shadow region", could you explain? What about if compaction starts off with empty old gen? In this case probably the situation can't occur, but still it seems more complicated than an obviously invalid shadow region id (which is far beyond the heap). Please change to use the ~0 sentinel (with a properly named constant) instead - this is much easier to reason about than otherwise. - psParallelCompact.cpp: line 3064: RegionSize is now unused, the line can be deleted. - I'd prefer if the push/pop_shadow_region_mt_safe methods used a MonitorLocker and a wait/notify scheme for synchronization. The pop method locking the _shadow_region_monitor in the infinite loop body (and not doing anything else) seems problematic when there is contention (if). Thanks, Thomas From leihouyju at gmail.com Tue Dec 3 09:08:09 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Tue, 3 Dec 2019 17:08:09 +0800 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> Message-ID: Hi Thomas, Thanks for your reviewing. Attachments are the updated patches, and details are as follows. I was trying to come up for a reason that "the first region cannot be a > shadow region", could you explain? What about if compaction starts off > with empty old gen? In this case probably the situation can't occur, but > still it seems more complicated than an obviously invalid shadow region > id (which is far beyond the heap). > > Please change to use the ~0 sentinel (with a properly named constant) > instead - this is much easier to reason about than otherwise. Sorry for the oversimple explanation. The first region cannot be a shadow region because we collect empty regions between max(top, new_top) and end of each space as shadow regions. For old space, though it could be empty, its new_top would be greater than 0 unless other spaces are also empty, which I think is impossible during a full GC. Therefore, max(top, new_top) will be greater than 0, and we won't collect region 0 as a shadow region. But I agree with you that using the ~0 sentinel is much easier to reason about the case. I have replaced the 0 with ~0 (ParCompactionManager::InvalidShadow) in the patches to avoid the above implicit logic. - psParallelCompact.cpp: line 3064: RegionSize is now unused, the line > can be deleted. I have deleted this line of dead code. > - I'd prefer if the push/pop_shadow_region_mt_safe methods used a > MonitorLocker and a wait/notify scheme for synchronization. The pop > method locking the _shadow_region_monitor in the infinite loop body (and > not doing anything else) seems problematic when there is contention (if). Thanks for the helpful suggestion! I have changed the MutexLocker to the MonitorLocker/wait/notify scheme. I use the timed wait because of a possible deadlock situation between two GC threads popping and pushing shadow regions. Suppose that region A's destination is region B, and thread T1 is processing region A with the only shadow region C first. If thread T2 then wants to process B with a shadow region, T2 will block in the pop_shadow_region_mt_safe since _shadow_region_array is empty. However, T1 cannot push C to _shadow_region_array because T1 hasn't copied C back to A, and T1 actually cannot copy C to A unless T2 has processed B. In such case, T1 won't notify T2, and therefore T2 has to wake up in a given time period to check if it should exist the shadow region protocal (return with ~0). However, this should be a rare case (so I reorder the two if clauses in ParCompactionManager::pop_shadow_region_mt_safe), and I set the time to 1 ms. Thanks very much for all your reviewing effort. Look forward to hearing from you. Best Regards, Haoyu Li Thomas Schatzl ?2019?12?3??? ??12:45??? > Hi, > > On 30.11.19 12:52, Haoyu Li wrote: > > Hi Stefan, > > > > Thanks for your reviewing. If there are any further problems in the > > code, please feel free to contact me! I am always more than happy to > > improve the code. > > Looks good, with the following minor issues: > > > > >> - I think there is a missed optimization opportunity in (now) > > > >> PSParallelCompact::initialize_shadow_regions(). There, the code > > > >> initializes the "free" region ids to region_at_top+1 to > > > >> end_region of a particular space. > > > >> > > > >> If the top for a given space is at a region boundary (e.g. if > > > >> a space is empty, which is probably common for one of the > > > >> survivor spaces), you loose a single region per space. > > > >> > > > >> One reason might that the code uses region "0" as sentinel to > > > >> indicate "there is no shadow region available" in > > > >> ParCompactionManager::acquire_shadow_region(). > > > >> > > > >> This could be fixed by improving the code in > > > >> PSParallelCompact::initialize_shadow_regions() and use a sentinel > > > >> region value of (size_t)~0 (as an explicit constant). > > > >> > > > >> Even if you do not change this, please introduce an explicit > > > >> onstant for this sentinel value. This makes the code more self- > > > >> explanatory. > > > >> > > > >> Sorry for the misleading +1 operation. The +1 can be safely > > > >> removed. The sentinel value 0 does not cause this design because > > > >> the first region (in old space) cannot be a shadow region. > > I was trying to come up for a reason that "the first region cannot be a > shadow region", could you explain? What about if compaction starts off > with empty old gen? In this case probably the situation can't occur, but > still it seems more complicated than an obviously invalid shadow region > id (which is far beyond the heap). > > Please change to use the ~0 sentinel (with a properly named constant) > instead - this is much easier to reason about than otherwise. > > - psParallelCompact.cpp: line 3064: RegionSize is now unused, the line > can be deleted. > > - I'd prefer if the push/pop_shadow_region_mt_safe methods used a > MonitorLocker and a wait/notify scheme for synchronization. The pop > method locking the _shadow_region_monitor in the infinite loop body (and > not doing anything else) seems problematic when there is contention (if). > > Thanks, > Thomas > -------------- next part -------------- A non-text attachment was scrubbed... Name: shadow-region-incr.patch Type: text/x-patch Size: 3964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shadow-region-v7.patch Type: text/x-patch Size: 30489 bytes Desc: not available URL: From thomas.schatzl at oracle.com Tue Dec 3 10:39:05 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 3 Dec 2019 11:39:05 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> Message-ID: <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> Hi, On 03.12.19 10:08, Haoyu Li wrote: > Hi Thomas, > > Thanks for your reviewing. Attachments are the updated patches, and > details are as follows. > > > I was trying to come up for a reason that "the first region cannot be a > > shadow region", could you explain? What about if compaction starts off > > with empty old gen? In this case probably the situation can't occur, > > but > > still it seems more complicated than an obviously invalid shadow region > > id (which is far beyond the heap). > > > > Please change to use the ~0 sentinel (with a properly named constant) > > instead - this is much easier to reason about than otherwise. > > > Sorry for the oversimple explanation. The first region cannot be a > shadow region because we collect empty regions between max(top, new_top) > and end of each space as shadow regions. For old space, though it could > be empty, its new_top would be greater than 0 unless other spaces are > also empty, which I think is impossible during a full GC. Therefore, > max(top, new_top) will be greater than 0, and we won't collect region 0 > as a shadow region. > > But I agree with you that using the ~0 sentinel is much easier to reason > about the case. I have replaced the 0 with ~0 > (ParCompactionManager::InvalidShadow) in the patches to avoid the above > implicit logic. Thanks, looks good. > > - I'd prefer if the push/pop_shadow_region_mt_safe methods used a > > MonitorLocker and a wait/notify scheme for synchronization. The pop > > method locking the _shadow_region_monitor in the infinite loop body > > (and > > not doing anything else) seems problematic when there is contention > > (if). > > > Thanks for the helpful suggestion! I have changed the MutexLocker to the > MonitorLocker/wait/notify scheme. I use the timed wait because of a > possible deadlock situation between two GC threads popping and pushing > [...] > (so I reorder the two if clauses in > ParCompactionManager::pop_shadow_region_mt_safe), and I set the time > to 1 ms. Stefan and me were just discussing this issue and to use a timed wait too. :) > > Thanks very much for all your reviewing effort. Look forward to hearing > from you. Looking at the patch, a few (further) minor nits that I fixed in the webrevs further below: - I rebased the change to latest code, e.g. the parameter order in Atomic::cmpxchg changed recently. Basically the first parameter (exchange_value) got moved to the third parameter. - we prefer to access statics via the class name, i.e. ParCompactionManager::InvalidShadow instead of cm->InvalidShadow. - some asserts were not updated to latest names of the states Please take a look if these changes are correct. I started a few internal regression testing runs. First, your recent changes as webrevs: http://cr.openjdk.java.net/~tschatzl/8220465/webrev.5_to_6/ (diff) http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6/ (full) Above changes: http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6_to_7/ (diff) http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7/ (full) Thanks, Thomas From thomas.schatzl at oracle.com Tue Dec 3 13:02:51 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 3 Dec 2019 14:02:51 +0100 Subject: RFR (S): 8235247: WorkerDataArray leaks C heap memory for associated work items Message-ID: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> Hi all, can I have reviews for this fix to a small memory leak, leaking a few 100 bytes per GC? WorkerDataArray does not delete linked thread work items, so code that temporarily creates and uses them leaks. Currently this is only a variant of WeakProcessor::weak_oops_do() that seems to be only used by G1. Thanks go to M. Vidstedt for finding and reporting the issue. CR: https://bugs.openjdk.java.net/browse/JDK-8235247 Webrev: http://cr.openjdk.java.net/~tschatzl/8235247/webrev/ Testing: manual testing using NMT; i did not observe other leaks given the example program attached to the CR. Thanks, Thomas From leo.korinth at oracle.com Tue Dec 3 14:45:35 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 3 Dec 2019 15:45:35 +0100 Subject: RFR (S): 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> References: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> Message-ID: <40a93cc8-903b-4502-6b43-143e082cefef@oracle.com> On 03/12/2019 14:02, Thomas Schatzl wrote: > Hi all, > > ? can I have reviews for this fix to a small memory leak, leaking a few > 100 bytes per GC? > > WorkerDataArray does not delete linked thread work items, so code that > temporarily creates and uses them leaks. > > Currently this is only a variant of WeakProcessor::weak_oops_do() that > seems to be only used by G1. > > Thanks go to M. Vidstedt for finding and reporting the issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235247 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235247/webrev/ Looks good! Thanks, Leo > Testing: > manual testing using NMT; i did not observe other leaks given the > example program attached to the CR. > > Thanks, > ? Thomas From kim.barrett at oracle.com Tue Dec 3 14:47:47 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Dec 2019 09:47:47 -0500 Subject: RFR (S): 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> References: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> Message-ID: <8B0212B4-33FF-4021-9E4B-0C85F5661637@oracle.com> > On Dec 3, 2019, at 8:02 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this fix to a small memory leak, leaking a few 100 bytes per GC? > > WorkerDataArray does not delete linked thread work items, so code that temporarily creates and uses them leaks. > > Currently this is only a variant of WeakProcessor::weak_oops_do() that seems to be only used by G1. > > Thanks go to M. Vidstedt for finding and reporting the issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235247 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235247/webrev/ > Testing: > manual testing using NMT; i did not observe other leaks given the example program attached to the CR. > > Thanks, > Thomas ~WeakProcessorPhaseTimes has delete expressions to deal with this. The problem is that the arrays whose elements are being deleted (_worker_dead_items and _worker_total_items) don't contain the expected WorkerDataArray objects. The constructor just calls link_thread_work_items on the new WorkerDataArrays directly, and does not record the new WorkerDataArrays in in those array members. I was expecting this change to introduce double-frees in G1GCPhaseTimes, but it seems there is no destructor or call to the destructor for that class. I think the right fix for the leak is to fix the WeakProcessorPhaseTimes constructor, rather than making link_thread_work_items (implicitly) transfer ownership of the argument to "this". From rkennke at redhat.com Tue Dec 3 16:29:50 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 3 Dec 2019 17:29:50 +0100 Subject: RFR: 8235260: Shenandoah: Do concurrent roots even when no evacuation is necessary Message-ID: <1cc2be19-2103-fc9e-6950-8f4027563f47@redhat.com> For concurrent class-unloading, we already found that we need to prevent recycle-assist until concurrent roots processing is over, otherwise we may get dangling pointers to a new region, which suddenly starts to appear as live again because objects get allocated in them. The same problem still exists for humongous regions, and we need to prevent using trashed regions for humongous allocations until we're done with concurrent roots. The solution is to treat trashed regions as non-empty as long as concurrent roots is in progress. Bug: https://bugs.openjdk.java.net/browse/JDK-8235260 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8235260/webrev.00/ Testing: hotspot_gc_shenandoah This used to fail with the upcoming concurrent roots cleaning that I have in progress, and passes now. Roman From stefan.johansson at oracle.com Tue Dec 3 18:21:35 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 3 Dec 2019 19:21:35 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> Message-ID: <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> Hi Thomas, Thanks for taking a look. On 2019-11-29 11:55, Thomas Schatzl wrote: > Hi, > On 26.11.19 16:01, Stefan Johansson wrote: >> Hi, >> >> Please review this fix to improve freeing the collection set when having a lot of regions. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8165443 >> Webrev: http://cr.openjdk.java.net/~sjohanss/8165443/00/ >> > some initial comments: > - g1CollectionSet::iterate_part_from: s/lenght/length Oups, fixed. > - HeapRegion::handle_evacuation_failed() -> handle_evacuation_failure() Fixed. > - heapRegionManager.hpp:176: s/region/regions Fixed. > - could the FreeRegionList refactoring be factored out? Not insisting on this, but might decrease the webrev quite a bit > > - G1FreeCollectionSetTask::G1FreeCollectionSetClosure::EventForRegion: maybe rename to JFREventForRegion to make it more clear that this is for JFR events. Changed. > - I would prefer that if a change modifies timing code, move it to use Ticks internally, i.e. in case of ...::TimerForRegion use Ticks/Tickspan as time base, not double, to slowly move to using Ticks everywhere. > Same with the double's for _young_time and _non_young_time in the area. > Also G1CollectedHeap::free_collection_set() should be changed imho. > (Yes, this introduces some ugly Tickspan::seconds() * 1000.0 calls, but they are probably easier to clean up later). Ok, changed to use Ticks. > - there is imho no need for the G1FreeCollectionSetClosure::stats() getter as it is only ever used locally and is trivial. Please at least make it private :) Made it private, I prefer the look of the code when using the getter in this case. > - not sure how I feel about not calling the destructor for the worker's FreeCSetStats. While it is empty I would still recommend calling it before freeing the containing array. > - same with the local FreRegionLists in ~G1RebuildFreeListTask. Added calls to the destructors. > - HeapRegionManager::is_available() is (mostly) meant as internal function, but due to assert'ing I was forced to make it public (probably should have a non-public version and a public one that is only available with assertions). > The use in G1RebuildFreeListTask::work() kind of violates this idea (and sorry for not mentioning it anywhere in the code). This was just a very small optimization instead of using at_or_null(), so reverted back to use that one. > Maybe move the entire freelist rebuild task into HeapRegionManager where it imho fits much better? HeapRegionManager is and should be the "owner" of the free list. > The call to HeapRegion::unlink_from_list() can probably be made earlier, or see below. > - another change I do not really like is the difference between "abandoning" the free list (and then later clearing the HeapRegion links in parallel) and "removing" the free list. While it makes sense from a performance POV, I would be happier if we could get away without introducing this tiny semantic difference. > An option would be that there were a FreeRegionList::add_to_tail that just overwrites the links. This would remove the need for the new "abandon" and other support methods in a few places and hide the ugliness there. > What do you think? Discussed this a bit with Thomas offline and we both agree that there can be further cleanups improvements here, but I think we agreed on just moving stuff into the HeapRegionManager but keep the added concepts. We both agree that having both remove_all and abandon for the freelist is not good in the long run, but getting rid of remove_all or fix remove_all to perform well is out of scope for this enhancement. > - while you mentioned that you did not look into balancing the work for the rebuild free list action, but please limit the workers in the G1RebuildFreeListTask by at least the number of regions in the heap. > (Move the chunk sizing outside of the G1RebuildFreeListTask for that.) Added a clamp to make sure we never use more workers than we have regions, even though in most cases this should never happen. > This sounds comical, but current machines' number of available threads are quickly approaching small heap sizes... > - instead of workers()->run_task() please use G1CollectedHeap::run_task(). That also removes some timing code for you around these places :) Can?t use that one since I need to time the destructor of the task as well. > - in the log, I believe that the "(Non-)Young Free collection set" "phases" should be indented one more place. > I.e. > GC(0) Free Collection Set: 0.0ms > GC(0) Serial Free Collection Set: 0.0ms > GC(0) Parallel Free Collection Set (ms): Min: ... > GC(0) Young Free Collection Set (ms): Min: ... > GC(0) Non-Young Free Collection Set (ms): skipped > should be > GC(0) Free Collection Set: 0.0ms > GC(0) Serial Free Collection Set: 0.0ms > GC(0) Parallel Free Collection Set (ms): Min: ... > GC(0) Young Free Collection Set (ms): Min: ... > GC(0) Non-Young Free Collection Set (ms): skipped Totally agree, added a extra_indent argument similar to what debug_phase already had. Here are the updated webrevs: Full: http://cr.openjdk.java.net/~sjohanss/8165443/01/ Inc: http://cr.openjdk.java.net/~sjohanss/8165443/00-01/ Thanks, Stefan > imo. > Thanks, > Thomas From stefan.johansson at oracle.com Tue Dec 3 18:46:08 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 3 Dec 2019 19:46:08 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> Message-ID: <36666990-8915-4BFB-8200-55232E57CFBF@oracle.com> Hi Thomas and Haoyu, > 3 dec. 2019 kl. 11:39 skrev Thomas Schatzl : > > Hi, > > On 03.12.19 10:08, Haoyu Li wrote: >> Hi Thomas, >> Thanks for your reviewing. Attachments are the updated patches, and details are as follows. >> > I was trying to come up for a reason that "the first region cannot be a >> > shadow region", could you explain? What about if compaction starts off >> > with empty old gen? In this case probably the situation can't occur, >> > but >> > still it seems more complicated than an obviously invalid shadow region >> > id (which is far beyond the heap). >> > >> > Please change to use the ~0 sentinel (with a properly named constant) >> > instead - this is much easier to reason about than otherwise. >> Sorry for the oversimple explanation. The first region cannot be a shadow region because we collect empty regions between max(top, new_top) and end of each space as shadow regions. For old space, though it could be empty, its new_top would be greater than 0 unless other spaces are also empty, which I think is impossible during a full GC. Therefore, max(top, new_top) will be greater than 0, and we won't collect region 0 as a shadow region. >> But I agree with you that using the ~0 sentinel is much easier to reason about the case. I have replaced the 0 with ~0 (ParCompactionManager::InvalidShadow) in the patches to avoid the above implicit logic. > > Thanks, looks good. > >> > - I'd prefer if the push/pop_shadow_region_mt_safe methods used a >> > MonitorLocker and a wait/notify scheme for synchronization. The pop >> > method locking the _shadow_region_monitor in the infinite loop body >> > (and >> > not doing anything else) seems problematic when there is contention >> > (if). >> Thanks for the helpful suggestion! I have changed the MutexLocker to the MonitorLocker/wait/notify scheme. I use the timed wait because of a possible deadlock situation between two GC threads popping and pushing > > [...] > > (so I reorder the two if clauses in > > ParCompactionManager::pop_shadow_region_mt_safe), and I set the time > > to 1 ms. > > Stefan and me were just discussing this issue and to use a timed wait too. :) > >> Thanks very much for all your reviewing effort. Look forward to hearing from you. > > Looking at the patch, a few (further) minor nits that I fixed in the webrevs further below: > > - I rebased the change to latest code, e.g. the parameter order in Atomic::cmpxchg changed recently. Basically the first parameter (exchange_value) got moved to the third parameter. > - we prefer to access statics via the class name, i.e. ParCompactionManager::InvalidShadow instead of cm->InvalidShadow. > - some asserts were not updated to latest names of the states > > Please take a look if these changes are correct. I started a few internal regression testing runs. > > First, your recent changes as webrevs: > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.5_to_6/ (diff) > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6/ (full) > > Above changes: > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6_to_7/ (diff) > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7/ (full) > All these changes look good to me, great work :) Thanks, Stefan > Thanks, > Thomas From zgu at redhat.com Tue Dec 3 19:55:48 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 3 Dec 2019 14:55:48 -0500 Subject: RFR: 8235260: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: <1cc2be19-2103-fc9e-6950-8f4027563f47@redhat.com> References: <1cc2be19-2103-fc9e-6950-8f4027563f47@redhat.com> Message-ID: Hi Roman, Fix looks good. Probably should change the method name is_empty_or_trash() to thing like can_allocate_from() ... Thanks, -Zhengyu On 12/3/19 11:29 AM, Roman Kennke wrote: > For concurrent class-unloading, we already found that we need to prevent > recycle-assist until concurrent roots processing is over, otherwise we > may get dangling pointers to a new region, which suddenly starts to > appear as live again because objects get allocated in them. The same > problem still exists for humongous regions, and we need to prevent using > trashed regions for humongous allocations until we're done with > concurrent roots. > > The solution is to treat trashed regions as non-empty as long as > concurrent roots is in progress. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8235260 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8235260/webrev.00/Fix > > Testing: hotspot_gc_shenandoah > This used to fail with the upcoming concurrent roots cleaning that I > have in progress, and passes now. > > Roman > From rkennke at redhat.com Tue Dec 3 20:16:19 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 3 Dec 2019 21:16:19 +0100 Subject: RFR: 8235260: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: References: <1cc2be19-2103-fc9e-6950-8f4027563f47@redhat.com> Message-ID: <6713b940-7298-fbf5-d42b-7000bcff561e@redhat.com> Ok. Like this? http://cr.openjdk.java.net/~rkennke/JDK-8235260/webrev.01/ Thanks, Roman > Hi Roman, > > Fix looks good. Probably should change the method name > is_empty_or_trash() to thing like can_allocate_from() ... > > Thanks, > > -Zhengyu > > On 12/3/19 11:29 AM, Roman Kennke wrote: >> For concurrent class-unloading, we already found that we need to prevent >> recycle-assist until concurrent roots processing is over, otherwise we >> may get dangling pointers to a new region, which suddenly starts to >> appear as live again because objects get allocated in them. The same >> problem still exists for humongous regions, and we need to prevent using >> trashed regions for humongous allocations until we're done with >> concurrent roots. >> >> The solution is to treat trashed regions as non-empty as long as >> concurrent roots is in progress. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8235260 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8235260/webrev.00/Fix >> >> Testing: hotspot_gc_shenandoah >> This used to fail with the upcoming concurrent roots cleaning that I >> have in progress, and passes now. >> >> Roman >> > From zgu at redhat.com Tue Dec 3 20:17:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 3 Dec 2019 15:17:11 -0500 Subject: RFR: 8235260: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: <6713b940-7298-fbf5-d42b-7000bcff561e@redhat.com> References: <1cc2be19-2103-fc9e-6950-8f4027563f47@redhat.com> <6713b940-7298-fbf5-d42b-7000bcff561e@redhat.com> Message-ID: Good. Thanks, -Zhengyu On 12/3/19 3:16 PM, Roman Kennke wrote: > Ok. Like this? > > http://cr.openjdk.java.net/~rkennke/JDK-8235260/webrev.01/ > > Thanks, > Roman > > >> Hi Roman, >> >> Fix looks good. Probably should change the method name >> is_empty_or_trash() to thing like can_allocate_from() ... >> >> Thanks, >> >> -Zhengyu >> >> On 12/3/19 11:29 AM, Roman Kennke wrote: >>> For concurrent class-unloading, we already found that we need to prevent >>> recycle-assist until concurrent roots processing is over, otherwise we >>> may get dangling pointers to a new region, which suddenly starts to >>> appear as live again because objects get allocated in them. The same >>> problem still exists for humongous regions, and we need to prevent using >>> trashed regions for humongous allocations until we're done with >>> concurrent roots. >>> >>> The solution is to treat trashed regions as non-empty as long as >>> concurrent roots is in progress. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8235260 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8235260/webrev.00/Fix >>> >>> Testing: hotspot_gc_shenandoah >>> This used to fail with the upcoming concurrent roots cleaning that I >>> have in progress, and passes now. >>> >>> Roman >>> >> > From rkennke at redhat.com Tue Dec 3 20:28:44 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 3 Dec 2019 21:28:44 +0100 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary Message-ID: Shenandoah can short-cut a cycle when the collection set remains empty, and doesn't dive into concurrent evacuation and updating refs phases then. However, this currently also precludes concurrent roots processing and concurrent class unloading. This is only a minor nuisance now (effectively skipping class unloading for short-cut-cycles), but amounts to a real bug when we're going to do weak-roots-cleaning concurrently too. Bug: https://bugs.openjdk.java.net/browse/JDK-8234974 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ Testing: hotspot_gc_shenandoah Can I please get a review? Roman From stefan.karlsson at oracle.com Wed Dec 4 08:50:37 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 09:50:37 +0100 Subject: RFR: 8235324: Dying objects are published from users of CollectedHeap::object_iterate Message-ID: Hi all, Please review this fix to make sure objects published from closures to CollectedHeap::object_iterate are kept alive. https://cr.openjdk.java.net/~stefank/8235324/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8235324 Caution needs to be taken when CollectedHeap::object_iterate is used. It may: - Return non-reachable objects - for example, when G1 walks the prev bitmap - Return the Reference.referent without an appropriate resurrection barrier - Return an object loaded without a "strong"/"marking" barrier These objects should not escape the confines of the active safepoint that calls object_iterate. If they do we run the risk of various crashes when the objects get garbage collected. Unfortunately, there are a few closures that do this. The once we have identified are: - HeapInspection::find_instances_at_safepoint - JVMTI object tagging There might be some merit to solving this by altering the object_iterate API, but for now we'd like to fix the two problematic areas listed above. The suggestion is to introduce a CollectedHeap::keep_alive function that notifies the GC that the object should be kept alive the current GC cycle (if active). This solution will also work with code that iterates over object fields without using object_iterate. For example, with this fix we'll be able to read the Reference.referent field in JDK-8234508, with AS_NO_KEEPALIVE, and only keep the object alive if it actually gets registered in the tag map. Without that, every single object reachable through Reference.referent would be kept alive. The fix introduces a keep_alive() function for ZGC, G1, and Shenandoah. It would be good to get reviews from maintainers of all these GCs. Thanks, StefanK From leihouyju at gmail.com Wed Dec 4 09:47:54 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Wed, 4 Dec 2019 17:47:54 +0800 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> Message-ID: Hi Thomas and Stefan, Thanks for your quick replies. The changes also look great to me, but I noticed that a few more statics and assertions could be improved, so I have updated them in the attached patches. I could have finished these updates earlier. However, there was a network issue that I cannot pull the latest code. Should you have any further suggestions, I am happy to adopt them. Best Regards, Haoyu Li Thomas Schatzl ?2019?12?3??? ??6:39??? > Hi, > > On 03.12.19 10:08, Haoyu Li wrote: > > Hi Thomas, > > > > Thanks for your reviewing. Attachments are the updated patches, and > > details are as follows. > > > > > I was trying to come up for a reason that "the first region cannot be a > > > shadow region", could you explain? What about if compaction starts off > > > with empty old gen? In this case probably the situation can't occur, > > > but > > > still it seems more complicated than an obviously invalid shadow region > > > id (which is far beyond the heap). > > > > > > Please change to use the ~0 sentinel (with a properly named constant) > > > instead - this is much easier to reason about than otherwise. > > > > > > Sorry for the oversimple explanation. The first region cannot be a > > shadow region because we collect empty regions between max(top, new_top) > > and end of each space as shadow regions. For old space, though it could > > be empty, its new_top would be greater than 0 unless other spaces are > > also empty, which I think is impossible during a full GC. Therefore, > > max(top, new_top) will be greater than 0, and we won't collect region 0 > > as a shadow region. > > > > But I agree with you that using the ~0 sentinel is much easier to reason > > about the case. I have replaced the 0 with ~0 > > (ParCompactionManager::InvalidShadow) in the patches to avoid the above > > implicit logic. > > Thanks, looks good. > > > > - I'd prefer if the push/pop_shadow_region_mt_safe methods used a > > > MonitorLocker and a wait/notify scheme for synchronization. The pop > > > method locking the _shadow_region_monitor in the infinite loop body > > > (and > > > not doing anything else) seems problematic when there is contention > > > (if). > > > > > > Thanks for the helpful suggestion! I have changed the MutexLocker to the > > MonitorLocker/wait/notify scheme. I use the timed wait because of a > > possible deadlock situation between two GC threads popping and pushing > > [...] > > (so I reorder the two if clauses in > > ParCompactionManager::pop_shadow_region_mt_safe), and I set the time > > to 1 ms. > > Stefan and me were just discussing this issue and to use a timed wait > too. :) > > > > > Thanks very much for all your reviewing effort. Look forward to hearing > > from you. > > Looking at the patch, a few (further) minor nits that I fixed in the > webrevs further below: > > - I rebased the change to latest code, e.g. the parameter order in > Atomic::cmpxchg changed recently. Basically the first parameter > (exchange_value) got moved to the third parameter. > - we prefer to access statics via the class name, i.e. > ParCompactionManager::InvalidShadow instead of cm->InvalidShadow. > - some asserts were not updated to latest names of the states > > Please take a look if these changes are correct. I started a few > internal regression testing runs. > > First, your recent changes as webrevs: > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.5_to_6/ (diff) > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6/ (full) > > Above changes: > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6_to_7/ (diff) > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7/ (full) > > Thanks, > Thomas > -------------- next part -------------- A non-text attachment was scrubbed... Name: shadow-region-incr.patch Type: text/x-patch Size: 4898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shadow-region-v8.patch Type: text/x-patch Size: 30576 bytes Desc: not available URL: From stefan.karlsson at oracle.com Wed Dec 4 10:15:04 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 11:15:04 +0100 Subject: RFR: 8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier Message-ID: Hi all, Please review this fix to ensure we use the correct barrier when resolving Refrence.referents in VM_HeapWalkOperation::iterate_over_object. https://cr.openjdk.java.net/~stefank/8234508/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8234508 Before this fix, the code would use an ON_STRONG barrier and potentially reading a dying referent during the resurrection blocked window. By using ON_UNKNOWN_OOP_REF we make sure that the correct barrier is used on Reference.referents, and the load will return NULL instead of a dead object. I'm also tagging the load as AS_NO_KEEPALIVE, since we likely don't want to keep all referents unnecessarily alive. This relies on the fix for '8235324: Dying objects are published from users of CollectedHeap::object_iterate'. Thanks, StefanK From zgu at redhat.com Wed Dec 4 10:21:51 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 4 Dec 2019 05:21:51 -0500 Subject: RFR 8235262: Move c2i_entry_barrier for x86_32 to shared Message-ID: <7d547ffb-031e-fd26-1075-6fdc5c4bf412@redhat.com> When integrating JDK-8230765 [1], I did not integrate c2i_entry_barrier. The implementation is not GC specific, should be moved to shared. Again, the implementation is very similar to x86_64 version, except it manufactures two temporary registers to act as scratch1 and scratch2 registers in x86_64. Bug: https://bugs.openjdk.java.net/browse/JDK-8235262 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.00/index.html Test: hotspot_gc (fastdebug and release) with x86_64 and x86_32 JVM on Linux submit tests Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8230765 From stefan.karlsson at oracle.com Wed Dec 4 10:34:34 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 11:34:34 +0100 Subject: RFR: 8235324: Dying objects are published from users of CollectedHeap::object_iterate In-Reply-To: References: Message-ID: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> Removed the unused oopDesc::keep_alive function: https://cr.openjdk.java.net/~stefank/8235324/webrev.02.delta/ https://cr.openjdk.java.net/~stefank/8235324/webrev.02/ StefanK On 2019-12-04 09:50, Stefan Karlsson wrote: > Hi all, > > Please review this fix to make sure objects published from closures to > CollectedHeap::object_iterate are kept alive. > > https://cr.openjdk.java.net/~stefank/8235324/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8235324 > > Caution needs to be taken when CollectedHeap::object_iterate is used. > It may: > - Return non-reachable objects - for example, when G1 walks the prev > bitmap > - Return the Reference.referent without an appropriate resurrection > barrier > - Return an object loaded without a "strong"/"marking" barrier > > These objects should not escape the confines of the active safepoint > that calls object_iterate. If they do we run the risk of various > crashes when the objects get garbage collected. > > Unfortunately, there are a few closures that do this. The once we have > identified are: > - HeapInspection::find_instances_at_safepoint > - JVMTI object tagging > > There might be some merit to solving this by altering the > object_iterate API, but for now we'd like to fix the two problematic > areas listed above. The suggestion is to introduce a > CollectedHeap::keep_alive function that notifies the GC that the > object should be kept alive the current GC cycle (if active). > > This solution will also work with code that iterates over object > fields without using object_iterate. For example, with this fix we'll > be able to read the Reference.referent field in JDK-8234508, with > AS_NO_KEEPALIVE, and only keep the object alive if it actually gets > registered in the tag map. Without that, every single object reachable > through Reference.referent would be kept alive. > > The fix introduces a keep_alive() function for ZGC, G1, and > Shenandoah. It would be good to get reviews from maintainers of all > these GCs. > > Thanks, > StefanK From per.liden at oracle.com Wed Dec 4 11:23:00 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 4 Dec 2019 12:23:00 +0100 Subject: RFR: 8235324: Dying objects are published from users of CollectedHeap::object_iterate In-Reply-To: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> References: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> Message-ID: Hi Stefan, On 12/4/19 11:34 AM, Stefan Karlsson wrote: > Removed the unused oopDesc::keep_alive function: > > https://cr.openjdk.java.net/~stefank/8235324/webrev.02.delta/ > https://cr.openjdk.java.net/~stefank/8235324/webrev.02/ zHeap.cpp should include zBarrier.inline.hpp now. I would maybe like to restructure the ZGC keepalive barrier a bit (or at least discuss some ideas). For example, I'm thinking the fast path could be "is_null_or_not_during_mark". But let's take that as a separate discussion/change. So, other than the missing include, looks good. No need for a new webrev. cheers, /Per > > StefanK > > On 2019-12-04 09:50, Stefan Karlsson wrote: >> Hi all, >> >> Please review this fix to make sure objects published from closures to >> CollectedHeap::object_iterate are kept alive. >> >> https://cr.openjdk.java.net/~stefank/8235324/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8235324 >> >> Caution needs to be taken when CollectedHeap::object_iterate is used. >> It may: >> - Return non-reachable objects - for example, when G1 walks the prev >> bitmap >> - Return the Reference.referent without an appropriate resurrection >> barrier >> - Return an object loaded without a "strong"/"marking" barrier >> >> These objects should not escape the confines of the active safepoint >> that calls object_iterate. If they do we run the risk of various >> crashes when the objects get garbage collected. >> >> Unfortunately, there are a few closures that do this. The once we have >> identified are: >> - HeapInspection::find_instances_at_safepoint >> - JVMTI object tagging >> >> There might be some merit to solving this by altering the >> object_iterate API, but for now we'd like to fix the two problematic >> areas listed above. The suggestion is to introduce a >> CollectedHeap::keep_alive function that notifies the GC that the >> object should be kept alive the current GC cycle (if active). >> >> This solution will also work with code that iterates over object >> fields without using object_iterate. For example, with this fix we'll >> be able to read the Reference.referent field in JDK-8234508, with >> AS_NO_KEEPALIVE, and only keep the object alive if it actually gets >> registered in the tag map. Without that, every single object reachable >> through Reference.referent would be kept alive. >> >> The fix introduces a keep_alive() function for ZGC, G1, and >> Shenandoah. It would be good to get reviews from maintainers of all >> these GCs. >> >> Thanks, >> StefanK > From per.liden at oracle.com Wed Dec 4 11:25:46 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 4 Dec 2019 12:25:46 +0100 Subject: RFR: 8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier In-Reply-To: References: Message-ID: On 12/4/19 11:15 AM, Stefan Karlsson wrote: > Hi all, > > Please review this fix to ensure we use the correct barrier when > resolving Refrence.referents in VM_HeapWalkOperation::iterate_over_object. > > https://cr.openjdk.java.net/~stefank/8234508/webrev.01/ Looks good. /Per > https://bugs.openjdk.java.net/browse/JDK-8234508 > > Before this fix, the code would use an ON_STRONG barrier and potentially > reading a dying referent during the resurrection blocked window. By > using ON_UNKNOWN_OOP_REF we make sure that the correct barrier is used > on Reference.referents, and the load will return NULL instead of a dead > object. > > I'm also tagging the load as AS_NO_KEEPALIVE, since we likely don't want > to keep all referents unnecessarily alive. This relies on the fix for > '8235324: Dying objects are published from users of > CollectedHeap::object_iterate'. > > Thanks, > StefanK From leo.korinth at oracle.com Wed Dec 4 11:32:28 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 4 Dec 2019 12:32:28 +0100 Subject: RFR: 8235250: Create (test) abstraction for allocating objects that is immune to removal by optimizations Message-ID: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> Hi, Please review this change to some tests that is needed for future optimizations. Reference.reachabilityFence seems not to be usable for ensuring GC allocations. I have added a new abstraction Allocation.blackHole(Object obj) for this. CR: https://bugs.openjdk.java.net/browse/JDK-8235250 Webrev: http://cr.openjdk.java.net/~lkorinth/8235250/00 Testing: currently running tier 1-3 on linux Thanks, Leo From stefan.karlsson at oracle.com Wed Dec 4 12:14:39 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 13:14:39 +0100 Subject: RFR: 8235324: Dying objects are published from users of CollectedHeap::object_iterate In-Reply-To: References: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> Message-ID: <649e85ce-8ce0-7897-8134-9d63833c64de@oracle.com> On 2019-12-04 12:23, Per Liden wrote: > Hi Stefan, > > On 12/4/19 11:34 AM, Stefan Karlsson wrote: >> Removed the unused oopDesc::keep_alive function: >> >> https://cr.openjdk.java.net/~stefank/8235324/webrev.02.delta/ >> https://cr.openjdk.java.net/~stefank/8235324/webrev.02/ > > zHeap.cpp should include zBarrier.inline.hpp now. OK. > > I would maybe like to restructure the ZGC keepalive barrier a bit (or > at least discuss some ideas). For example, I'm thinking the fast path > could be "is_null_or_not_during_mark". But let's take that as a > separate discussion/change. I was also thinking about not using the barrier(...) infrastructure at all, just calling the appropriate "slow path" function. I also think the other keep_alive_* functions are poorly named, they just fix the oop but don't keep the object alive. I'd be happy to deal with that in a separate discussion. > > So, other than the missing include, looks good. No need for a new webrev. Thanks, StefanK > > cheers, > /Per > >> >> StefanK >> >> On 2019-12-04 09:50, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this fix to make sure objects published from closures >>> to CollectedHeap::object_iterate are kept alive. >>> >>> https://cr.openjdk.java.net/~stefank/8235324/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8235324 >>> >>> Caution needs to be taken when CollectedHeap::object_iterate is >>> used. It may: >>> - Return non-reachable objects - for example, when G1 walks the prev >>> bitmap >>> - Return the Reference.referent without an appropriate resurrection >>> barrier >>> - Return an object loaded without a "strong"/"marking" barrier >>> >>> These objects should not escape the confines of the active safepoint >>> that calls object_iterate. If they do we run the risk of various >>> crashes when the objects get garbage collected. >>> >>> Unfortunately, there are a few closures that do this. The once we >>> have identified are: >>> - HeapInspection::find_instances_at_safepoint >>> - JVMTI object tagging >>> >>> There might be some merit to solving this by altering the >>> object_iterate API, but for now we'd like to fix the two problematic >>> areas listed above. The suggestion is to introduce a >>> CollectedHeap::keep_alive function that notifies the GC that the >>> object should be kept alive the current GC cycle (if active). >>> >>> This solution will also work with code that iterates over object >>> fields without using object_iterate. For example, with this fix >>> we'll be able to read the Reference.referent field in JDK-8234508, >>> with AS_NO_KEEPALIVE, and only keep the object alive if it actually >>> gets registered in the tag map. Without that, every single object >>> reachable through Reference.referent would be kept alive. >>> >>> The fix introduces a keep_alive() function for ZGC, G1, and >>> Shenandoah. It would be good to get reviews from maintainers of all >>> these GCs. >>> >>> Thanks, >>> StefanK >> From stefan.karlsson at oracle.com Wed Dec 4 12:25:45 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 13:25:45 +0100 Subject: RFR: 8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier In-Reply-To: References: Message-ID: <4d614baa-7d2e-5b9e-3e49-cf2b08ff7c0a@oracle.com> Thanks, Per. StefanK On 2019-12-04 12:25, Per Liden wrote: > On 12/4/19 11:15 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this fix to ensure we use the correct barrier when >> resolving Refrence.referents in >> VM_HeapWalkOperation::iterate_over_object. >> >> https://cr.openjdk.java.net/~stefank/8234508/webrev.01/ > > Looks good. > > /Per > >> https://bugs.openjdk.java.net/browse/JDK-8234508 >> >> Before this fix, the code would use an ON_STRONG barrier and >> potentially reading a dying referent during the resurrection blocked >> window. By using ON_UNKNOWN_OOP_REF we make sure that the correct >> barrier is used on Reference.referents, and the load will return NULL >> instead of a dead object. >> >> I'm also tagging the load as AS_NO_KEEPALIVE, since we likely don't >> want to keep all referents unnecessarily alive. This relies on the >> fix for '8235324: Dying objects are published from users of >> CollectedHeap::object_iterate'. >> >> Thanks, >> StefanK From thomas.schatzl at oracle.com Wed Dec 4 12:26:45 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Dec 2019 13:26:45 +0100 Subject: RFR (S): 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <8B0212B4-33FF-4021-9E4B-0C85F5661637@oracle.com> References: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> <8B0212B4-33FF-4021-9E4B-0C85F5661637@oracle.com> Message-ID: <51f0b15b-5788-51a6-f3ef-763072024b05@oracle.com> Hi Kim, On 03.12.19 15:47, Kim Barrett wrote: >> On Dec 3, 2019, at 8:02 AM, Thomas Schatzl wrote: >> >> Hi all, >> >> can I have reviews for this fix to a small memory leak, leaking a few 100 bytes per GC? >> >> WorkerDataArray does not delete linked thread work items, so code that temporarily creates and uses them leaks. >> >> Currently this is only a variant of WeakProcessor::weak_oops_do() that seems to be only used by G1. >> >> Thanks go to M. Vidstedt for finding and reporting the issue. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235247 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235247/webrev/ >> Testing: >> manual testing using NMT; i did not observe other leaks given the example program attached to the CR. >> >> Thanks, >> Thomas > > ~WeakProcessorPhaseTimes has delete expressions to deal with this. The > problem is that the arrays whose elements are being deleted > (_worker_dead_items and _worker_total_items) don't contain the > expected WorkerDataArray objects. The constructor just calls > link_thread_work_items on the new WorkerDataArrays directly, and does > not record the new WorkerDataArrays in in those array members. > > I was expecting this change to introduce double-frees in > G1GCPhaseTimes, but it seems there is no destructor or call to the > destructor for that class. > > I think the right fix for the leak is to fix the > WeakProcessorPhaseTimes constructor, rather than making > link_thread_work_items (implicitly) transfer ownership of the argument > to "this". > we talked about this internally and the results were that due to bad WorkerDataArray API it is unclear who should be the owner of these worker data items; we both agreed on making the "main" WorkerDataArray owner in the future, as there is no use case to share the item arrays. I will look into improving the API to make the usage less confusing asap (including cleaning up code that assumes otherwise), but for now as a point fix keep the change as is. If nobody objects I will push this change later today. Thanks, Thomas From leo.korinth at oracle.com Wed Dec 4 13:11:03 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 4 Dec 2019 14:11:03 +0100 Subject: RFR (S): 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <51f0b15b-5788-51a6-f3ef-763072024b05@oracle.com> References: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> <8B0212B4-33FF-4021-9E4B-0C85F5661637@oracle.com> <51f0b15b-5788-51a6-f3ef-763072024b05@oracle.com> Message-ID: <0f23d89a-f47b-315d-a582-dd0f0802813f@oracle.com> On 04/12/2019 13:26, Thomas Schatzl wrote: > Hi Kim, > > On 03.12.19 15:47, Kim Barrett wrote: >>> On Dec 3, 2019, at 8:02 AM, Thomas Schatzl >>> wrote: >>> >>> Hi all, >>> >>> ? can I have reviews for this fix to a small memory leak, leaking a >>> few 100 bytes per GC? >>> >>> WorkerDataArray does not delete linked thread work items, so code >>> that temporarily creates and uses them leaks. >>> >>> Currently this is only a variant of WeakProcessor::weak_oops_do() >>> that seems to be only used by G1. >>> >>> Thanks go to M. Vidstedt for finding and reporting the issue. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8235247 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8235247/webrev/ >>> Testing: >>> manual testing using NMT; i did not observe other leaks given the >>> example program attached to the CR. >>> >>> Thanks, >>> ? Thomas >> >> ~WeakProcessorPhaseTimes has delete expressions to deal with this. The >> problem is that the arrays whose elements are being deleted >> (_worker_dead_items and _worker_total_items) don't contain the >> expected WorkerDataArray objects. The constructor just calls >> link_thread_work_items on the new WorkerDataArrays directly, and does >> not record the new WorkerDataArrays in in those array members. >> >> I was expecting this change to introduce double-frees in >> G1GCPhaseTimes, but it seems there is no destructor or call to the >> destructor for that class. >> >> I think the right fix for the leak is to fix the >> WeakProcessorPhaseTimes constructor, rather than making >> link_thread_work_items (implicitly) transfer ownership of the argument >> to "this". >> > > ? we talked about this internally and the results were that due to bad > WorkerDataArray API it is unclear who should be the owner of these > worker data items; we both agreed on making the "main" WorkerDataArray > owner in the future, as there is no use case to share the item arrays. I > will look into improving the API to make the usage less confusing asap > (including cleaning up code that assumes otherwise), but for now as a > point fix keep the change as is. > > If nobody objects I will push this change later today. I am still okay with your change, and I agree with shipping it "as is". Eventually I would really appreciate a clean-up or even rewrite. Every time I look into the "half recursive" WorkerDataArray I get extremely confused. IMO WorkerDataArray should be /two/ separate types, big parts of the API is only applicable to the "aggregated" arrays. I also agree with Kim that ownership is unclear; maybe (in the future) make link_thread_work_items into allocate_thread_work_items to have allocation and deletion of sub-arrays in the same class. A tracking CR for cleaning up the deletes Kim mentioned would be good. Thanks, Leo > Thanks, > ? Thomas From thomas.schatzl at oracle.com Wed Dec 4 13:42:14 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Dec 2019 14:42:14 +0100 Subject: RFR (S): 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <0f23d89a-f47b-315d-a582-dd0f0802813f@oracle.com> References: <77ee2261-dfa5-cd96-6114-02e8128ec965@oracle.com> <8B0212B4-33FF-4021-9E4B-0C85F5661637@oracle.com> <51f0b15b-5788-51a6-f3ef-763072024b05@oracle.com> <0f23d89a-f47b-315d-a582-dd0f0802813f@oracle.com> Message-ID: <5b1924b1-1b88-3466-e451-8407072795ae@oracle.com> Hi Leo, On 04.12.19 14:11, Leo Korinth wrote: > > > On 04/12/2019 13:26, Thomas Schatzl wrote: >> Hi Kim, >> >> On 03.12.19 15:47, Kim Barrett wrote: >>>> On Dec 3, 2019, at 8:02 AM, Thomas Schatzl >>>> wrote: [...]>>> >>> I think the right fix for the leak is to fix the >>> WeakProcessorPhaseTimes constructor, rather than making >>> link_thread_work_items (implicitly) transfer ownership of the argument >>> to "this". >>> >> >> ?? we talked about this internally and the results were that due to >> bad WorkerDataArray API it is unclear who should be the owner of these >> worker data items; we both agreed on making the "main" WorkerDataArray >> owner in the future, as there is no use case to share the item arrays. >> I will look into improving the API to make the usage less confusing >> asap (including cleaning up code that assumes otherwise), but for now >> as a point fix keep the change as is. >> >> If nobody objects I will push this change later today. > > I am still okay with your change, and I agree with shipping it "as is". Thanks for your understanding. > Eventually I would really appreciate a clean-up or even rewrite. Every > time I look into the "half recursive" WorkerDataArray I get extremely > confused. IMO WorkerDataArray should be /two/ separate types, big parts > of the API is only applicable to the "aggregated" arrays. I also agree > with Kim that ownership is unclear; maybe (in the future) make > link_thread_work_items into allocate_thread_work_items to have > allocation and deletion of sub-arrays in the same class. A tracking CR > for cleaning up the deletes Kim mentioned would be good. I already finished cleaning up the issues Kim mentioned and I will file an RFE for this cleanup change later and post it. These do not cover breaking up things further, but I agree that G1GCPhaseTimes is ripe for a good refactoring; another item on the wish list would be to use Ticks/Tickspan for storage of the times. Even more changes like better (and simpler/easier) use with parallel tasks/AbstractGangTask, potentially integrating into them directly, have been floating around for some time. There are already RFEs for some of that too - just that there hasn't been anyone picking these up in earnest. Thanks, Thomas From erik.osterlund at oracle.com Wed Dec 4 14:20:01 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 4 Dec 2019 15:20:01 +0100 Subject: RFR: 8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier In-Reply-To: References: Message-ID: <52e719bc-1010-8e59-c3d2-917c4f93177e@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2019-12-04 11:15, Stefan Karlsson wrote: > Hi all, > > Please review this fix to ensure we use the correct barrier when > resolving Refrence.referents in > VM_HeapWalkOperation::iterate_over_object. > > https://cr.openjdk.java.net/~stefank/8234508/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8234508 > > Before this fix, the code would use an ON_STRONG barrier and > potentially reading a dying referent during the resurrection blocked > window. By using ON_UNKNOWN_OOP_REF we make sure that the correct > barrier is used on Reference.referents, and the load will return NULL > instead of a dead object. > > I'm also tagging the load as AS_NO_KEEPALIVE, since we likely don't > want to keep all referents unnecessarily alive. This relies on the fix > for '8235324: Dying objects are published from users of > CollectedHeap::object_iterate'. > > Thanks, > StefanK From erik.osterlund at oracle.com Wed Dec 4 14:23:52 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 4 Dec 2019 15:23:52 +0100 Subject: RFR: 8235324: Dying objects are published from users of CollectedHeap::object_iterate In-Reply-To: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> References: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> Message-ID: <27059923-622b-f5a4-4363-9d58ef07716b@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2019-12-04 11:34, Stefan Karlsson wrote: > Removed the unused oopDesc::keep_alive function: > > https://cr.openjdk.java.net/~stefank/8235324/webrev.02.delta/ > https://cr.openjdk.java.net/~stefank/8235324/webrev.02/ > > StefanK > > On 2019-12-04 09:50, Stefan Karlsson wrote: >> Hi all, >> >> Please review this fix to make sure objects published from closures >> to CollectedHeap::object_iterate are kept alive. >> >> https://cr.openjdk.java.net/~stefank/8235324/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8235324 >> >> Caution needs to be taken when CollectedHeap::object_iterate is used. >> It may: >> - Return non-reachable objects - for example, when G1 walks the prev >> bitmap >> - Return the Reference.referent without an appropriate resurrection >> barrier >> - Return an object loaded without a "strong"/"marking" barrier >> >> These objects should not escape the confines of the active safepoint >> that calls object_iterate. If they do we run the risk of various >> crashes when the objects get garbage collected. >> >> Unfortunately, there are a few closures that do this. The once we >> have identified are: >> - HeapInspection::find_instances_at_safepoint >> - JVMTI object tagging >> >> There might be some merit to solving this by altering the >> object_iterate API, but for now we'd like to fix the two problematic >> areas listed above. The suggestion is to introduce a >> CollectedHeap::keep_alive function that notifies the GC that the >> object should be kept alive the current GC cycle (if active). >> >> This solution will also work with code that iterates over object >> fields without using object_iterate. For example, with this fix we'll >> be able to read the Reference.referent field in JDK-8234508, with >> AS_NO_KEEPALIVE, and only keep the object alive if it actually gets >> registered in the tag map. Without that, every single object >> reachable through Reference.referent would be kept alive. >> >> The fix introduces a keep_alive() function for ZGC, G1, and >> Shenandoah. It would be good to get reviews from maintainers of all >> these GCs. >> >> Thanks, >> StefanK > From rkennke at redhat.com Wed Dec 4 14:23:57 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 4 Dec 2019 15:23:57 +0100 Subject: RFR 8235262: Move c2i_entry_barrier for x86_32 to shared In-Reply-To: <7d547ffb-031e-fd26-1075-6fdc5c4bf412@redhat.com> References: <7d547ffb-031e-fd26-1075-6fdc5c4bf412@redhat.com> Message-ID: <4bbe89c9-b02e-626e-e9ef-8c392f64554a@redhat.com> It looks good to me, thanks! Roman > When integrating JDK-8230765 [1], I did not integrate c2i_entry_barrier. > The implementation is not GC specific, should be moved to shared. > > Again, the implementation is very similar to x86_64 version, except it > manufactures two temporary registers to act as scratch1 and scratch2 > registers in x86_64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235262 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.00/index.html > > > Test: > ? hotspot_gc (fastdebug and release) with x86_64 and x86_32 JVM on Linux > ? submit tests > > > Thanks, > > -Zhengyu > > [1] https://bugs.openjdk.java.net/browse/JDK-8230765 > From erik.osterlund at oracle.com Wed Dec 4 14:30:32 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 4 Dec 2019 15:30:32 +0100 Subject: RFR 8235262: Move c2i_entry_barrier for x86_32 to shared In-Reply-To: <7d547ffb-031e-fd26-1075-6fdc5c4bf412@redhat.com> References: <7d547ffb-031e-fd26-1075-6fdc5c4bf412@redhat.com> Message-ID: <6067adc1-bfc8-36a5-2fc2-4c19b57d6e63@oracle.com> Hi Zhengyu, Since the 32 bit stuff is just a copy paste of the 64 bit stuff, with some small tweaks, I think it might be easier to read and maintain if you tried to merge the two implementations and just do things different where it is different. Thanks, /Erik On 2019-12-04 11:21, Zhengyu Gu wrote: > When integrating JDK-8230765 [1], I did not integrate > c2i_entry_barrier. The implementation is not GC specific, should be > moved to shared. > > Again, the implementation is very similar to x86_64 version, except it > manufactures two temporary registers to act as scratch1 and scratch2 > registers in x86_64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235262 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.00/index.html > > > Test: > ? hotspot_gc (fastdebug and release) with x86_64 and x86_32 JVM on Linux > ? submit tests > > > Thanks, > > -Zhengyu > > [1] https://bugs.openjdk.java.net/browse/JDK-8230765 > From stefan.karlsson at oracle.com Wed Dec 4 14:34:29 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 15:34:29 +0100 Subject: RFR: 8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier In-Reply-To: <52e719bc-1010-8e59-c3d2-917c4f93177e@oracle.com> References: <52e719bc-1010-8e59-c3d2-917c4f93177e@oracle.com> Message-ID: <4ecd46a7-647e-0540-0ea1-1d9934191330@oracle.com> Thanks, Erik. StefanK On 2019-12-04 15:20, Erik ?sterlund wrote: > Hi Stefan, > > Looks good. > > Thanks, > /Erik > > On 2019-12-04 11:15, Stefan Karlsson wrote: >> Hi all, >> >> Please review this fix to ensure we use the correct barrier when >> resolving Refrence.referents in >> VM_HeapWalkOperation::iterate_over_object. >> >> https://cr.openjdk.java.net/~stefank/8234508/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8234508 >> >> Before this fix, the code would use an ON_STRONG barrier and >> potentially reading a dying referent during the resurrection blocked >> window. By using ON_UNKNOWN_OOP_REF we make sure that the correct >> barrier is used on Reference.referents, and the load will return NULL >> instead of a dead object. >> >> I'm also tagging the load as AS_NO_KEEPALIVE, since we likely don't >> want to keep all referents unnecessarily alive. This relies on the >> fix for '8235324: Dying objects are published from users of >> CollectedHeap::object_iterate'. >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Dec 4 14:34:51 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 4 Dec 2019 15:34:51 +0100 Subject: RFR: 8235324: Dying objects are published from users of CollectedHeap::object_iterate In-Reply-To: <27059923-622b-f5a4-4363-9d58ef07716b@oracle.com> References: <3fcb952a-c0ed-1368-f16a-2fb4357eee07@oracle.com> <27059923-622b-f5a4-4363-9d58ef07716b@oracle.com> Message-ID: <377593b7-4a7a-e099-d152-bb50dae3d704@oracle.com> Thanks, Erik. StefanK On 2019-12-04 15:23, Erik ?sterlund wrote: > Hi Stefan, > > Looks good. > > Thanks, > /Erik > > On 2019-12-04 11:34, Stefan Karlsson wrote: >> Removed the unused oopDesc::keep_alive function: >> >> https://cr.openjdk.java.net/~stefank/8235324/webrev.02.delta/ >> https://cr.openjdk.java.net/~stefank/8235324/webrev.02/ >> >> StefanK >> >> On 2019-12-04 09:50, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this fix to make sure objects published from closures >>> to CollectedHeap::object_iterate are kept alive. >>> >>> https://cr.openjdk.java.net/~stefank/8235324/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8235324 >>> >>> Caution needs to be taken when CollectedHeap::object_iterate is >>> used. It may: >>> - Return non-reachable objects - for example, when G1 walks the prev >>> bitmap >>> - Return the Reference.referent without an appropriate resurrection >>> barrier >>> - Return an object loaded without a "strong"/"marking" barrier >>> >>> These objects should not escape the confines of the active safepoint >>> that calls object_iterate. If they do we run the risk of various >>> crashes when the objects get garbage collected. >>> >>> Unfortunately, there are a few closures that do this. The once we >>> have identified are: >>> - HeapInspection::find_instances_at_safepoint >>> - JVMTI object tagging >>> >>> There might be some merit to solving this by altering the >>> object_iterate API, but for now we'd like to fix the two problematic >>> areas listed above. The suggestion is to introduce a >>> CollectedHeap::keep_alive function that notifies the GC that the >>> object should be kept alive the current GC cycle (if active). >>> >>> This solution will also work with code that iterates over object >>> fields without using object_iterate. For example, with this fix >>> we'll be able to read the Reference.referent field in JDK-8234508, >>> with AS_NO_KEEPALIVE, and only keep the object alive if it actually >>> gets registered in the tag map. Without that, every single object >>> reachable through Reference.referent would be kept alive. >>> >>> The fix introduces a keep_alive() function for ZGC, G1, and >>> Shenandoah. It would be good to get reviews from maintainers of all >>> these GCs. >>> >>> Thanks, >>> StefanK >> > From erik.osterlund at oracle.com Wed Dec 4 14:45:10 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 4 Dec 2019 15:45:10 +0100 Subject: RFR: 8235250: Create (test) abstraction for allocating objects that is immune to removal by optimizations In-Reply-To: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> References: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> Message-ID: <3466972d-bf8d-2a02-51e3-e42338f31c5f@oracle.com> Hi Leo, Looks reasonable to me. Thanks, /Erik On 2019-12-04 12:32, Leo Korinth wrote: > Hi, > > Please review this change to some tests that is needed for future > optimizations. Reference.reachabilityFence seems not to be usable for > ensuring GC allocations. > > I have added a new abstraction Allocation.blackHole(Object obj) for this. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235250 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8235250/00 > > Testing: > currently running tier 1-3 on linux > > Thanks, > Leo From leo.korinth at oracle.com Wed Dec 4 15:07:01 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 4 Dec 2019 16:07:01 +0100 Subject: RFR: 8235250: Create (test) abstraction for allocating objects that is immune to removal by optimizations In-Reply-To: <3466972d-bf8d-2a02-51e3-e42338f31c5f@oracle.com> References: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> <3466972d-bf8d-2a02-51e3-e42338f31c5f@oracle.com> Message-ID: <0ae8863a-069e-47ac-7453-60dda4a837c7@oracle.com> On 04/12/2019 15:45, Erik ?sterlund wrote: > Hi Leo, > > Looks reasonable to me. > > Thanks, > /Erik Thanks for your review Erik! /Leo > > On 2019-12-04 12:32, Leo Korinth wrote: >> Hi, >> >> Please review this change to some tests that is needed for future >> optimizations. Reference.reachabilityFence seems not to be usable for >> ensuring GC allocations. >> >> I have added a new abstraction Allocation.blackHole(Object obj) for this. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235250 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8235250/00 >> >> Testing: >> currently running tier 1-3 on linux >> >> Thanks, >> Leo > From thomas.schatzl at oracle.com Wed Dec 4 15:55:11 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Dec 2019 16:55:11 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> Message-ID: <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> Hi all, On 04.12.19 10:47, Haoyu Li wrote: > Hi Thomas and Stefan, > > Thanks for your quick replies. The changes also look great to me, but I > noticed that a few more statics and assertions could be improved, so I > have updated them in the attached patches.? I could have finished these > updates earlier. However, there was a network issue that I cannot pull > the latest code. Should you have any further suggestions, I am happy to > adopt them. > > Best Regards, > Haoyu Li Merged with your changes. http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) Tests of the previous version were good afaict. Ready to go imho :) Thomas From stefan.johansson at oracle.com Wed Dec 4 16:27:27 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 4 Dec 2019 17:27:27 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> Message-ID: <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> > 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl : > > Hi all, > > On 04.12.19 10:47, Haoyu Li wrote: >> Hi Thomas and Stefan, >> Thanks for your quick replies. The changes also look great to me, but I noticed that a few more statics and assertions could be improved, so I have updated them in the attached patches. I could have finished these updates earlier. However, there was a network issue that I cannot pull the latest code. Should you have any further suggestions, I am happy to adopt them. >> Best Regards, >> Haoyu Li > > Merged with your changes. > > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) > http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) > > Tests of the previous version were good afaict. > > Ready to go imho :) I agree, Stefan > > Thomas From rkennke at redhat.com Wed Dec 4 16:45:26 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 4 Dec 2019 17:45:26 +0100 Subject: RFR: 8235337: Shenandoah: Fix evac OOM scoping for concurrent class unloading Message-ID: <430d3992-c112-2709-5714-162c19d1b42c@redhat.com> CI threw up a bunch of asserts claiming that OOM scope hasn't been set-up correctly on an evacuating code path. I believe I have tracked this down to ShenandoahUnlinkTask calling into runtime and coming back with a native LRB call that is not procted with OOM scope. See more info in the bug report: https://bugs.openjdk.java.net/browse/JDK-8235337 The fix would be to move the OOM scope all the way up to the worker entry in ShenandoahUnlinkTask::work(), and remove lower scopes (because they are not reentrant): http://cr.openjdk.java.net/~rkennke/JDK-8235337/webrev.01/ Testing: hotspot_gc_shenandoah specjvm with +aggressive and +ShenandoahOOMDuringEvacALot (which triggered the original problem). Ok? Roman From thomas.schatzl at oracle.com Wed Dec 4 17:42:16 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Dec 2019 18:42:16 +0100 Subject: RFR (T): 8235347: [Backout] 8235247: WorkerDataArray leaks C heap memory for associated work items Message-ID: Hi, can I have reviews for the backout of 8235247: WorkerDataArray leaks C heap memory for associated work items since it fails some basic gtests, giving me more time to look into this? CR: https://bugs.openjdk.java.net/browse/JDK-8235347 Webrev: http://cr.openjdk.java.net/~tschatzl/8235347/webrev/ Original change: https://hg.openjdk.java.net/jdk/jdk/rev/19d927f669e9 Thanks, Thomas From stefan.johansson at oracle.com Wed Dec 4 17:52:38 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 4 Dec 2019 18:52:38 +0100 Subject: RFR (T): 8235347: [Backout] 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: References: Message-ID: <7898D905-B221-44D3-83F9-AAF0DA2BA3B4@oracle.com> Looks good, Stefan > 4 dec. 2019 kl. 18:42 skrev Thomas Schatzl : > > Hi, > > can I have reviews for the backout of 8235247: WorkerDataArray leaks C heap memory for associated work items since it fails some basic gtests, giving me more time to look into this? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235347 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235347/webrev/ > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/19d927f669e9 > > Thanks, > Thomas From leo.korinth at oracle.com Wed Dec 4 17:54:54 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 4 Dec 2019 18:54:54 +0100 Subject: RFR (T): 8235347: [Backout] 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <7898D905-B221-44D3-83F9-AAF0DA2BA3B4@oracle.com> References: <7898D905-B221-44D3-83F9-AAF0DA2BA3B4@oracle.com> Message-ID: Looks good. /Leo On 04/12/2019 18:52, Stefan Johansson wrote: > Looks good, > > Stefan > >> 4 dec. 2019 kl. 18:42 skrev Thomas Schatzl : >> >> Hi, >> >> can I have reviews for the backout of 8235247: WorkerDataArray leaks C heap memory for associated work items since it fails some basic gtests, giving me more time to look into this? >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235347 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235347/webrev/ >> >> Original change: >> https://hg.openjdk.java.net/jdk/jdk/rev/19d927f669e9 >> >> Thanks, >> Thomas > From thomas.schatzl at oracle.com Wed Dec 4 17:56:04 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Dec 2019 18:56:04 +0100 Subject: RFR (T): 8235347: [Backout] 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: References: <7898D905-B221-44D3-83F9-AAF0DA2BA3B4@oracle.com> Message-ID: Hi Leo, Stefan, On 04.12.19 18:54, Leo Korinth wrote: > Looks good. thanks for your quick reviews. Pushed. Thomas > > /Leo > > On 04/12/2019 18:52, Stefan Johansson wrote: >> Looks good, >> >> Stefan >> >>> 4 dec. 2019 kl. 18:42 skrev Thomas Schatzl : >>> >>> Hi, >>> >>> ? can I have reviews for the backout of 8235247: WorkerDataArray >>> leaks C heap memory for associated work items since it fails some >>> basic gtests, giving me more time to look into this? >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8235347 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8235347/webrev/ >>> >>> Original change: >>> https://hg.openjdk.java.net/jdk/jdk/rev/19d927f669e9 >>> >>> Thanks, >>> ? Thomas >> From zgu at redhat.com Wed Dec 4 19:00:48 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 4 Dec 2019 14:00:48 -0500 Subject: RFR: 8235337: Shenandoah: Fix evac OOM scoping for concurrent class unloading In-Reply-To: <430d3992-c112-2709-5714-162c19d1b42c@redhat.com> References: <430d3992-c112-2709-5714-162c19d1b42c@redhat.com> Message-ID: <8fa763e8-7459-baa6-14b7-7a17b651e888@redhat.com> Fix is good. Thanks, -Zhengyu On 12/4/19 11:45 AM, Roman Kennke wrote: > CI threw up a bunch of asserts claiming that OOM scope hasn't been > set-up correctly on an evacuating code path. I believe I have tracked > this down to ShenandoahUnlinkTask calling into runtime and coming back > with a native LRB call that is not procted with OOM scope. See more info > in the bug report: > > https://bugs.openjdk.java.net/browse/JDK-8235337 > > The fix would be to move the OOM scope all the way up to the worker > entry in ShenandoahUnlinkTask::work(), and remove lower scopes (because > they are not reentrant): > > http://cr.openjdk.java.net/~rkennke/JDK-8235337/webrev.01/ > > Testing: hotspot_gc_shenandoah > specjvm with +aggressive and +ShenandoahOOMDuringEvacALot (which > triggered the original problem). > > Ok? > > Roman > From rkennke at redhat.com Wed Dec 4 20:02:55 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 4 Dec 2019 21:02:55 +0100 Subject: RFR: 8235355: Shenandoah: Resolve deadlock between OOM handler and nmethod lock Message-ID: JDK-8235337 changed OOM scoping, but unfortunately it causes a deadlock. See bug report for more details: https://bugs.openjdk.java.net/browse/JDK-8235355 The proposed fix ensures that we're entering the nmethod lock and OOM scope in the right and the same order always. It reverts JDK-8235337 and puts an extra OOM scope on the path that caused the original bug. http://cr.openjdk.java.net/~rkennke/JDK-8235355/webrev.00/ Testing: hotspot_gc_shenandoah, specjvm with +aggressive and +ShenandoahOOMDuringEvacALot Can I please get a review? Thanks, Roman From zgu at redhat.com Wed Dec 4 20:38:48 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 4 Dec 2019 15:38:48 -0500 Subject: RFR: 8235355: Shenandoah: Resolve deadlock between OOM handler and nmethod lock In-Reply-To: References: Message-ID: <5dcea1df-9e7d-3936-43ea-c0f70bb3489a@redhat.com> Look good. Thanks, -Zhengyu On 12/4/19 3:02 PM, Roman Kennke wrote: > JDK-8235337 changed OOM scoping, but unfortunately it causes a deadlock. > See bug report for more details: > > https://bugs.openjdk.java.net/browse/JDK-8235355 > > The proposed fix ensures that we're entering the nmethod lock and OOM > scope in the right and the same order always. It reverts JDK-8235337 and > puts an extra OOM scope on the path that caused the original bug. > > http://cr.openjdk.java.net/~rkennke/JDK-8235355/webrev.00/ > > Testing: hotspot_gc_shenandoah, specjvm with +aggressive and > +ShenandoahOOMDuringEvacALot > > Can I please get a review? > > Thanks, > Roman > From thomas.schatzl at oracle.com Thu Dec 5 09:20:44 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 5 Dec 2019 10:20:44 +0100 Subject: RFR (S): 8235346: [Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items Message-ID: <71037a60-8ccb-15ec-d34f-3aa4d9878530@oracle.com> Hi all, can I have reviews for this redo for 8235247: WorkerDataArray leaks C heap memory for associated work items; while the original change in the GC code has been correct, the associated gtest did double-frees, causing errors. The test assumed that ownership of the sub-WorkerDataArray did not transfer, and it is responsible for freeing it. This issue has not been caught in the original change because I only did local jtreg testing (which does not include jtreg) for this change separately. CI testing has only been done for this with the follow-up JDK-8235341 included which passed. Sorry for this. CR: https://bugs.openjdk.java.net/browse/JDK-8235346 Webrev: http://cr.openjdk.java.net/~tschatzl/8235346/webrev/ Testing: hs-tier1-3 Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 5 09:27:50 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 5 Dec 2019 10:27:50 +0100 Subject: RFR (S): 8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items Message-ID: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> Hi all, can I have reviews for this follow-up change of JDK-8235247 that improves the API about using sub-items in WorkerDataArray to effectively disallow manual handling of them. This makes it hopefully clear how to use sub-WorkerDataArrays, and impossible to use them separately, obviating questions about ownership. The change is mostly about changing the link_thread_work_items() method to internally construct the sub-WorkerDataArray; this results in a lot of obsolete code that has been removed here. This cleanup is followed by a change of the argument order in the WorkerDataArray constructor to make the argument order similar to link/add_thread_work_items(). CR: https://bugs.openjdk.java.net/browse/JDK-8235341 Webrev: http://cr.openjdk.java.net/~tschatzl/8235341/webrev/ Testing: hs-tier1-3 Thanks, Thomas From stefan.johansson at oracle.com Thu Dec 5 09:41:25 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 5 Dec 2019 10:41:25 +0100 Subject: RFR (S): 8235346: [Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <71037a60-8ccb-15ec-d34f-3aa4d9878530@oracle.com> References: <71037a60-8ccb-15ec-d34f-3aa4d9878530@oracle.com> Message-ID: Looks good, StefanJ > 5 dec. 2019 kl. 10:20 skrev Thomas Schatzl : > > Hi all, > > can I have reviews for this redo for 8235247: WorkerDataArray leaks C heap memory for associated work items; while the original change in the GC code has been correct, the associated gtest did double-frees, causing errors. > > The test assumed that ownership of the sub-WorkerDataArray did not transfer, and it is responsible for freeing it. > > This issue has not been caught in the original change because I only did local jtreg testing (which does not include jtreg) for this change separately. CI testing has only been done for this with the follow-up JDK-8235341 included which passed. > > Sorry for this. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235346 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235346/webrev/ > Testing: > hs-tier1-3 > > Thanks, > Thomas From leo.korinth at oracle.com Thu Dec 5 09:52:50 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 5 Dec 2019 10:52:50 +0100 Subject: RFR (S): 8235346: [Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: <71037a60-8ccb-15ec-d34f-3aa4d9878530@oracle.com> References: <71037a60-8ccb-15ec-d34f-3aa4d9878530@oracle.com> Message-ID: <0e3027b3-c45a-9501-b114-0c0ecc282e5b@oracle.com> On 05/12/2019 10:20, Thomas Schatzl wrote: > Hi all, > > ? can I have reviews for this redo for 8235247: WorkerDataArray leaks C > heap memory for associated work items; while the original change in the > GC code has been correct, the associated gtest did double-frees, causing > errors. > > The test assumed that ownership of the sub-WorkerDataArray did not > transfer, and it is responsible for freeing it. This update looks good to me. Thanks, Leo > > This issue has not been caught in the original change because I only did > local jtreg testing (which does not include jtreg) for this change > separately. CI testing has only been done for this with the follow-up > JDK-8235341 included which passed. > > Sorry for this. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235346 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235346/webrev/ > Testing: > hs-tier1-3 > > Thanks, > ? Thomas From stefan.johansson at oracle.com Thu Dec 5 10:10:00 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 5 Dec 2019 11:10:00 +0100 Subject: RFR (S): 8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items In-Reply-To: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> References: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> Message-ID: Hi Thomas, > 5 dec. 2019 kl. 10:27 skrev Thomas Schatzl : > > Hi all, > > can I have reviews for this follow-up change of JDK-8235247 that improves the API about using sub-items in WorkerDataArray to effectively disallow manual handling of them. > > This makes it hopefully clear how to use sub-WorkerDataArrays, and impossible to use them separately, obviating questions about ownership. > > The change is mostly about changing the link_thread_work_items() method to internally construct the sub-WorkerDataArray; this results in a lot of obsolete code that has been removed here. > > This cleanup is followed by a change of the argument order in the WorkerDataArray constructor to make the argument order similar to link/add_thread_work_items(). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235341 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235341/webrev/ Really nice cleanup. Everything looks good, but I would prefer if we renamed add_thread_work_items to create_thread_work_items. Thanks, Stefan > Testing: > hs-tier1-3 > > Thanks, > Thomas From thomas.schatzl at oracle.com Thu Dec 5 10:18:48 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 5 Dec 2019 11:18:48 +0100 Subject: RFR: 8235250: Create (test) abstraction for allocating objects that is immune to removal by optimizations In-Reply-To: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> References: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> Message-ID: <0fc93289-05f1-dd3d-c72e-83452e5fa812@oracle.com> Hi, On 04.12.19 12:32, Leo Korinth wrote: > Hi, > > Please review this change to some tests that is needed for future > optimizations. Reference.reachabilityFence seems not to be usable for > ensuring GC allocations. > > I have added a new abstraction Allocation.blackHole(Object obj) for this. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235250 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8235250/00 > > Testing: > currently running tier 1-3 on linux looks good. Could you file an RFE to look through GC code to replace existing workarounds ("System.out.println(obj);" or others) to this problem with this code? Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 5 10:25:54 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 5 Dec 2019 11:25:54 +0100 Subject: RFR (S): 8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items In-Reply-To: References: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> Message-ID: <9e77b31f-489f-f8ac-a141-25e1cdc02c6b@oracle.com> Hi Stefan, thanks for your review. On 05.12.19 11:10, Stefan Johansson wrote: > Hi Thomas, > >> 5 dec. 2019 kl. 10:27 skrev Thomas Schatzl : >> >> Hi all, >> >> can I have reviews for this follow-up change of JDK-8235247 that improve[...] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235341 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235341/webrev/ > Really nice cleanup. Everything looks good, but I would prefer if we renamed add_thread_work_items to create_thread_work_items. > Fixed: http://cr.openjdk.java.net/~tschatzl/8235341/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8235341/webrev.1/ (full) (In the incremental webrev, the webrev tool somehow messed up with src/hotspot/share/gc/shared/workerDataArray.inline.hpp - the change does not add that file...). The full webrev is okay. Thanks, Thomas From stefan.johansson at oracle.com Thu Dec 5 10:52:10 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 5 Dec 2019 11:52:10 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> Message-ID: Hi Haoyu, Both me and Thomas are good with the current state of the patch and we think it is ready to get pushed. I will push the patch with a "Contributed-by: " line to indicate you are the author of the patch. For that I need to know which email you used when signing the OCA? Is it the same one you are using on these lists: leihouyju at gmail.com Thanks, Stefan > 4 dec. 2019 kl. 17:27 skrev Stefan Johansson : > > > >> 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl : >> >> Hi all, >> >> On 04.12.19 10:47, Haoyu Li wrote: >>> Hi Thomas and Stefan, >>> Thanks for your quick replies. The changes also look great to me, but I noticed that a few more statics and assertions could be improved, so I have updated them in the attached patches. I could have finished these updates earlier. However, there was a network issue that I cannot pull the latest code. Should you have any further suggestions, I am happy to adopt them. >>> Best Regards, >>> Haoyu Li >> >> Merged with your changes. >> >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) >> >> Tests of the previous version were good afaict. >> >> Ready to go imho :) > I agree, > Stefan > >> >> Thomas From leo.korinth at oracle.com Thu Dec 5 11:42:26 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 5 Dec 2019 12:42:26 +0100 Subject: RFR: 8235250: Create (test) abstraction for allocating objects that is immune to removal by optimizations In-Reply-To: <0fc93289-05f1-dd3d-c72e-83452e5fa812@oracle.com> References: <8601fad1-1496-1717-16e9-24d43a32ea50@oracle.com> <0fc93289-05f1-dd3d-c72e-83452e5fa812@oracle.com> Message-ID: <4fe060d1-13e7-7b0e-d3c1-356f8cbf3b28@oracle.com> On 05/12/2019 11:18, Thomas Schatzl wrote: > Hi, > > On 04.12.19 12:32, Leo Korinth wrote: >> Hi, >> >> Please review this change to some tests that is needed for future >> optimizations. Reference.reachabilityFence seems not to be usable for >> ensuring GC allocations. >> >> I have added a new abstraction Allocation.blackHole(Object obj) for this. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235250 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8235250/00 >> >> Testing: >> currently running tier 1-3 on linux > > ? looks good. Could you file an RFE to look through GC code to replace > existing workarounds ("System.out.println(obj);" or others) to this > problem with this code? https://bugs.openjdk.java.net/browse/JDK-8235401 Thank you for your review! /Leo > > Thanks, > ? Thomas > From zgu at redhat.com Thu Dec 5 11:43:25 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 5 Dec 2019 06:43:25 -0500 Subject: RFR 8235262: Move c2i_entry_barrier for x86_32 to shared In-Reply-To: <6067adc1-bfc8-36a5-2fc2-4c19b57d6e63@oracle.com> References: <7d547ffb-031e-fd26-1075-6fdc5c4bf412@redhat.com> <6067adc1-bfc8-36a5-2fc2-4c19b57d6e63@oracle.com> Message-ID: Hi Erik, Updated: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.01/index.html Test: Reran hotspot_gc and submit tests Thanks, -Zhengyu On 12/4/19 9:30 AM, Erik ?sterlund wrote: > Hi Zhengyu, > > Since the 32 bit stuff is just a copy paste of the 64 bit stuff, with > some small tweaks, I think it might be easier to read and maintain if > you tried to merge the two implementations and just do things different > where it is different. > > Thanks, > /Erik > > On 2019-12-04 11:21, Zhengyu Gu wrote: >> When integrating JDK-8230765 [1], I did not integrate >> c2i_entry_barrier. The implementation is not GC specific, should be >> moved to shared. >> >> Again, the implementation is very similar to x86_64 version, except it >> manufactures two temporary registers to act as scratch1 and scratch2 >> registers in x86_64. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235262 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.00/index.html >> >> >> Test: >> ? hotspot_gc (fastdebug and release) with x86_64 and x86_32 JVM on Linux >> ? submit tests >> >> >> Thanks, >> >> -Zhengyu >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230765 >> > From leihouyju at gmail.com Thu Dec 5 12:30:20 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Thu, 5 Dec 2019 20:30:20 +0800 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> Message-ID: Hi Stefan, I used leihouyju at gmail.com when signing my OCA, and it's the same address on these lists. Thanks very much for all your efforts reviewing this patch! Best Regards, Haoyu Li Stefan Johansson ?2019?12?5??? ??6:52??? > Hi Haoyu, > > Both me and Thomas are good with the current state of the patch and we > think it is ready to get pushed. > > I will push the patch with a "Contributed-by: " line to indicate > you are the author of the patch. For that I need to know which email you > used when signing the OCA? Is it the same one you are using on these lists: > leihouyju at gmail.com > > Thanks, > Stefan > > > > 4 dec. 2019 kl. 17:27 skrev Stefan Johansson < > stefan.johansson at oracle.com>: > > > > > > > >> 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl : > >> > >> Hi all, > >> > >> On 04.12.19 10:47, Haoyu Li wrote: > >>> Hi Thomas and Stefan, > >>> Thanks for your quick replies. The changes also look great to me, but > I noticed that a few more statics and assertions could be improved, so I > have updated them in the attached patches. I could have finished these > updates earlier. However, there was a network issue that I cannot pull the > latest code. Should you have any further suggestions, I am happy to adopt > them. > >>> Best Regards, > >>> Haoyu Li > >> > >> Merged with your changes. > >> > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) > >> > >> Tests of the previous version were good afaict. > >> > >> Ready to go imho :) > > I agree, > > Stefan > > > >> > >> Thomas > > From leo.korinth at oracle.com Thu Dec 5 12:45:49 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 5 Dec 2019 13:45:49 +0100 Subject: RFR (S): 8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items In-Reply-To: <9e77b31f-489f-f8ac-a141-25e1cdc02c6b@oracle.com> References: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> <9e77b31f-489f-f8ac-a141-25e1cdc02c6b@oracle.com> Message-ID: On 05/12/2019 11:25, Thomas Schatzl wrote: > Hi Stefan, > > ? thanks for your review. > > On 05.12.19 11:10, Stefan Johansson wrote: >> Hi Thomas, >> >>> 5 dec. 2019 kl. 10:27 skrev Thomas Schatzl : >>> >>> Hi all, >>> >>> ? can I have reviews for this follow-up change of JDK-8235247 that >>> improve[...] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8235341 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8235341/webrev/ >> Really nice cleanup. Everything looks good, but I would prefer if we >> renamed add_thread_work_items to create_thread_work_items. >> Looks great. Thanks, Leo > > Fixed: > > http://cr.openjdk.java.net/~tschatzl/8235341/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8235341/webrev.1/ (full) > > (In the incremental webrev, the webrev tool somehow messed up with > src/hotspot/share/gc/shared/workerDataArray.inline.hpp - the change does > not add that file...). The full webrev is okay. > > Thanks, > ? Thomas From stefan.johansson at oracle.com Thu Dec 5 12:49:50 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 5 Dec 2019 13:49:50 +0100 Subject: RFR (S): 8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items In-Reply-To: <9e77b31f-489f-f8ac-a141-25e1cdc02c6b@oracle.com> References: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> <9e77b31f-489f-f8ac-a141-25e1cdc02c6b@oracle.com> Message-ID: > 5 dec. 2019 kl. 11:25 skrev Thomas Schatzl : > > Hi Stefan, > > thanks for your review. > > On 05.12.19 11:10, Stefan Johansson wrote: >> Hi Thomas, >>> 5 dec. 2019 kl. 10:27 skrev Thomas Schatzl : >>> >>> Hi all, >>> >>> can I have reviews for this follow-up change of JDK-8235247 that improve[...] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8235341 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8235341/webrev/ >> Really nice cleanup. Everything looks good, but I would prefer if we renamed add_thread_work_items to create_thread_work_items. > > Fixed: > > http://cr.openjdk.java.net/~tschatzl/8235341/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8235341/webrev.1/ (full) > Looks good, StefanJ > (In the incremental webrev, the webrev tool somehow messed up with src/hotspot/share/gc/shared/workerDataArray.inline.hpp - the change does not add that file...). The full webrev is okay. > > Thanks, > Thomas From thomas.schatzl at oracle.com Thu Dec 5 13:00:02 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 5 Dec 2019 14:00:02 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> Message-ID: <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> Hi Stefan, On 03.12.19 19:21, Stefan Johansson wrote:> Hi Thomas, > > Thanks for taking a look. > > On 2019-11-29 11:55, Thomas Schatzl wrote: >> Hi, >> On 26.11.19 16:01, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this fix to improve freeing the collection set when >>> having a lot of regions. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8165443 >>> Webrev: http://cr.openjdk.java.net/~sjohanss/8165443/00/ >>>[...] >> - HeapRegionManager::is_available() is (mostly) meant as internal >> function, but due to assert'ing I was forced to make it public >> (probably should have a non-public version and a public one that is >> only available with assertions). >> The use in G1RebuildFreeListTask::work() kind of violates this idea >> (and sorry for not mentioning it anywhere in the code). > > This was just a very small optimization instead of using at_or_null(), > so reverted back to use that one. Okay :) > >> Maybe move the entire freelist rebuild task into HeapRegionManager >> where it imho fits much better? HeapRegionManager is and should be >> the "owner" of the free list. The call to >> HeapRegion::unlink_from_list() can probably be made earlier, or see >> below. >> - another change I do not really like is the difference between >> "abandoning" the free list (and then later clearing the HeapRegion >> links in parallel) and "removing" the free list. >> While it makes sense from a performance POV, I would be happier if we >> could get away without introducing this tiny semantic difference. >> An option would be that there were a FreeRegionList::add_to_tail that >> just overwrites the links. This would remove the need for the new >> "abandon" and other support methods in a few places and hide the >> ugliness there. >> What do you think? > > Discussed this a bit with Thomas offline and we both agree that there > can be further cleanups improvements here, but I think we agreed on > just moving stuff into the HeapRegionManager but keep the added > concepts. We both agree that having both remove_all and abandon for > the freelist is not good in the long run, but getting rid of > remove_all or fix remove_all to perform well is out of scope for this > enhancement. > Fine with me. >> - while you mentioned that you did not look into balancing the work >> for the rebuild free list action, but please limit the workers in the >> G1RebuildFreeListTask by at least the number of regions in the heap. >> (Move the chunk sizing outside of the G1RebuildFreeListTask for >> that.) > > Added a clamp to make sure we never use more workers than we have > regions, even though in most cases this should never happen. > >> - instead of workers()->run_task() please use >> G1CollectedHeap::run_task(). That also removes some timing code for >> you around these places :) > > Can?t use that one since I need to time the destructor of the task as > well. > Okay. > > Here are the updated webrevs: > Full: http://cr.openjdk.java.net/~sjohanss/8165443/01/ > Inc: http://cr.openjdk.java.net/~sjohanss/8165443/00-01/ > Some more nits (sorry for not mentioning these in the first review - I was a bit distracted by the placement of the rebuild-free-list code): - HeapRegionManager::abandon_free_list should be private, and the implementation could easily be moved to the cpp file. Also HRM::append_to_free_list. I would probably just manually inline these two one-liner methods though. - G1Collectionset::iterate_part_from can be private - I think there will be some merge errors with latest changes (i.e. the update to the WorkerDataArray at least) - heapRegionManager.hpp: please move G1RebuildFreeListTask into the cpp file. It is only ever used there. This allows undo of the changes to the includes in the hpp file too. - in G1FreeCollectionSetClosure::handle_evacuated_region, the code could remove the call to clear_remset_locked() and set the skip_remset parameter of the free_region call to false. Since this seems to have been the only case of the skip_remset==true, the parameter can be removed. Also the "locked" parameter seems to be always true (now?), so this one can be removed too. The removal of these parameters propagates a bit, but that would reduce complexity of related methods quite a bit :) Please add an is_at_safepoint() or so call there then. I am open to moving this to a separate follow-up RFE, but it does not seem that big of a change, and I think it makes the code easier to understand. - (this is imho) in the method FreeCSetStats::update_used_before() and FreeCSetStats::increment_regions_freed() are always called together I recommend merging them. To me it distracts a bit from the flow of the code with details (given that you already added methods to the FreeCSetStats class). I would also merge the calls to update_failure_used/update_failure_waste/update_used_after in handle_failed_region. Looks good otherwise. Thanks, Thomas From stefan.johansson at oracle.com Thu Dec 5 13:21:50 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 5 Dec 2019 14:21:50 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> Message-ID: <24B88E5F-FEFD-48AD-8FA3-1FFDF2C96AA3@oracle.com> Thanks Haoyu, I will probably push this tomorrow, running it through some more testing. Cheers, Stefan > 5 dec. 2019 kl. 13:30 skrev Haoyu Li : > > Hi Stefan, > > I used leihouyju at gmail.com when signing my OCA, and it's the same address on these lists. Thanks very much for all your efforts reviewing this patch! > > Best Regards, > Haoyu Li > > > Stefan Johansson ?2019?12?5??? ??6:52??? > Hi Haoyu, > > Both me and Thomas are good with the current state of the patch and we think it is ready to get pushed. > > I will push the patch with a "Contributed-by: " line to indicate you are the author of the patch. For that I need to know which email you used when signing the OCA? Is it the same one you are using on these lists: leihouyju at gmail.com > > Thanks, > Stefan > > > > 4 dec. 2019 kl. 17:27 skrev Stefan Johansson : > > > > > > > >> 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl : > >> > >> Hi all, > >> > >> On 04.12.19 10:47, Haoyu Li wrote: > >>> Hi Thomas and Stefan, > >>> Thanks for your quick replies. The changes also look great to me, but I noticed that a few more statics and assertions could be improved, so I have updated them in the attached patches. I could have finished these updates earlier. However, there was a network issue that I cannot pull the latest code. Should you have any further suggestions, I am happy to adopt them. > >>> Best Regards, > >>> Haoyu Li > >> > >> Merged with your changes. > >> > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) > >> > >> Tests of the previous version were good afaict. > >> > >> Ready to go imho :) > > I agree, > > Stefan > > > >> > >> Thomas > From leihouyju at gmail.com Thu Dec 5 14:59:31 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Thu, 5 Dec 2019 22:59:31 +0800 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <24B88E5F-FEFD-48AD-8FA3-1FFDF2C96AA3@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> <24B88E5F-FEFD-48AD-8FA3-1FFDF2C96AA3@oracle.com> Message-ID: Thanks Stefan, If there are any issues in the test, please feel free to contact me! Best Regards, Haoyu Li Stefan Johansson ?2019?12?5??? ??9:24??? > Thanks Haoyu, > > I will probably push this tomorrow, running it through some more testing. > > Cheers, > Stefan > > > 5 dec. 2019 kl. 13:30 skrev Haoyu Li : > > > > Hi Stefan, > > > > I used leihouyju at gmail.com when signing my OCA, and it's the same > address on these lists. Thanks very much for all your efforts reviewing > this patch! > > > > Best Regards, > > Haoyu Li > > > > > > Stefan Johansson ?2019?12?5??? ??6:52??? > > Hi Haoyu, > > > > Both me and Thomas are good with the current state of the patch and we > think it is ready to get pushed. > > > > I will push the patch with a "Contributed-by: " line to indicate > you are the author of the patch. For that I need to know which email you > used when signing the OCA? Is it the same one you are using on these lists: > leihouyju at gmail.com > > > > Thanks, > > Stefan > > > > > > > 4 dec. 2019 kl. 17:27 skrev Stefan Johansson < > stefan.johansson at oracle.com>: > > > > > > > > > > > >> 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl >: > > >> > > >> Hi all, > > >> > > >> On 04.12.19 10:47, Haoyu Li wrote: > > >>> Hi Thomas and Stefan, > > >>> Thanks for your quick replies. The changes also look great to me, > but I noticed that a few more statics and assertions could be improved, so > I have updated them in the attached patches. I could have finished these > updates earlier. However, there was a network issue that I cannot pull the > latest code. Should you have any further suggestions, I am happy to adopt > them. > > >>> Best Regards, > > >>> Haoyu Li > > >> > > >> Merged with your changes. > > >> > > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) > > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) > > >> > > >> Tests of the previous version were good afaict. > > >> > > >> Ready to go imho :) > > > I agree, > > > Stefan > > > > > >> > > >> Thomas > > > > From stefan.johansson at oracle.com Thu Dec 5 18:27:41 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 5 Dec 2019 19:27:41 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> Message-ID: Hi Thomas, > 5 dec. 2019 kl. 14:00 skrev Thomas Schatzl : > > Hi Stefan, > > On 03.12.19 19:21, Stefan Johansson wrote:> Hi Thomas, > > > > Thanks for taking a look. > > > > On 2019-11-29 11:55, Thomas Schatzl wrote: > >> Hi, > >> On 26.11.19 16:01, Stefan Johansson wrote: > >>> Hi, > >>> > >>> Please review this fix to improve freeing the collection set when > >>> having a lot of regions. > >>> > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8165443 > >>> Webrev: http://cr.openjdk.java.net/~sjohanss/8165443/00/ > >>>[...] > >> - HeapRegionManager::is_available() is (mostly) meant as internal > >> function, but due to assert'ing I was forced to make it public > >> (probably should have a non-public version and a public one that is > >> only available with assertions). > >> The use in G1RebuildFreeListTask::work() kind of violates this idea > >> (and sorry for not mentioning it anywhere in the code). > > > > This was just a very small optimization instead of using at_or_null(), > > so reverted back to use that one. > > Okay :) > > > > >> Maybe move the entire freelist rebuild task into HeapRegionManager > >> where it imho fits much better? HeapRegionManager is and should be > >> the "owner" of the free list. The call to > >> HeapRegion::unlink_from_list() can probably be made earlier, or see > >> below. > >> - another change I do not really like is the difference between > >> "abandoning" the free list (and then later clearing the HeapRegion > >> links in parallel) and "removing" the free list. > >> While it makes sense from a performance POV, I would be happier if we > >> could get away without introducing this tiny semantic difference. > >> An option would be that there were a FreeRegionList::add_to_tail that > >> just overwrites the links. This would remove the need for the new > >> "abandon" and other support methods in a few places and hide the > >> ugliness there. > >> What do you think? > > > > Discussed this a bit with Thomas offline and we both agree that there > > can be further cleanups improvements here, but I think we agreed on > > just moving stuff into the HeapRegionManager but keep the added > > concepts. We both agree that having both remove_all and abandon for > > the freelist is not good in the long run, but getting rid of > > remove_all or fix remove_all to perform well is out of scope for this > > enhancement. > > > > Fine with me. > > >> - while you mentioned that you did not look into balancing the work > >> for the rebuild free list action, but please limit the workers in the > >> G1RebuildFreeListTask by at least the number of regions in the heap. > >> (Move the chunk sizing outside of the G1RebuildFreeListTask for > >> that.) > > > > Added a clamp to make sure we never use more workers than we have > > regions, even though in most cases this should never happen. > > > >> - instead of workers()->run_task() please use > >> G1CollectedHeap::run_task(). That also removes some timing code for > >> you around these places :) > > > > Can?t use that one since I need to time the destructor of the task as > > well. > > > > Okay. > > > > > Here are the updated webrevs: > > Full: http://cr.openjdk.java.net/~sjohanss/8165443/01/ > > Inc: http://cr.openjdk.java.net/~sjohanss/8165443/00-01/ > > > > Some more nits (sorry for not mentioning these in the first review - I was a bit distracted by the placement of the rebuild-free-list code): > No problem =) > - HeapRegionManager::abandon_free_list should be private, and the implementation could easily be moved to the cpp file. > Also HRM::append_to_free_list. > > I would probably just manually inline these two one-liner methods though. I agree, no need for the wrappers now when everything lives in HRM. > > - G1Collectionset::iterate_part_from can be private Fixed. > > - I think there will be some merge errors with latest changes (i.e. the update to the WorkerDataArray at least) Yes, I will take care of those when I rebase. > > - heapRegionManager.hpp: please move G1RebuildFreeListTask into the cpp file. It is only ever used there. This allows undo of the changes to the includes in the hpp file too. Good catch. > > - in G1FreeCollectionSetClosure::handle_evacuated_region, the code could remove the call to clear_remset_locked() and set the skip_remset parameter of the free_region call to false. Since this seems to have been the only case of the skip_remset==true, the parameter can be removed. > Also the "locked" parameter seems to be always true (now?), so this one can be removed too. The removal of these parameters propagates a bit, but that would reduce complexity of related methods quite a bit :) I removed the explicit call to clear_remset_locked() and changed the parameter to false. I think this is a good change for this patch. > > Please add an is_at_safepoint() or so call there then. > > I am open to moving this to a separate follow-up RFE, but it does not seem that big of a change, and I think it makes the code easier to understand. I think the rest of this should be handled separately in follow up, filed: https://bugs.openjdk.java.net/browse/JDK-8235427 > > - (this is imho) in the method FreeCSetStats::update_used_before() and > FreeCSetStats::increment_regions_freed() are always called together I recommend merging them. To me it distracts a bit from the flow of the code with details (given that you already added methods to the FreeCSetStats class). I would also merge the calls to update_failure_used/update_failure_waste/update_used_after in handle_failed_region. I like this suggestion and I renamed the functions a bit too. > > Looks good otherwise. Thanks, here are updated webrevs: Full: http://cr.openjdk.java.net/~sjohanss/8165443/02/ Inc: http://cr.openjdk.java.net/~sjohanss/8165443/01-02/ Thanks, Stefan > > Thanks, > Thomas > From vladimir.kozlov at oracle.com Thu Dec 5 19:16:37 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 Dec 2019 11:16:37 -0800 Subject: [14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses In-Reply-To: <0b821ef8-90ec-28e3-2008-ec999af7e87a@oracle.com> References: <0b821ef8-90ec-28e3-2008-ec999af7e87a@oracle.com> Message-ID: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> CCing to GC group. Looks fine to me but someone from GC land have to look too. I wish we have more concrete indication for off-heap access instead of guessing it based on how we address memory through Unsafe API. Thanks, Vladimir On 11/29/19 7:42 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8226411/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8226411 > > There were a number of fixes in C2 support for unsafe accesses recently which led to additional memory barriers around > them. It improved stability, but in some cases it was redundant. One of important use cases which regressed is off-heap > accesses [1]. The barriers around them are redundant because they are serialized on raw memory and don't intersect with > any on-heap accesses. > > Proposed fix skips memory barriers around unsafe accesses which are provably off-heap (base == NULL). > > It (almost completely) recovers performance on the microbenchmark provided in JDK-8224182 [1]. > > Testing: tier1-6. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8224182 From erik.osterlund at oracle.com Thu Dec 5 20:14:59 2019 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 5 Dec 2019 21:14:59 +0100 Subject: [14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses In-Reply-To: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> References: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> Message-ID: Hi, Could we use the existing IN_NATIVE decorator instead of introducing a new decorator that seems to be an alias for the same thing? The decorator describing its use (IN_NATIVE) says it is for off-heap accesses pointing into the heap. We can just remove from the comment the part presuming it is a reference. What do you think? Thanks, /Erik > On 5 Dec 2019, at 20:16, Vladimir Kozlov wrote: > > ?CCing to GC group. > > Looks fine to me but someone from GC land have to look too. > > I wish we have more concrete indication for off-heap access instead of guessing it based on how we address memory through Unsafe API. > > Thanks, > Vladimir > >> On 11/29/19 7:42 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8226411/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8226411 >> There were a number of fixes in C2 support for unsafe accesses recently which led to additional memory barriers around them. It improved stability, but in some cases it was redundant. One of important use cases which regressed is off-heap accesses [1]. The barriers around them are redundant because they are serialized on raw memory and don't intersect with any on-heap accesses. >> Proposed fix skips memory barriers around unsafe accesses which are provably off-heap (base == NULL). >> It (almost completely) recovers performance on the microbenchmark provided in JDK-8224182 [1]. >> Testing: tier1-6. >> Best regards, >> Vladimir Ivanov >> [1] https://bugs.openjdk.java.net/browse/JDK-8224182 From thomas.schatzl at oracle.com Thu Dec 5 20:38:36 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 05 Dec 2019 21:38:36 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> Message-ID: Hi Stefan, On Thu, 2019-12-05 at 19:27 +0100, Stefan Johansson wrote: > Hi Thomas, > > > 5 dec. 2019 kl. 14:00 skrev Thomas Schatzl < > > thomas.schatzl at oracle.com>: > > > > Hi Stefan, > > > > [...] > > - in G1FreeCollectionSetClosure::handle_evacuated_region, the code > > could remove the call to clear_remset_locked() and set the > > skip_remset parameter of the free_region call to false. Since this > > seems to have been the only case of the skip_remset==true, the > > parameter can be removed. > > Also the "locked" parameter seems to be always true (now?), so this > > one can be removed too. The removal of these parameters propagates > > a bit, but that would reduce complexity of related methods quite a > > bit :) > > I removed the explicit call to clear_remset_locked() and changed the > parameter to false. I think this is a good change for this patch. :) > > > > > Please add an is_at_safepoint() or so call there then. > > > > I am open to moving this to a separate follow-up RFE, but it does > > not seem that big of a change, and I think it makes the code easier > > to understand. > > I think the rest of this should be handled separately in follow up, > filed: https://bugs.openjdk.java.net/browse/JDK-8235427 Good. > > > > > - (this is imho) in the method FreeCSetStats::update_used_before() > > and > > FreeCSetStats::increment_regions_freed() are always called together > > I recommend merging them. To me it distracts a bit from the flow of > > the code with details (given that you already added methods to the > > FreeCSetStats class). I would also merge the calls to > > update_failure_used/update_failure_waste/update_used_after in > > handle_failed_region. > > I like this suggestion and I renamed the functions a bit too. > > > > > Looks good otherwise. > > Thanks, here are updated webrevs: > Full: http://cr.openjdk.java.net/~sjohanss/8165443/02/ > Inc: http://cr.openjdk.java.net/~sjohanss/8165443/01-02/ looks good. Thomas From kim.barrett at oracle.com Fri Dec 6 00:33:11 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Dec 2019 19:33:11 -0500 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> Message-ID: <39546A96-D638-4C54-A92B-7995B3F112EB@oracle.com> > On Dec 5, 2019, at 1:27 PM, Stefan Johansson wrote: > Thanks, here are updated webrevs: > Full: http://cr.openjdk.java.net/~sjohanss/8165443/02/ > Inc: http://cr.openjdk.java.net/~sjohanss/8165443/01-02/ Looks good. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.cpp 4207 class G1FreeCollectionSetClosure : public HeapRegionClosure { Since it's a nested class, it could be called FreeCSetClosure, to be similar to FreeCSetStats. Just a suggestion. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/heapRegionManager.cpp 680 uint const num_workers = clamp(max_length(), 1u, workers->active_workers()); Maybe this was already discussed, but it looks to me that the cost per region for the rebuild task is pretty low, so that it might be that this should use one thread per N regions, N > 1. So use "max_length() / N". I don't know what N should be. For a similar case in reference processing we added the experimental option ReferencesPerThread with a default value of 1000. (Note that I'm not encouraging the addition of an option here.) This should probably be deferred for further experimentation and measurement. ------------------------------------------------------------------------------ From stefan.johansson at oracle.com Fri Dec 6 09:53:06 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 6 Dec 2019 10:53:06 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: <39546A96-D638-4C54-A92B-7995B3F112EB@oracle.com> References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> <39546A96-D638-4C54-A92B-7995B3F112EB@oracle.com> Message-ID: <09EE050F-2068-475E-B1FD-31B4C89B5388@oracle.com> Hi Kim, > 6 dec. 2019 kl. 01:33 skrev Kim Barrett : > >> On Dec 5, 2019, at 1:27 PM, Stefan Johansson wrote: >> Thanks, here are updated webrevs: >> Full: http://cr.openjdk.java.net/~sjohanss/8165443/02/ >> Inc: http://cr.openjdk.java.net/~sjohanss/8165443/01-02/ > > Looks good. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/g1/g1CollectedHeap.cpp > 4207 class G1FreeCollectionSetClosure : public HeapRegionClosure { > > Since it's a nested class, it could be called FreeCSetClosure, to be > similar to FreeCSetStats. Just a suggestion. > I like to keep names similar, so I changed this as you suggested. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/g1/heapRegionManager.cpp > 680 uint const num_workers = clamp(max_length(), 1u, workers->active_workers()); > > Maybe this was already discussed, but it looks to me that the cost per > region for the rebuild task is pretty low, so that it might be that > this should use one thread per N regions, N > 1. So use "max_length() > / N". I don't know what N should be. For a similar case in reference > processing we added the experimental option ReferencesPerThread with a > default value of 1000. (Note that I'm not encouraging the addition of > an option here.) > > This should probably be deferred for further experimentation and measurement. Yes, I mentioned that I didn?t add any heuristic for this and I agree that one worker per region is to much, and in most cases we will already have fewer active workers for small heaps, this clamp was just a way to make sure we don?t have more workers than ever needed. I also agree that we could do some experiments and see if we can come up with a better way to size the number of threads here, but for now I think this is ok. New webrev, full one also contain a change to work with latest WorkerDataArray changes: Full: http://cr.openjdk.java.net/~sjohanss/8165443/03/ Inc: http://cr.openjdk.java.net/~sjohanss/8165443/02-03/ Thanks for the review, Stefan > > ------------------------------------------------------------------------------ > From thomas.schatzl at oracle.com Fri Dec 6 10:29:45 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 6 Dec 2019 11:29:45 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: <09EE050F-2068-475E-B1FD-31B4C89B5388@oracle.com> References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> <39546A96-D638-4C54-A92B-7995B3F112EB@oracle.com> <09EE050F-2068-475E-B1FD-31B4C89B5388@oracle.com> Message-ID: <6e65f9a5-16a0-5e8b-999e-b865e3d3377f@oracle.com> Hi Stefan, still looks good. Thomas From thomas.schatzl at oracle.com Fri Dec 6 10:38:08 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 6 Dec 2019 11:38:08 +0100 Subject: RFR (S): 8235346: [Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items In-Reply-To: References: <71037a60-8ccb-15ec-d34f-3aa4d9878530@oracle.com> Message-ID: Hi Stefan and Leo, On 05.12.19 10:41, Stefan Johansson wrote: > Looks good, > StefanJ thanks for your reviews. Thomas From thomas.schatzl at oracle.com Fri Dec 6 10:37:26 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 6 Dec 2019 11:37:26 +0100 Subject: RFR (S): 8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items In-Reply-To: References: <36863e67-4a80-2973-d2bb-ff37470ffda6@oracle.com> <9e77b31f-489f-f8ac-a141-25e1cdc02c6b@oracle.com> Message-ID: Hi Stefan and Leo, thanks for your reviews. Thomas On 05.12.19 13:49, Stefan Johansson wrote: > > >> 5 dec. 2019 kl. 11:25 skrev Thomas Schatzl : >> >> Hi Stefan, >> >> thanks for your review. >> >> On 05.12.19 11:10, Stefan Johansson wrote: >>> Hi Thomas, >>>> 5 dec. 2019 kl. 10:27 skrev Thomas Schatzl : >>>> >>>> Hi all, >>>> >>>> can I have reviews for this follow-up change of JDK-8235247 that improve[...] >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8235341 >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8235341/webrev/ >>> Really nice cleanup. Everything looks good, but I would prefer if we renamed add_thread_work_items to create_thread_work_items. >> >> Fixed: >> >> http://cr.openjdk.java.net/~tschatzl/8235341/webrev.0_to_1 (diff) >> http://cr.openjdk.java.net/~tschatzl/8235341/webrev.1/ (full) >> > Looks good, > StefanJ > >> (In the incremental webrev, the webrev tool somehow messed up with src/hotspot/share/gc/shared/workerDataArray.inline.hpp - the change does not add that file...). The full webrev is okay. >> >> Thanks, >> Thomas > From stefan.johansson at oracle.com Fri Dec 6 11:48:55 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 6 Dec 2019 12:48:55 +0100 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> <24B88E5F-FEFD-48AD-8FA3-1FFDF2C96AA3@oracle.com> Message-ID: <8B1E991E-1049-478A-97F5-E9966030397D@oracle.com> Hi Haoyu, Your contribution has now been pushed and it will run through our testing over the weekend. I?ll let you know if we see any problems but I don?t think we will, both me and Thomas have to some significant testing already. If you are interested in becoming more involved in OpenJDK you are now just one more contribution away from being able to request an OpenJDK username and become an Author. More information can be found here: https://openjdk.java.net/projects/ Cheers, Stefan > 5 dec. 2019 kl. 15:59 skrev Haoyu Li : > > Thanks Stefan, > > If there are any issues in the test, please feel free to contact me! > > Best Regards, > Haoyu Li > > > Stefan Johansson ?2019?12?5??? ??9:24??? > Thanks Haoyu, > > I will probably push this tomorrow, running it through some more testing. > > Cheers, > Stefan > > > 5 dec. 2019 kl. 13:30 skrev Haoyu Li : > > > > Hi Stefan, > > > > I used leihouyju at gmail.com when signing my OCA, and it's the same address on these lists. Thanks very much for all your efforts reviewing this patch! > > > > Best Regards, > > Haoyu Li > > > > > > Stefan Johansson ?2019?12?5??? ??6:52??? > > Hi Haoyu, > > > > Both me and Thomas are good with the current state of the patch and we think it is ready to get pushed. > > > > I will push the patch with a "Contributed-by: " line to indicate you are the author of the patch. For that I need to know which email you used when signing the OCA? Is it the same one you are using on these lists: leihouyju at gmail.com > > > > Thanks, > > Stefan > > > > > > > 4 dec. 2019 kl. 17:27 skrev Stefan Johansson : > > > > > > > > > > > >> 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl : > > >> > > >> Hi all, > > >> > > >> On 04.12.19 10:47, Haoyu Li wrote: > > >>> Hi Thomas and Stefan, > > >>> Thanks for your quick replies. The changes also look great to me, but I noticed that a few more statics and assertions could be improved, so I have updated them in the attached patches. I could have finished these updates earlier. However, there was a network issue that I cannot pull the latest code. Should you have any further suggestions, I am happy to adopt them. > > >>> Best Regards, > > >>> Haoyu Li > > >> > > >> Merged with your changes. > > >> > > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) > > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) > > >> > > >> Tests of the previous version were good afaict. > > >> > > >> Ready to go imho :) > > > I agree, > > > Stefan > > > > > >> > > >> Thomas > > > From leihouyju at gmail.com Fri Dec 6 11:59:16 2019 From: leihouyju at gmail.com (Haoyu Li) Date: Fri, 6 Dec 2019 19:59:16 +0800 Subject: RFR: 8220465: Use shadow regions for faster ParallelGC full GCs In-Reply-To: <8B1E991E-1049-478A-97F5-E9966030397D@oracle.com> References: <7ac0dde2-a32d-a641-d5ed-88c9f5fd8157@oracle.com> <88ECD3FD-485D-4633-B4EE-DF10BC5F3AFB@oracle.com> <72b9788d-457a-592d-38ce-40ea5b8b9a3d@oracle.com> <76715160-e11e-e50e-f1c8-da692b133309@oracle.com> <935d97e5-4a9f-cf11-c187-ae28de54564a@oracle.com> <123C7198-C959-48A8-A012-047ECBE07E01@oracle.com> <24B88E5F-FEFD-48AD-8FA3-1FFDF2C96AA3@oracle.com> <8B1E991E-1049-478A-97F5-E9966030397D@oracle.com> Message-ID: Hi Stefan, Awesome! Thanks for the update. I am happy to address problems in the testing, if any. I will also keep researching the OpenJDK in the futher. Thanks for your information regarding the Author and all your time reviewing this patch. Best Regards, Haoyu Li Stefan Johansson ?2019?12?6??? ??7:49??? > Hi Haoyu, > > Your contribution has now been pushed and it will run through our testing > over the weekend. I?ll let you know if we see any problems but I don?t > think we will, both me and Thomas have to some significant testing already. > > If you are interested in becoming more involved in OpenJDK you are now > just one more contribution away from being able to request an OpenJDK > username and become an Author. More information can be found here: > https://openjdk.java.net/projects/ > > Cheers, > Stefan > > > 5 dec. 2019 kl. 15:59 skrev Haoyu Li : > > > > Thanks Stefan, > > > > If there are any issues in the test, please feel free to contact me! > > > > Best Regards, > > Haoyu Li > > > > > > Stefan Johansson ?2019?12?5??? ??9:24??? > > Thanks Haoyu, > > > > I will probably push this tomorrow, running it through some more testing. > > > > Cheers, > > Stefan > > > > > 5 dec. 2019 kl. 13:30 skrev Haoyu Li : > > > > > > Hi Stefan, > > > > > > I used leihouyju at gmail.com when signing my OCA, and it's the same > address on these lists. Thanks very much for all your efforts reviewing > this patch! > > > > > > Best Regards, > > > Haoyu Li > > > > > > > > > Stefan Johansson ?2019?12?5??? ??6:52??? > > > Hi Haoyu, > > > > > > Both me and Thomas are good with the current state of the patch and we > think it is ready to get pushed. > > > > > > I will push the patch with a "Contributed-by: " line to > indicate you are the author of the patch. For that I need to know which > email you used when signing the OCA? Is it the same one you are using on > these lists: leihouyju at gmail.com > > > > > > Thanks, > > > Stefan > > > > > > > > > > 4 dec. 2019 kl. 17:27 skrev Stefan Johansson < > stefan.johansson at oracle.com>: > > > > > > > > > > > > > > > >> 4 dec. 2019 kl. 16:55 skrev Thomas Schatzl < > thomas.schatzl at oracle.com>: > > > >> > > > >> Hi all, > > > >> > > > >> On 04.12.19 10:47, Haoyu Li wrote: > > > >>> Hi Thomas and Stefan, > > > >>> Thanks for your quick replies. The changes also look great to me, > but I noticed that a few more statics and assertions could be improved, so > I have updated them in the attached patches. I could have finished these > updates earlier. However, there was a network issue that I cannot pull the > latest code. Should you have any further suggestions, I am happy to adopt > them. > > > >>> Best Regards, > > > >>> Haoyu Li > > > >> > > > >> Merged with your changes. > > > >> > > > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7_to_8/ (diff) > > > >> http://cr.openjdk.java.net/~tschatzl/8220465/webrev.8/ (full) > > > >> > > > >> Tests of the previous version were good afaict. > > > >> > > > >> Ready to go imho :) > > > > I agree, > > > > Stefan > > > > > > > >> > > > >> Thomas > > > > > > > From vladimir.x.ivanov at oracle.com Fri Dec 6 15:19:58 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 Dec 2019 18:19:58 +0300 Subject: [14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses In-Reply-To: References: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> Message-ID: <015f0c8a-37f0-e603-e644-7a51195c4ad2@oracle.com> Hi Erik, I like your idea. Here's updated version: http://cr.openjdk.java.net/~vlivanov/8226411/webrev.01 While browsing the code, I noticed that changes in G1BarrierSetC2::load_at_resolved() aren't required (need_cpu_mem_bar is used for oop case). But I decided to keep them to keep it (relatively) close to C2Access::needs_cpu_membar(). Best regards, Vladimir Ivanov On 05.12.2019 23:14, Erik ?sterlund wrote: > Hi, > > Could we use the existing IN_NATIVE decorator instead of introducing a new decorator that seems to be an alias for the same thing? The decorator describing its use (IN_NATIVE) says it is for off-heap accesses pointing into the heap. We can just remove from the comment the part presuming it is a reference. > > What do you think? > > Thanks, > /Erik > >> On 5 Dec 2019, at 20:16, Vladimir Kozlov wrote: >> >> ?CCing to GC group. >> >> Looks fine to me but someone from GC land have to look too. >> >> I wish we have more concrete indication for off-heap access instead of guessing it based on how we address memory through Unsafe API. >> >> Thanks, >> Vladimir >> >>> On 11/29/19 7:42 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8226411/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8226411 >>> There were a number of fixes in C2 support for unsafe accesses recently which led to additional memory barriers around them. It improved stability, but in some cases it was redundant. One of important use cases which regressed is off-heap accesses [1]. The barriers around them are redundant because they are serialized on raw memory and don't intersect with any on-heap accesses. >>> Proposed fix skips memory barriers around unsafe accesses which are provably off-heap (base == NULL). >>> It (almost completely) recovers performance on the microbenchmark provided in JDK-8224182 [1]. >>> Testing: tier1-6. >>> Best regards, >>> Vladimir Ivanov >>> [1] https://bugs.openjdk.java.net/browse/JDK-8224182 > From erik.osterlund at oracle.com Fri Dec 6 17:05:57 2019 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Fri, 6 Dec 2019 18:05:57 +0100 Subject: RFR 8235262: Move c2i_entry_barrier for x86_32 to shared In-Reply-To: References: Message-ID: <9E9D221C-446B-4C21-B310-2DA153567D13@oracle.com> Hi Zhengyu, Looks good. Thanks, /Erik > On 5 Dec 2019, at 12:43, Zhengyu Gu wrote: > > ?Hi Erik, > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.01/index.html > > Test: > Reran hotspot_gc and submit tests > > > Thanks, > > -Zhengyu > >> On 12/4/19 9:30 AM, Erik ?sterlund wrote: >> Hi Zhengyu, >> Since the 32 bit stuff is just a copy paste of the 64 bit stuff, with some small tweaks, I think it might be easier to read and maintain if you tried to merge the two implementations and just do things different where it is different. >> Thanks, >> /Erik >>> On 2019-12-04 11:21, Zhengyu Gu wrote: >>> When integrating JDK-8230765 [1], I did not integrate c2i_entry_barrier. The implementation is not GC specific, should be moved to shared. >>> >>> Again, the implementation is very similar to x86_64 version, except it manufactures two temporary registers to act as scratch1 and scratch2 registers in x86_64. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235262 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235262/webrev.00/index.html >>> >>> >>> Test: >>> hotspot_gc (fastdebug and release) with x86_64 and x86_32 JVM on Linux >>> submit tests >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230765 >>> > From kim.barrett at oracle.com Fri Dec 6 20:25:23 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 6 Dec 2019 15:25:23 -0500 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: <09EE050F-2068-475E-B1FD-31B4C89B5388@oracle.com> References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> <39546A96-D638-4C54-A92B-7995B3F112EB@oracle.com> <09EE050F-2068-475E-B1FD-31B4C89B5388@oracle.com> Message-ID: > On Dec 6, 2019, at 4:53 AM, Stefan Johansson wrote: > Yes, I mentioned that I didn?t add any heuristic for this and I agree that one worker per region is to much, and in most cases we will already have fewer active workers for small heaps, this clamp was just a way to make sure we don?t have more workers than ever needed. > > I also agree that we could do some experiments and see if we can come up with a better way to size the number of threads here, but for now I think this is ok. > > New webrev, full one also contain a change to work with latest WorkerDataArray changes: > Full: http://cr.openjdk.java.net/~sjohanss/8165443/03/ > Inc: http://cr.openjdk.java.net/~sjohanss/8165443/02-03/ Looks good. From per.liden at oracle.com Mon Dec 9 09:17:10 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 9 Dec 2019 10:17:10 +0100 Subject: RFR: 8234654: ZGC: Only disarm NMethods when marking/relocating code roots In-Reply-To: References: <46674d77-9ae7-82e5-0572-77fc44f0c8c7@oracle.com> <30503437-ee40-a924-d7fa-8ed5787adf52@oracle.com> Message-ID: <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> Here's an updated webrev, which removes the "assert(is_armed, ...)" BarrierSetNMethod::disarm(), as it's a bit too strict. Also, added the "if (ZNMethod::is_armed(nm))" to the ZNMethodUnlinkClosure, so avoid walking to oops if it's already disarmed. http://cr.openjdk.java.net/~pliden/8234654/webrev.1 /Per On 11/22/19 3:38 PM, Per Liden wrote: > Thanks Erik! > > /Per > > On 11/22/19 3:35 PM, erik.osterlund at oracle.com wrote: >> Hi Per, >> >> Looks good. >> >> Thanks, >> /Erik >> >> On 11/22/19 3:03 PM, Per Liden wrote: >>> ZRootIterator will currently always try to disarm on-stack NMethods. >>> Strictly speaking, we should only do this when marking/relocating >>> code roots, not when e.g. iterating the heap. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234654 >>> Webrev: http://cr.openjdk.java.net/~pliden/8234654/webrev.0 >>> >>> /Per >> From erik.osterlund at oracle.com Mon Dec 9 09:26:37 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 9 Dec 2019 10:26:37 +0100 Subject: RFR: 8234654: ZGC: Only disarm NMethods when marking/relocating code roots In-Reply-To: <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> References: <46674d77-9ae7-82e5-0572-77fc44f0c8c7@oracle.com> <30503437-ee40-a924-d7fa-8ed5787adf52@oracle.com> <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> Message-ID: <222d145f-fc4e-a0f3-6984-d6191fe845b1@oracle.com> Hi Per, Looks good. Thanks, /Erik On 2019-12-09 10:17, Per Liden wrote: > Here's an updated webrev, which removes the "assert(is_armed, ...)" > BarrierSetNMethod::disarm(), as it's a bit too strict. Also, added the > "if (ZNMethod::is_armed(nm))" to the ZNMethodUnlinkClosure, so avoid > walking to oops if it's already disarmed. > > http://cr.openjdk.java.net/~pliden/8234654/webrev.1 > > /Per > > On 11/22/19 3:38 PM, Per Liden wrote: >> Thanks Erik! >> >> /Per >> >> On 11/22/19 3:35 PM, erik.osterlund at oracle.com wrote: >>> Hi Per, >>> >>> Looks good. >>> >>> Thanks, >>> /Erik >>> >>> On 11/22/19 3:03 PM, Per Liden wrote: >>>> ZRootIterator will currently always try to disarm on-stack >>>> NMethods. Strictly speaking, we should only do this when >>>> marking/relocating code roots, not when e.g. iterating the heap. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234654 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8234654/webrev.0 >>>> >>>> /Per >>> From stefan.johansson at oracle.com Mon Dec 9 09:42:05 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 9 Dec 2019 10:42:05 +0100 Subject: RFR: 8165443: Free Collection Set serial phase takes very long on large heaps In-Reply-To: References: <94565e78-149c-b8b5-ff17-752481e0e36e@oracle.com> <2ED2D304-BFE0-4B6F-90DC-0D0627B444E0@oracle.com> <804ddfc8-161a-22bd-f3b2-aa4a37c1e7fa@oracle.com> <39546A96-D638-4C54-A92B-7995B3F112EB@oracle.com> <09EE050F-2068-475E-B1FD-31B4C89B5388@oracle.com> Message-ID: Thanks Thomas and Kim for your reviews, Stefan On 2019-12-06 21:25, Kim Barrett wrote: >> On Dec 6, 2019, at 4:53 AM, Stefan Johansson wrote: >> Yes, I mentioned that I didn?t add any heuristic for this and I agree that one worker per region is to much, and in most cases we will already have fewer active workers for small heaps, this clamp was just a way to make sure we don?t have more workers than ever needed. >> >> I also agree that we could do some experiments and see if we can come up with a better way to size the number of threads here, but for now I think this is ok. >> >> New webrev, full one also contain a change to work with latest WorkerDataArray changes: >> Full: http://cr.openjdk.java.net/~sjohanss/8165443/03/ >> Inc: http://cr.openjdk.java.net/~sjohanss/8165443/02-03/ > > Looks good. > From per.liden at oracle.com Mon Dec 9 10:22:35 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 9 Dec 2019 11:22:35 +0100 Subject: RFR: 8234654: ZGC: Only disarm NMethods when marking/relocating code roots In-Reply-To: <222d145f-fc4e-a0f3-6984-d6191fe845b1@oracle.com> References: <46674d77-9ae7-82e5-0572-77fc44f0c8c7@oracle.com> <30503437-ee40-a924-d7fa-8ed5787adf52@oracle.com> <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> <222d145f-fc4e-a0f3-6984-d6191fe845b1@oracle.com> Message-ID: <66bc2156-26c4-e726-0448-96cbbf48f035@oracle.com> Thanks Erik! /Per On 12/9/19 10:26 AM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-12-09 10:17, Per Liden wrote: >> Here's an updated webrev, which removes the "assert(is_armed, ...)" >> BarrierSetNMethod::disarm(), as it's a bit too strict. Also, added the >> "if (ZNMethod::is_armed(nm))" to the ZNMethodUnlinkClosure, so avoid >> walking to oops if it's already disarmed. >> >> http://cr.openjdk.java.net/~pliden/8234654/webrev.1 >> >> /Per >> >> On 11/22/19 3:38 PM, Per Liden wrote: >>> Thanks Erik! >>> >>> /Per >>> >>> On 11/22/19 3:35 PM, erik.osterlund at oracle.com wrote: >>>> Hi Per, >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> /Erik >>>> >>>> On 11/22/19 3:03 PM, Per Liden wrote: >>>>> ZRootIterator will currently always try to disarm on-stack >>>>> NMethods. Strictly speaking, we should only do this when >>>>> marking/relocating code roots, not when e.g. iterating the heap. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234654 >>>>> Webrev: http://cr.openjdk.java.net/~pliden/8234654/webrev.0 >>>>> >>>>> /Per >>>> > From per.liden at oracle.com Mon Dec 9 10:57:47 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 9 Dec 2019 11:57:47 +0100 Subject: RFR: 8235366: ZGC: Kitchensink.java fails in ZBarrier::should_mark_through Message-ID: JDK-8230661 introduced a bug where we can accidentally "downgrade" an oop while healing it. More specifically, during the marking phase, an AS_NO_KEELALIVE load racing with finalizable marking could leave the oop in a remapped state (instead of finalizable marked state). The problem is the conditions for when to re-try a failing heal CAS. Instead of using an is_good_or_null() check, this patch uses the barrier fast_path() in the self_heal() function to avoid "downgrading" oops. Bug: https://bugs.openjdk.java.net/browse/JDK-8235366 Webrev: http://cr.openjdk.java.net/~pliden/8235366/webrev.1 Testing: ZGC tier1-8 /Per From erik.osterlund at oracle.com Mon Dec 9 11:12:19 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 9 Dec 2019 12:12:19 +0100 Subject: RFR: 8235366: ZGC: Kitchensink.java fails in ZBarrier::should_mark_through In-Reply-To: References: Message-ID: <9743b768-3352-6392-4d57-dde4077f8c49@oracle.com> Hi Per, Looks good. Thanks, /Erik On 2019-12-09 11:57, Per Liden wrote: > JDK-8230661 introduced a bug where we can accidentally "downgrade" an > oop while healing it. More specifically, during the marking phase, an > AS_NO_KEELALIVE load racing with finalizable marking could leave the > oop in a remapped state (instead of finalizable marked state). > > The problem is the conditions for when to re-try a failing heal CAS. > Instead of using an is_good_or_null() check, this patch uses the > barrier fast_path() in the self_heal() function to avoid "downgrading" > oops. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235366 > Webrev: http://cr.openjdk.java.net/~pliden/8235366/webrev.1 > > Testing: ZGC tier1-8 > > /Per From per.liden at oracle.com Mon Dec 9 11:21:56 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 9 Dec 2019 12:21:56 +0100 Subject: RFR: 8235366: ZGC: Kitchensink.java fails in ZBarrier::should_mark_through In-Reply-To: <9743b768-3352-6392-4d57-dde4077f8c49@oracle.com> References: <9743b768-3352-6392-4d57-dde4077f8c49@oracle.com> Message-ID: Thanks Erik! /Per On 12/9/19 12:12 PM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-12-09 11:57, Per Liden wrote: >> JDK-8230661 introduced a bug where we can accidentally "downgrade" an >> oop while healing it. More specifically, during the marking phase, an >> AS_NO_KEELALIVE load racing with finalizable marking could leave the >> oop in a remapped state (instead of finalizable marked state). >> >> The problem is the conditions for when to re-try a failing heal CAS. >> Instead of using an is_good_or_null() check, this patch uses the >> barrier fast_path() in the self_heal() function to avoid "downgrading" >> oops. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235366 >> Webrev: http://cr.openjdk.java.net/~pliden/8235366/webrev.1 >> >> Testing: ZGC tier1-8 >> >> /Per > From erik.osterlund at oracle.com Mon Dec 9 15:59:39 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 9 Dec 2019 16:59:39 +0100 Subject: [14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses In-Reply-To: <015f0c8a-37f0-e603-e644-7a51195c4ad2@oracle.com> References: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> <015f0c8a-37f0-e603-e644-7a51195c4ad2@oracle.com> Message-ID: <7326c54d-1aef-8cf7-cc4e-01c26aed73c8@oracle.com> Hi Vladimir, On 2019-12-06 16:19, Vladimir Ivanov wrote: > Hi Erik, > > I like your idea. Here's updated version: > ? http://cr.openjdk.java.net/~vlivanov/8226411/webrev.01 Looks good! > While browsing the code, I noticed that changes in > G1BarrierSetC2::load_at_resolved() aren't required (need_cpu_mem_bar > is used for oop case). But I decided to keep them to keep it > (relatively) close to C2Access::needs_cpu_membar(). Sounds reasonable. Thanks, /Erik > Best regards, > Vladimir Ivanov > > On 05.12.2019 23:14, Erik ?sterlund wrote: >> Hi, >> >> Could we use the existing IN_NATIVE decorator instead of introducing >> a new decorator that seems to be an alias for the same thing? The >> decorator describing its use (IN_NATIVE) says it is for off-heap >> accesses pointing into the heap. We can just remove from the comment >> the part presuming it is a reference. >> >> What do you think? >> >> Thanks, >> /Erik >> >>> On 5 Dec 2019, at 20:16, Vladimir Kozlov >>> wrote: >>> >>> ?CCing to GC group. >>> >>> Looks fine to me but someone from GC land have to look too. >>> >>> I wish we have more concrete indication for off-heap access instead >>> of guessing it based on how we address memory through Unsafe API. >>> >>> Thanks, >>> Vladimir >>> >>>> On 11/29/19 7:42 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8226411/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8226411 >>>> There were a number of fixes in C2 support for unsafe accesses >>>> recently which led to additional memory barriers around them. It >>>> improved stability, but in some cases it was redundant. One of >>>> important use cases which regressed is off-heap accesses [1]. The >>>> barriers around them are redundant because they are serialized on >>>> raw memory and don't intersect with any on-heap accesses. >>>> Proposed fix skips memory barriers around unsafe accesses which are >>>> provably off-heap (base == NULL). >>>> It (almost completely) recovers performance on the microbenchmark >>>> provided in JDK-8224182 [1]. >>>> Testing: tier1-6. >>>> Best regards, >>>> Vladimir Ivanov >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8224182 >> From vladimir.x.ivanov at oracle.com Mon Dec 9 16:04:01 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 9 Dec 2019 19:04:01 +0300 Subject: [14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses In-Reply-To: <7326c54d-1aef-8cf7-cc4e-01c26aed73c8@oracle.com> References: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> <015f0c8a-37f0-e603-e644-7a51195c4ad2@oracle.com> <7326c54d-1aef-8cf7-cc4e-01c26aed73c8@oracle.com> Message-ID: <784f3959-933a-a5c7-beb2-f011c9928ec7@oracle.com> Thanks, Erik! Best regards, Vladimir Ivanov On 09.12.2019 18:59, Erik ?sterlund wrote: > Hi Vladimir, > > On 2019-12-06 16:19, Vladimir Ivanov wrote: >> Hi Erik, >> >> I like your idea. Here's updated version: >> ? http://cr.openjdk.java.net/~vlivanov/8226411/webrev.01 > > Looks good! > >> While browsing the code, I noticed that changes in >> G1BarrierSetC2::load_at_resolved() aren't required (need_cpu_mem_bar >> is used for oop case). But I decided to keep them to keep it >> (relatively) close to C2Access::needs_cpu_membar(). > > Sounds reasonable. > > Thanks, > /Erik > >> Best regards, >> Vladimir Ivanov >> >> On 05.12.2019 23:14, Erik ?sterlund wrote: >>> Hi, >>> >>> Could we use the existing IN_NATIVE decorator instead of introducing >>> a new decorator that seems to be an alias for the same thing? The >>> decorator describing its use (IN_NATIVE) says it is for off-heap >>> accesses pointing into the heap. We can just remove from the comment >>> the part presuming it is a reference. >>> >>> What do you think? >>> >>> Thanks, >>> /Erik >>> >>>> On 5 Dec 2019, at 20:16, Vladimir Kozlov >>>> wrote: >>>> >>>> ?CCing to GC group. >>>> >>>> Looks fine to me but someone from GC land have to look too. >>>> >>>> I wish we have more concrete indication for off-heap access instead >>>> of guessing it based on how we address memory through Unsafe API. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 11/29/19 7:42 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8226411/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8226411 >>>>> There were a number of fixes in C2 support for unsafe accesses >>>>> recently which led to additional memory barriers around them. It >>>>> improved stability, but in some cases it was redundant. One of >>>>> important use cases which regressed is off-heap accesses [1]. The >>>>> barriers around them are redundant because they are serialized on >>>>> raw memory and don't intersect with any on-heap accesses. >>>>> Proposed fix skips memory barriers around unsafe accesses which are >>>>> provably off-heap (base == NULL). >>>>> It (almost completely) recovers performance on the microbenchmark >>>>> provided in JDK-8224182 [1]. >>>>> Testing: tier1-6. >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8224182 >>> > From tobias.hartmann at oracle.com Mon Dec 9 16:25:22 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 Dec 2019 17:25:22 +0100 Subject: [14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses In-Reply-To: <7326c54d-1aef-8cf7-cc4e-01c26aed73c8@oracle.com> References: <7fa6918f-f645-ba25-cad3-df223eba9990@oracle.com> <015f0c8a-37f0-e603-e644-7a51195c4ad2@oracle.com> <7326c54d-1aef-8cf7-cc4e-01c26aed73c8@oracle.com> Message-ID: On 09.12.19 16:59, Erik ?sterlund wrote: >> I like your idea. Here's updated version: >> ? http://cr.openjdk.java.net/~vlivanov/8226411/webrev.01 > > Looks good! +1 Best regards, Tobias From zgu at redhat.com Mon Dec 9 16:37:21 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 9 Dec 2019 11:37:21 -0500 Subject: RFR 8235586: Shenandoah: Traversal GC still uses old CLD::oops_do API Message-ID: <85b80671-c8cb-2a8a-a2ea-6f4f02957d45@redhat.com> Travesal GC did not update CLD::oops_do() API after JDK-8210330 Bug: https://bugs.openjdk.java.net/browse/JDK-8235586 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235586/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From rkennke at redhat.com Mon Dec 9 17:31:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 9 Dec 2019 18:31:52 +0100 Subject: RFR 8235586: Shenandoah: Traversal GC still uses old CLD::oops_do API In-Reply-To: <85b80671-c8cb-2a8a-a2ea-6f4f02957d45@redhat.com> References: <85b80671-c8cb-2a8a-a2ea-6f4f02957d45@redhat.com> Message-ID: <29a80974-5f6c-56f3-7111-090783f34264@redhat.com> Yes, looks good & trivial! Thanks, Roman > Travesal GC did not update CLD::oops_do() API after JDK-8210330 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235586 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235586/webrev.00/ > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) > > Thanks, > > -Zhengyu > From stefan.karlsson at oracle.com Mon Dec 9 21:29:39 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 9 Dec 2019 22:29:39 +0100 Subject: RFR: 8234654: ZGC: Only disarm NMethods when marking/relocating code roots In-Reply-To: <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> References: <46674d77-9ae7-82e5-0572-77fc44f0c8c7@oracle.com> <30503437-ee40-a924-d7fa-8ed5787adf52@oracle.com> <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> Message-ID: <56494050-83b0-4080-1a91-a6be79ea15fa@oracle.com> Reworked the patch a bit, because I wanted to move _disarm_nmethod out from the iterator and into the closures: https://cr.openjdk.java.net/~stefank/8234654/webrev.01.delta/ https://cr.openjdk.java.net/~stefank/8234654/webrev.01/ - Ripped out _disarm_nmethod from the ZRootsIterator. - Added a should_disarm_nmethod() virtual function to the closure. The mark and relocation closures return true. Had a version that introduced a ZRootsIterator::do_code_blob analogous to ZRootsIterator::do_thread, but we don't need that flexibility right now, so backed away from that in favor of more straight forward code. - Removed closure indirection in ZRootsIteratorCodeBlobClosure. - Changed to use ZNMethod::nmethod_oops_do instead of nm->oops_do and nm->fix_oop_relocations, since it's faster . - Changed to use ZNMethod::disarm(nm) instead of _bs->disarm(nm), since it hides the _bs retrieval. - Added armed state assert. This passes tier1-7 of ZGC testing. Sat down with Per for the final version of this. Either we fold this patch into his change, or I'll add this as a patch afterwards. Thanks, StefanK On 2019-12-09 10:17, Per Liden wrote: > Here's an updated webrev, which removes the "assert(is_armed, ...)" > BarrierSetNMethod::disarm(), as it's a bit too strict. Also, added the > "if (ZNMethod::is_armed(nm))" to the ZNMethodUnlinkClosure, so avoid > walking to oops if it's already disarmed. > > http://cr.openjdk.java.net/~pliden/8234654/webrev.1 > > /Per > > On 11/22/19 3:38 PM, Per Liden wrote: >> Thanks Erik! >> >> /Per >> >> On 11/22/19 3:35 PM, erik.osterlund at oracle.com wrote: >>> Hi Per, >>> >>> Looks good. >>> >>> Thanks, >>> /Erik >>> >>> On 11/22/19 3:03 PM, Per Liden wrote: >>>> ZRootIterator will currently always try to disarm on-stack >>>> NMethods. Strictly speaking, we should only do this when >>>> marking/relocating code roots, not when e.g. iterating the heap. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234654 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8234654/webrev.0 >>>> >>>> /Per >>> From per.liden at oracle.com Tue Dec 10 08:07:18 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 10 Dec 2019 09:07:18 +0100 Subject: RFR: 8234654: ZGC: Only disarm NMethods when marking/relocating code roots In-Reply-To: <56494050-83b0-4080-1a91-a6be79ea15fa@oracle.com> References: <46674d77-9ae7-82e5-0572-77fc44f0c8c7@oracle.com> <30503437-ee40-a924-d7fa-8ed5787adf52@oracle.com> <042e1092-4a3a-4bfc-1710-9d11ec2368b7@oracle.com> <56494050-83b0-4080-1a91-a6be79ea15fa@oracle.com> Message-ID: Thanks for reviewing. I'll fold the suggested changes into the patch. /Per On 12/9/19 10:29 PM, Stefan Karlsson wrote: > Reworked the patch a bit, because I wanted to move _disarm_nmethod out > from the iterator and into the closures: > > https://cr.openjdk.java.net/~stefank/8234654/webrev.01.delta/ > https://cr.openjdk.java.net/~stefank/8234654/webrev.01/ > > - Ripped out _disarm_nmethod from the ZRootsIterator. > > - Added a should_disarm_nmethod() virtual function to the closure. The > mark and relocation closures return true. Had a version that introduced > a ZRootsIterator::do_code_blob analogous to ZRootsIterator::do_thread, > but we don't need that flexibility right now, so backed away from that > in favor of more straight forward code. > > - Removed closure indirection in ZRootsIteratorCodeBlobClosure. > > - Changed to use ZNMethod::nmethod_oops_do instead of nm->oops_do and > nm->fix_oop_relocations, since it's faster . > > - Changed to use ZNMethod::disarm(nm) instead of _bs->disarm(nm), since > it hides the _bs retrieval. > > - Added armed state assert. > > This passes tier1-7 of ZGC testing. > > Sat down with Per for the final version of this. Either we fold this > patch into his change, or I'll add this as a patch afterwards. > > Thanks, > StefanK > > > On 2019-12-09 10:17, Per Liden wrote: >> Here's an updated webrev, which removes the "assert(is_armed, ...)" >> BarrierSetNMethod::disarm(), as it's a bit too strict. Also, added the >> "if (ZNMethod::is_armed(nm))" to the ZNMethodUnlinkClosure, so avoid >> walking to oops if it's already disarmed. >> >> http://cr.openjdk.java.net/~pliden/8234654/webrev.1 >> >> /Per >> >> On 11/22/19 3:38 PM, Per Liden wrote: >>> Thanks Erik! >>> >>> /Per >>> >>> On 11/22/19 3:35 PM, erik.osterlund at oracle.com wrote: >>>> Hi Per, >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> /Erik >>>> >>>> On 11/22/19 3:03 PM, Per Liden wrote: >>>>> ZRootIterator will currently always try to disarm on-stack >>>>> NMethods. Strictly speaking, we should only do this when >>>>> marking/relocating code roots, not when e.g. iterating the heap. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234654 >>>>> Webrev: http://cr.openjdk.java.net/~pliden/8234654/webrev.0 >>>>> >>>>> /Per >>>> > From erik.osterlund at oracle.com Tue Dec 10 08:20:50 2019 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Tue, 10 Dec 2019 09:20:50 +0100 Subject: RFR: 8234654: ZGC: Only disarm NMethods when marking/relocating code roots In-Reply-To: <56494050-83b0-4080-1a91-a6be79ea15fa@oracle.com> References: <56494050-83b0-4080-1a91-a6be79ea15fa@oracle.com> Message-ID: Hi Stefan, Looks... even better! Thanks, /Erik > On 9 Dec 2019, at 22:29, Stefan Karlsson wrote: > > ?Reworked the patch a bit, because I wanted to move _disarm_nmethod out from the iterator and into the closures: > > https://cr.openjdk.java.net/~stefank/8234654/webrev.01.delta/ > https://cr.openjdk.java.net/~stefank/8234654/webrev.01/ > > - Ripped out _disarm_nmethod from the ZRootsIterator. > > - Added a should_disarm_nmethod() virtual function to the closure. The mark and relocation closures return true. Had a version that introduced a ZRootsIterator::do_code_blob analogous to ZRootsIterator::do_thread, but we don't need that flexibility right now, so backed away from that in favor of more straight forward code. > > - Removed closure indirection in ZRootsIteratorCodeBlobClosure. > > - Changed to use ZNMethod::nmethod_oops_do instead of nm->oops_do and nm->fix_oop_relocations, since it's faster . > > - Changed to use ZNMethod::disarm(nm) instead of _bs->disarm(nm), since it hides the _bs retrieval. > > - Added armed state assert. > > This passes tier1-7 of ZGC testing. > > Sat down with Per for the final version of this. Either we fold this patch into his change, or I'll add this as a patch afterwards. > > Thanks, > StefanK > > >> On 2019-12-09 10:17, Per Liden wrote: >> Here's an updated webrev, which removes the "assert(is_armed, ...)" BarrierSetNMethod::disarm(), as it's a bit too strict. Also, added the "if (ZNMethod::is_armed(nm))" to the ZNMethodUnlinkClosure, so avoid walking to oops if it's already disarmed. >> >> http://cr.openjdk.java.net/~pliden/8234654/webrev.1 >> >> /Per >> >>> On 11/22/19 3:38 PM, Per Liden wrote: >>> Thanks Erik! >>> >>> /Per >>> >>> On 11/22/19 3:35 PM, erik.osterlund at oracle.com wrote: >>>> Hi Per, >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> /Erik >>>> >>>> On 11/22/19 3:03 PM, Per Liden wrote: >>>>> ZRootIterator will currently always try to disarm on-stack NMethods. Strictly speaking, we should only do this when marking/relocating code roots, not when e.g. iterating the heap. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234654 >>>>> Webrev: http://cr.openjdk.java.net/~pliden/8234654/webrev.0 >>>>> >>>>> /Per >>>> > From stefan.karlsson at oracle.com Tue Dec 10 09:04:44 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Dec 2019 10:04:44 +0100 Subject: RFR: 8235366: ZGC: Kitchensink.java fails in ZBarrier::should_mark_through In-Reply-To: References: Message-ID: <60c6f9c6-ccd1-9dcd-1365-1d040773dafa@oracle.com> Looks good. StefanK On 2019-12-09 11:57, Per Liden wrote: > JDK-8230661 introduced a bug where we can accidentally "downgrade" an > oop while healing it. More specifically, during the marking phase, an > AS_NO_KEELALIVE load racing with finalizable marking could leave the oop > in a remapped state (instead of finalizable marked state). > > The problem is the conditions for when to re-try a failing heal CAS. > Instead of using an is_good_or_null() check, this patch uses the barrier > fast_path() in the self_heal() function to avoid "downgrading" oops. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235366 > Webrev: http://cr.openjdk.java.net/~pliden/8235366/webrev.1 > > Testing: ZGC tier1-8 > > /Per From per.liden at oracle.com Tue Dec 10 09:06:48 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 10 Dec 2019 10:06:48 +0100 Subject: RFR: 8235366: ZGC: Kitchensink.java fails in ZBarrier::should_mark_through In-Reply-To: <60c6f9c6-ccd1-9dcd-1365-1d040773dafa@oracle.com> References: <60c6f9c6-ccd1-9dcd-1365-1d040773dafa@oracle.com> Message-ID: <9bc0e8c7-7e98-0fcd-e76b-b3bcffc3c947@oracle.com> Thanks Stefan. /Per On 12/10/19 10:04 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-12-09 11:57, Per Liden wrote: >> JDK-8230661 introduced a bug where we can accidentally "downgrade" an >> oop while healing it. More specifically, during the marking phase, an >> AS_NO_KEELALIVE load racing with finalizable marking could leave the >> oop in a remapped state (instead of finalizable marked state). >> >> The problem is the conditions for when to re-try a failing heal CAS. >> Instead of using an is_good_or_null() check, this patch uses the >> barrier fast_path() in the self_heal() function to avoid "downgrading" >> oops. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235366 >> Webrev: http://cr.openjdk.java.net/~pliden/8235366/webrev.1 >> >> Testing: ZGC tier1-8 >> >> /Per From stefan.johansson at oracle.com Tue Dec 10 11:27:34 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 10 Dec 2019 12:27:34 +0100 Subject: RFR: 8235427: Remove unnecessary parameters from G1CollectedHeap::free_region and HeapRegion::hr_clear Message-ID: Hi, Please review this cleanup to get rid of some unnecessary boolean passing. Issue: https://bugs.openjdk.java.net/browse/JDK-8235427 Webrev: http://cr.openjdk.java.net/~sjohanss/8235427/00/ Summary While reviewing the fix for JDK-8165443 we realized that some boolean parameters passed to G1CollectedHeap::free_region always had the same values and could therefore be removed. When looking a bit closer it turns out even more parameters can be skipped. The two things that are really changed when it comes to functionality in this patch are: 1. When freeing the CSet we previously always cleared the hot card cache for old regions. We now rely on this being done by free_region and this will have the effect that for evacuation failures we won't clear the hot card cache for those regions having failures. I've discussed this with a couple of others and we can't see any problems with this. 2. When creating heap regions we previously used the default value false for locked when initializing heap regions, but we know this code path will never be called in parallel so we can safely remove this parameter and always do rem_set()->clear_locked() in hr_clear(). Testing Mach5 tier1-3 passed, currently running tier4-5 as well. Cheers, Stefan From thomas.schatzl at oracle.com Tue Dec 10 15:33:43 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Dec 2019 16:33:43 +0100 Subject: RFR: 8235427: Remove unnecessary parameters from G1CollectedHeap::free_region and HeapRegion::hr_clear In-Reply-To: References: Message-ID: <57d31c39-fa14-f310-9c70-bb3db25dc509@oracle.com> Hi, On 10.12.19 12:27, Stefan Johansson wrote: > Hi, > > Please review this cleanup to get rid of some unnecessary boolean passing. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8235427 > Webrev: http://cr.openjdk.java.net/~sjohanss/8235427/00/ > > Summary > While reviewing the fix for JDK-8165443 we realized that some boolean > parameters passed to G1CollectedHeap::free_region always had the same > values and could therefore be removed. When looking a bit closer it > turns out even more parameters can be skipped. > > The two things that are really changed when it comes to functionality in > this patch are: > 1. When freeing the CSet we previously always cleared the hot card cache > for old regions. We now rely on this being done by free_region and this > will have the effect that for evacuation failures we won't clear the hot > card cache for those regions having failures. I've discussed this with a > couple of others and we can't see any problems with this. > > 2. When creating heap regions we previously used the default value false > for locked when initializing heap regions, but we know this code path > will never be called in parallel so we can safely remove this parameter > and always do rem_set()->clear_locked() in hr_clear(). > > Testing > Mach5 tier1-3 passed, currently running tier4-5 as well. > looks good. Thomas From rkennke at redhat.com Tue Dec 10 17:39:57 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 10 Dec 2019 18:39:57 +0100 Subject: RFR: 8235598: Shenandoah: Update copyrights Message-ID: <679dfe1e-03c7-b01f-3039-08eb06e7a25f@redhat.com> We accumulated a lot of copyright headers that went out-of-sync with reality. Let's fix them. Issue: https://bugs.openjdk.java.net/browse/JDK-8235598 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8235598/webrev.00/ Testing: build, hotspot_gc_shenandoah Ok? From zgu at redhat.com Tue Dec 10 18:39:40 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 10 Dec 2019 13:39:40 -0500 Subject: RFR: 8235598: Shenandoah: Update copyrights In-Reply-To: <679dfe1e-03c7-b01f-3039-08eb06e7a25f@redhat.com> References: <679dfe1e-03c7-b01f-3039-08eb06e7a25f@redhat.com> Message-ID: <9e791cf0-957c-2c7a-1360-ae1ae6f894d8@redhat.com> Looks good and trivial Thanks, -Zhengyu On 12/10/19 12:39 PM, Roman Kennke wrote: > We accumulated a lot of copyright headers that went out-of-sync with > reality. Let's fix them. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8235598 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8235598/webrev.00/ > > Testing: build, hotspot_gc_shenandoah > > Ok? > From zgu at redhat.com Tue Dec 10 19:45:38 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 10 Dec 2019 14:45:38 -0500 Subject: RFR (T) 8235685: Shenandoah: Enable leak profiler Message-ID: Please review this trivial patch that enables JFR leak profiler for Shenandoah. JDK-8235174 enhancement also applies to Shenandoah, we can enable leak profiler as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8235685 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235685/weberv.00/ Test: Use jmc to create JFR recording, eyeball Memory->Live Objects Thanks, -Zhengyu From rkennke at redhat.com Tue Dec 10 20:26:24 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 10 Dec 2019 21:26:24 +0100 Subject: RFR (T) 8235685: Shenandoah: Enable leak profiler In-Reply-To: References: Message-ID: Yes, good! Thanks, Roman > Please review this trivial patch that enables JFR leak profiler for > Shenandoah. > > JDK-8235174 enhancement also applies to Shenandoah, we can enable leak > profiler as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235685 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235685/weberv.00/ > > Test: > ? Use jmc to create JFR recording, eyeball Memory->Live Objects > > > Thanks, > > -Zhengyu > From per.liden at oracle.com Wed Dec 11 08:24:50 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 11 Dec 2019 09:24:50 +0100 Subject: RFR: 8235748: ZGC: Remove ZAddress::address() Message-ID: I propose that we remove ZAddress::address(). It was useful for the now defunct Sparc port, but none of the currently supported architectures need it. Should we ever need it in the future, we can easily add it again. Removing ZAddress::address() implies also removing ZAddressBase and the initialization functions ZPlatformAddressBase(). Bug: https://bugs.openjdk.java.net/browse/JDK-8235748 Webrev: http://cr.openjdk.java.net/~pliden/8235748/webrev.0 /Per From kim.barrett at oracle.com Wed Dec 11 10:24:03 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Dec 2019 05:24:03 -0500 Subject: RFR: 8235427: Remove unnecessary parameters from G1CollectedHeap::free_region and HeapRegion::hr_clear In-Reply-To: References: Message-ID: <63CA9EB2-5F7C-4369-8C88-DD1D3AC1EC7A@oracle.com> > On Dec 10, 2019, at 6:27 AM, Stefan Johansson wrote: > > Hi, > > Please review this cleanup to get rid of some unnecessary boolean passing. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8235427 > Webrev: http://cr.openjdk.java.net/~sjohanss/8235427/00/ > > Summary > While reviewing the fix for JDK-8165443 we realized that some boolean parameters passed to G1CollectedHeap::free_region always had the same values and could therefore be removed. When looking a bit closer it turns out even more parameters can be skipped. > > The two things that are really changed when it comes to functionality in this patch are: > 1. When freeing the CSet we previously always cleared the hot card cache for old regions. We now rely on this being done by free_region and this will have the effect that for evacuation failures we won't clear the hot card cache for those regions having failures. I've discussed this with a couple of others and we can't see any problems with this. > > 2. When creating heap regions we previously used the default value false for locked when initializing heap regions, but we know this code path will never be called in parallel so we can safely remove this parameter and always do rem_set()->clear_locked() in hr_clear(). > > Testing > Mach5 tier1-3 passed, currently running tier4-5 as well. > > Cheers, > Stefan Looks good. From stefan.karlsson at oracle.com Wed Dec 11 11:27:25 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 12:27:25 +0100 Subject: RFR: 8235757 : Rename SupportedGC to IncludedGC Message-ID: Hi all, Please review this trivial patch to rename SupportedGC (and associated macros and functions) to IncludedGC. https://cr.openjdk.java.net/~stefank/8235757/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8235757 I want to do this name change to disambiguate an upcoming addition to GCConfig::is_gc_supported, where built-in GCs doesn't mean that the GC is supported on the current platform. I'm using the name IncludedGC because it reflects our usage of INCLUDE_*GC macros and defines. Thanks, StefanK From per.liden at oracle.com Wed Dec 11 11:36:11 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 11 Dec 2019 12:36:11 +0100 Subject: RFR: 8235757 : Rename SupportedGC to IncludedGC In-Reply-To: References: Message-ID: <865a2559-9422-9c9f-5d06-a8f231bd3a00@oracle.com> Looks good (and trivial)! /Per On 12/11/19 12:27 PM, Stefan Karlsson wrote: > Hi all, > > Please review this trivial patch to rename SupportedGC (and associated > macros and functions) to IncludedGC. > > https://cr.openjdk.java.net/~stefank/8235757/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8235757 > > I want to do this name change to disambiguate an upcoming addition to > GCConfig::is_gc_supported, where built-in GCs doesn't mean that the GC > is supported on the current platform. > > I'm using the name IncludedGC because it reflects our usage of > INCLUDE_*GC macros and defines. > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Dec 11 11:36:31 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 12:36:31 +0100 Subject: RFR: 8235757 : Rename SupportedGC to IncludedGC In-Reply-To: <865a2559-9422-9c9f-5d06-a8f231bd3a00@oracle.com> References: <865a2559-9422-9c9f-5d06-a8f231bd3a00@oracle.com> Message-ID: Thanks, Per. StefanK On 2019-12-11 12:36, Per Liden wrote: > Looks good (and trivial)! > > /Per > > On 12/11/19 12:27 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this trivial patch to rename SupportedGC (and associated >> macros and functions) to IncludedGC. >> >> https://cr.openjdk.java.net/~stefank/8235757/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8235757 >> >> I want to do this name change to disambiguate an upcoming addition to >> GCConfig::is_gc_supported, where built-in GCs doesn't mean that the GC >> is supported on the current platform. >> >> I'm using the name IncludedGC because it reflects our usage of >> INCLUDE_*GC macros and defines. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Wed Dec 11 11:38:53 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 12:38:53 +0100 Subject: RFR: 8235759: Extend GCConfig::is_gc_supported to mean supported not only included in build Message-ID: <5c965b4b-6380-00aa-7916-b191369def2d@oracle.com> Hi all, Please review this trivial patch to allow GC to say that they are unsupported even though they exists in the binary. https://cr.openjdk.java.net/~stefank/8235759/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8235759 There's no change in behavior, but allows ZGC to specialize is_gc_supported in an up-coming patch. This patch applies on-top of: 8235757: Rename SupportedGC to IncludedGC Thanks, StefanK From per.liden at oracle.com Wed Dec 11 11:43:09 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 11 Dec 2019 12:43:09 +0100 Subject: RFR: 8235759: Extend GCConfig::is_gc_supported to mean supported not only included in build In-Reply-To: <5c965b4b-6380-00aa-7916-b191369def2d@oracle.com> References: <5c965b4b-6380-00aa-7916-b191369def2d@oracle.com> Message-ID: <58b82715-77e4-c2f6-6543-8b3b780b32a3@oracle.com> Looks good and trivial. /Per On 12/11/19 12:38 PM, Stefan Karlsson wrote: > Hi all, > > Please review this trivial patch to allow GC to say that they are > unsupported even though they exists in the binary. > > https://cr.openjdk.java.net/~stefank/8235759/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8235759 > > There's no change in behavior, but allows ZGC to specialize > is_gc_supported in an up-coming patch. > > This patch applies on-top of: > ?8235757: Rename SupportedGC to IncludedGC > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Dec 11 11:46:40 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 12:46:40 +0100 Subject: RFR: 8235759: Extend GCConfig::is_gc_supported to mean supported not only included in build In-Reply-To: <58b82715-77e4-c2f6-6543-8b3b780b32a3@oracle.com> References: <5c965b4b-6380-00aa-7916-b191369def2d@oracle.com> <58b82715-77e4-c2f6-6543-8b3b780b32a3@oracle.com> Message-ID: <3e4d4cde-589b-1969-ac10-130b70b4b24b@oracle.com> Thanks, Per. StefanK On 2019-12-11 12:43, Per Liden wrote: > Looks good and trivial. > > /Per > > On 12/11/19 12:38 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this trivial patch to allow GC to say that they are >> unsupported even though they exists in the binary. >> >> https://cr.openjdk.java.net/~stefank/8235759/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8235759 >> >> There's no change in behavior, but allows ZGC to specialize >> is_gc_supported in an up-coming patch. >> >> This patch applies on-top of: >> ??8235757: Rename SupportedGC to IncludedGC >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Wed Dec 11 12:10:09 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 13:10:09 +0100 Subject: 8235760: ZGC: Implement precise check for @require vm.gc.Z for Windows Message-ID: Hi all, Please review this patch to reimplemente @require vm.gc.Z and WB_IsGCSupported to use a more precise check on Windows. https://cr.openjdk.java.net/~stefank/8235760/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8235760 With this patch we call into the VM and try to resolve the required Windows APIs, instead of doing string comparisons on system properties. Thanks, StefanK From per.liden at oracle.com Wed Dec 11 15:33:13 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 11 Dec 2019 16:33:13 +0100 Subject: RFR: 8235696: ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state Message-ID: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> The assert in ZRootsIteratorCodeBlobClosure::do_code_blob() fails to take into account that some nmethods don't have an entry barrier at all and those are always considered disarmed. This patch adjusts the assert accordingly. Bug: https://bugs.openjdk.java.net/browse/JDK-8235696 Webrev: http://cr.openjdk.java.net/~pliden/8235696/webrev.0 /Per From erik.osterlund at oracle.com Wed Dec 11 16:04:44 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Wed, 11 Dec 2019 17:04:44 +0100 Subject: RFR: 8235748: ZGC: Remove ZAddress::address() In-Reply-To: References: Message-ID: <0f097e39-2be8-65d3-fffa-78df06c8a9d8@oracle.com> Hi Per, Looks good. Thanks, /Erik On 12/11/19 9:24 AM, Per Liden wrote: > I propose that we remove ZAddress::address(). It was useful for the > now defunct Sparc port, but none of the currently supported > architectures need it. Should we ever need it in the future, we can > easily add it again. > > Removing ZAddress::address() implies also removing ZAddressBase and > the initialization functions ZPlatformAddressBase(). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235748 > Webrev: http://cr.openjdk.java.net/~pliden/8235748/webrev.0 > > /Per From erik.osterlund at oracle.com Wed Dec 11 16:13:30 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Wed, 11 Dec 2019 17:13:30 +0100 Subject: 8235760: ZGC: Implement precise check for @require vm.gc.Z for Windows In-Reply-To: References: Message-ID: <54d293ea-eea2-af11-48d5-3e1222050471@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 12/11/19 1:10 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to reimplemente @require vm.gc.Z and > WB_IsGCSupported to use a more precise check on Windows. > > https://cr.openjdk.java.net/~stefank/8235760/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8235760 > > With this patch we call into the VM and try to resolve the required > Windows APIs, instead of doing string comparisons on system properties. > > Thanks, > StefanK From per.liden at oracle.com Wed Dec 11 16:23:55 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 11 Dec 2019 17:23:55 +0100 Subject: RFR: 8235748: ZGC: Remove ZAddress::address() In-Reply-To: <0f097e39-2be8-65d3-fffa-78df06c8a9d8@oracle.com> References: <0f097e39-2be8-65d3-fffa-78df06c8a9d8@oracle.com> Message-ID: Thanks Erik! /Per On 2019-12-11 17:04, erik.osterlund at oracle.com wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 12/11/19 9:24 AM, Per Liden wrote: >> I propose that we remove ZAddress::address(). It was useful for the >> now defunct Sparc port, but none of the currently supported >> architectures need it. Should we ever need it in the future, we can >> easily add it again. >> >> Removing ZAddress::address() implies also removing ZAddressBase and >> the initialization functions ZPlatformAddressBase(). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235748 >> Webrev: http://cr.openjdk.java.net/~pliden/8235748/webrev.0 >> >> /Per > From erik.osterlund at oracle.com Wed Dec 11 16:31:14 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Wed, 11 Dec 2019 17:31:14 +0100 Subject: RFR: 8235696: ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state In-Reply-To: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> References: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> Message-ID: <731eb1bc-ca7b-4001-e0f6-686f596dff71@oracle.com> Hi Per, Looks good. Thanks, /Erik On 12/11/19 4:33 PM, Per Liden wrote: > The assert in ZRootsIteratorCodeBlobClosure::do_code_blob() fails to > take into account that some nmethods don't have an entry barrier at > all and those are always considered disarmed. This patch adjusts the > assert accordingly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235696 > Webrev: http://cr.openjdk.java.net/~pliden/8235696/webrev.0 > > /Per From per.liden at oracle.com Wed Dec 11 16:38:13 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 11 Dec 2019 17:38:13 +0100 Subject: RFR: 8235696: ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state In-Reply-To: <731eb1bc-ca7b-4001-e0f6-686f596dff71@oracle.com> References: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> <731eb1bc-ca7b-4001-e0f6-686f596dff71@oracle.com> Message-ID: <47853e4f-0215-2968-245b-fe3717c6603d@oracle.com> Thanks Erik! /Per On 12/11/19 5:31 PM, erik.osterlund at oracle.com wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 12/11/19 4:33 PM, Per Liden wrote: >> The assert in ZRootsIteratorCodeBlobClosure::do_code_blob() fails to >> take into account that some nmethods don't have an entry barrier at >> all and those are always considered disarmed. This patch adjusts the >> assert accordingly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235696 >> Webrev: http://cr.openjdk.java.net/~pliden/8235696/webrev.0 >> >> /Per > From stefan.karlsson at oracle.com Wed Dec 11 17:36:08 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 18:36:08 +0100 Subject: RFR: 8235696: ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state In-Reply-To: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> References: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> Message-ID: <421dd496-c190-9054-a93e-435628092d03@oracle.com> Looks good. StefanK On 2019-12-11 16:33, Per Liden wrote: > The assert in ZRootsIteratorCodeBlobClosure::do_code_blob() fails to > take into account that some nmethods don't have an entry barrier at > all and those are always considered disarmed. This patch adjusts the > assert accordingly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235696 > Webrev: http://cr.openjdk.java.net/~pliden/8235696/webrev.0 > > /Per From stefan.karlsson at oracle.com Wed Dec 11 17:55:58 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Dec 2019 18:55:58 +0100 Subject: 8235760: ZGC: Implement precise check for @require vm.gc.Z for Windows In-Reply-To: References: Message-ID: <53ce2649-e2b2-5bab-8226-4685bd745a27@oracle.com> Per wanted to move the is_os_supported from ZInitialize to ZArguments. Updated webrevs: ?https://cr.openjdk.java.net/~stefank/8235760/webrev.02.delta/ ?https://cr.openjdk.java.net/~stefank/8235760/webrev.02/ StefanK On 2019-12-11 13:10, Stefan Karlsson wrote: > Hi all, > > Please review this patch to reimplemente @require vm.gc.Z and > WB_IsGCSupported to use a more precise check on Windows. > > https://cr.openjdk.java.net/~stefank/8235760/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8235760 > > With this patch we call into the VM and try to resolve the required > Windows APIs, instead of doing string comparisons on system properties. > > Thanks, > StefanK From zgu at redhat.com Wed Dec 11 17:56:06 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 11 Dec 2019 12:56:06 -0500 Subject: [14] RFR(XS) 8235776: Shenandoah: Shenandoah root updater not always uses right code blob closure Message-ID: <50f70dc3-3370-0e45-c991-793af1d6bebc@redhat.com> Please review this small patch that updates/disarms nmethods during root updating if concurrent class unloading is enabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8235776 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235776/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From erik.osterlund at oracle.com Wed Dec 11 17:57:50 2019 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Wed, 11 Dec 2019 18:57:50 +0100 Subject: RFR (T) 8235685: Shenandoah: Enable leak profiler In-Reply-To: References: Message-ID: <8AB2C61D-643A-4F98-BFD5-CF9CA8ECE228@oracle.com> Hi Zhengyu, Looks good. /Erik > On 10 Dec 2019, at 20:45, Zhengyu Gu wrote: > > ?Please review this trivial patch that enables JFR leak profiler for Shenandoah. > > JDK-8235174 enhancement also applies to Shenandoah, we can enable leak profiler as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235685 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235685/weberv.00/ > > Test: > Use jmc to create JFR recording, eyeball Memory->Live Objects > > > Thanks, > > -Zhengyu > From zgu at redhat.com Wed Dec 11 18:02:27 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 11 Dec 2019 13:02:27 -0500 Subject: RFR (T) 8235685: Shenandoah: Enable leak profiler In-Reply-To: <8AB2C61D-643A-4F98-BFD5-CF9CA8ECE228@oracle.com> References: <8AB2C61D-643A-4F98-BFD5-CF9CA8ECE228@oracle.com> Message-ID: <1e8366dc-ae13-42e8-0a75-8543d9ff19c4@redhat.com> Thanks, Erik -Zhengyu On 12/11/19 12:57 PM, Erik ?sterlund wrote: > Hi Zhengyu, > > Looks good. > > /Erik > >> On 10 Dec 2019, at 20:45, Zhengyu Gu wrote: >> >> ?Please review this trivial patch that enables JFR leak profiler for Shenandoah. >> >> JDK-8235174 enhancement also applies to Shenandoah, we can enable leak profiler as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235685 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235685/weberv.00/ >> >> Test: >> Use jmc to create JFR recording, eyeball Memory->Live Objects >> >> >> Thanks, >> >> -Zhengyu >> > From rkennke at redhat.com Wed Dec 11 18:21:32 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 11 Dec 2019 19:21:32 +0100 Subject: [14] RFR(XS) 8235776: Shenandoah: Shenandoah root updater not always uses right code blob closure In-Reply-To: <50f70dc3-3370-0e45-c991-793af1d6bebc@redhat.com> References: <50f70dc3-3370-0e45-c991-793af1d6bebc@redhat.com> Message-ID: Ok. Thanks, Roman > Please review this small patch that updates/disarms nmethods during root > updating if concurrent class unloading is enabled. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235776 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235776/webrev.00/ > > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) > > Thanks, > > -Zhengyu > From rkennke at redhat.com Wed Dec 11 22:12:44 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 11 Dec 2019 23:12:44 +0100 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: References: Message-ID: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> After discussing off-line with Zhengyu, I am proposing those changes: - Reinstate returning object for GC threads (apparently needed b/c of bug in JVMTI) - Always heal nmethods in barrier. We can only get there during evac (see below) - ShenandoahEvacUpdateOopStorageRootsClosure renamed to ShenandoahEvacUpdateCleanupRootsClosure and let it also handle cleanup. - Changed order of cleanup and unload: first do cleanup, then do unload. - only call prepare_unloading() when we have a cset. This arms nmethods. We only ever want to get into nmethod-barriers when we have a cset/are doing evacuation. Incremental: http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01/ Good now? Roman > Shenandoah can short-cut a cycle when the collection set remains empty, > and doesn't dive into concurrent evacuation and updating refs phases > then. However, this currently also precludes concurrent roots processing > and concurrent class unloading. This is only a minor nuisance now > (effectively skipping class unloading for short-cut-cycles), but amounts > to a real bug when we're going to do weak-roots-cleaning concurrently too. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234974 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ > > Testing: hotspot_gc_shenandoah > > Can I please get a review? > > Roman > From zgu at redhat.com Thu Dec 12 02:13:35 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 11 Dec 2019 21:13:35 -0500 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> References: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> Message-ID: Hi Roman, This patch is a bit confusing, as it along, cleaning up weak roots during concurrent roots phase is unnecessary, because they are cleaned in parallel cleaning during final mark pause. Should it be part of concurrent weak root processing, e.g. JDK-8228818? Nit: probably should rename ShenandoahCodeRoots::prepare_concurrent_unloading() to ShenandoahCodeRoots::arm_nmethods() Otherwise, looks good. Thanks, -Zhengyu On 12/11/19 5:12 PM, Roman Kennke wrote: > After discussing off-line with Zhengyu, I am proposing those changes: > > - Reinstate returning object for GC threads (apparently needed b/c of > bug in JVMTI) > - Always heal nmethods in barrier. We can only get there during evac > (see below) > - ShenandoahEvacUpdateOopStorageRootsClosure renamed to > ShenandoahEvacUpdateCleanupRootsClosure and let it also handle cleanup. > - Changed order of cleanup and unload: first do cleanup, then do unload. > - only call prepare_unloading() when we have a cset. This arms nmethods. > We only ever want to get into nmethod-barriers when we have a cset/are > doing evacuation. > > Incremental: > http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01/ > > Good now? > > Roman > >> Shenandoah can short-cut a cycle when the collection set remains empty, >> and doesn't dive into concurrent evacuation and updating refs phases >> then. However, this currently also precludes concurrent roots processing >> and concurrent class unloading. This is only a minor nuisance now >> (effectively skipping class unloading for short-cut-cycles), but amounts >> to a real bug when we're going to do weak-roots-cleaning concurrently too. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8234974 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ >> >> Testing: hotspot_gc_shenandoah >> >> Can I please get a review? >> >> Roman >> > From zgu at redhat.com Thu Dec 12 02:37:56 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 11 Dec 2019 21:37:56 -0500 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> References: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> Message-ID: <20f69c3b-9800-b146-b03e-86c46aba68c1@redhat.com> Second thought: I am not sure what problem you are trying to solve here, let's talk tomorrow. Thanks, -Zhengyu On 12/11/19 5:12 PM, Roman Kennke wrote: > After discussing off-line with Zhengyu, I am proposing those changes: > > - Reinstate returning object for GC threads (apparently needed b/c of > bug in JVMTI) > - Always heal nmethods in barrier. We can only get there during evac > (see below) > - ShenandoahEvacUpdateOopStorageRootsClosure renamed to > ShenandoahEvacUpdateCleanupRootsClosure and let it also handle cleanup. > - Changed order of cleanup and unload: first do cleanup, then do unload. > - only call prepare_unloading() when we have a cset. This arms nmethods. > We only ever want to get into nmethod-barriers when we have a cset/are > doing evacuation. > > Incremental: > http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01/ > > Good now? > > Roman > >> Shenandoah can short-cut a cycle when the collection set remains empty, >> and doesn't dive into concurrent evacuation and updating refs phases >> then. However, this currently also precludes concurrent roots processing >> and concurrent class unloading. This is only a minor nuisance now >> (effectively skipping class unloading for short-cut-cycles), but amounts >> to a real bug when we're going to do weak-roots-cleaning concurrently too. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8234974 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ >> >> Testing: hotspot_gc_shenandoah >> >> Can I please get a review? >> >> Roman >> > From per.liden at oracle.com Thu Dec 12 08:53:05 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 12 Dec 2019 09:53:05 +0100 Subject: 8235760: ZGC: Implement precise check for @require vm.gc.Z for Windows In-Reply-To: <53ce2649-e2b2-5bab-8226-4685bd745a27@oracle.com> References: <53ce2649-e2b2-5bab-8226-4685bd745a27@oracle.com> Message-ID: Thanks for fixing, looks good! /Per On 12/11/19 6:55 PM, Stefan Karlsson wrote: > Per wanted to move the is_os_supported from ZInitialize to ZArguments. > > Updated webrevs: > ?https://cr.openjdk.java.net/~stefank/8235760/webrev.02.delta/ > ?https://cr.openjdk.java.net/~stefank/8235760/webrev.02/ > > StefanK > > On 2019-12-11 13:10, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to reimplemente @require vm.gc.Z and >> WB_IsGCSupported to use a more precise check on Windows. >> >> https://cr.openjdk.java.net/~stefank/8235760/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8235760 >> >> With this patch we call into the VM and try to resolve the required >> Windows APIs, instead of doing string comparisons on system properties. >> >> Thanks, >> StefanK > From per.liden at oracle.com Thu Dec 12 08:53:46 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 12 Dec 2019 09:53:46 +0100 Subject: RFR: 8235696: ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state In-Reply-To: <421dd496-c190-9054-a93e-435628092d03@oracle.com> References: <09d73f65-48ce-6775-f88b-0a41202c9581@oracle.com> <421dd496-c190-9054-a93e-435628092d03@oracle.com> Message-ID: Thanks Stefan. /Per On 12/11/19 6:36 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-12-11 16:33, Per Liden wrote: >> The assert in ZRootsIteratorCodeBlobClosure::do_code_blob() fails to >> take into account that some nmethods don't have an entry barrier at >> all and those are always considered disarmed. This patch adjusts the >> assert accordingly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235696 >> Webrev: http://cr.openjdk.java.net/~pliden/8235696/webrev.0 >> >> /Per > From stefan.karlsson at oracle.com Thu Dec 12 09:09:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Dec 2019 10:09:05 +0100 Subject: RFR: 8235748: ZGC: Remove ZAddress::address() In-Reply-To: References: Message-ID: Looks good. StefanK On 2019-12-11 09:24, Per Liden wrote: > I propose that we remove ZAddress::address(). It was useful for the now > defunct Sparc port, but none of the currently supported architectures > need it. Should we ever need it in the future, we can easily add it again. > > Removing ZAddress::address() implies also removing ZAddressBase and the > initialization functions ZPlatformAddressBase(). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235748 > Webrev: http://cr.openjdk.java.net/~pliden/8235748/webrev.0 > > /Per From per.liden at oracle.com Thu Dec 12 09:10:10 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 12 Dec 2019 10:10:10 +0100 Subject: RFR: 8235748: ZGC: Remove ZAddress::address() In-Reply-To: References: Message-ID: <5ec7f741-6dab-dae2-2067-8938edb95b2d@oracle.com> Thanks Stefan. /Per On 12/12/19 10:09 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-12-11 09:24, Per Liden wrote: >> I propose that we remove ZAddress::address(). It was useful for the >> now defunct Sparc port, but none of the currently supported >> architectures need it. Should we ever need it in the future, we can >> easily add it again. >> >> Removing ZAddress::address() implies also removing ZAddressBase and >> the initialization functions ZPlatformAddressBase(). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235748 >> Webrev: http://cr.openjdk.java.net/~pliden/8235748/webrev.0 >> >> /Per From stefan.karlsson at oracle.com Thu Dec 12 12:01:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Dec 2019 13:01:05 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) Message-ID: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> Hi all, Please review this patch to fix a problem with unintialized values in our generation counters. https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8226797 The jstat values NGCMN and OGCMN both return uninitialized values. I stumbled upon this while creating a patch to remove the GenerationSpec class. GenerationSpec::_min_size is never initialized, and then used to create the generations: case Generation::DefNew: return new DefNewGeneration(rs, _init_size, _min_size, _max_size); case Generation::MarkSweepCompact: return new TenuredGeneration(rs, _init_size, _min_size, _max_size, remset); That in turn uses it to initialize the perf counters: DefNewGeneration::DefNewGeneration(ReservedSpace rs, size_t initial_size, size_t min_size, size_t max_size, const char* policy) ... _gen_counters = new GenerationCounters("new", 0, 3, min_size, max_size, &_virtual_space); I'm setting the value to _init_size, because it reflects how MinNewSize and MinOldSize relates to NewSize and OldSize. Thanks, StefanK From thomas.schatzl at oracle.com Thu Dec 12 12:05:48 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 12 Dec 2019 13:05:48 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> Message-ID: Hi, On 12.12.19 13:01, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix a problem with unintialized values in > our generation counters. > > https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8226797 > > The jstat values NGCMN and OGCMN both return uninitialized values. > > I stumbled upon this while creating a patch to remove the GenerationSpec > class. > > GenerationSpec::_min_size is never initialized, and then used to create > the generations: > > ??? case Generation::DefNew: > ????? return new DefNewGeneration(rs, _init_size, _min_size, _max_size); > > ??? case Generation::MarkSweepCompact: > ????? return new TenuredGeneration(rs, _init_size, _min_size, > _max_size, remset); > > That in turn uses it to initialize the perf counters: > DefNewGeneration::DefNewGeneration(ReservedSpace rs, > ?????????????????????????????????? size_t initial_size, > ?????????????????????????????????? size_t min_size, > ?????????????????????????????????? size_t max_size, > ?????????????????????????????????? const char* policy) > ... > ? _gen_counters = new GenerationCounters("new", 0, 3, > ????? min_size, max_size, &_virtual_space); > > I'm setting the value to _init_size, because it reflects how MinNewSize > and MinOldSize relates to NewSize and OldSize. Great find! Looks good. Thomas From rkennke at redhat.com Thu Dec 12 12:08:17 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 12 Dec 2019 13:08:17 +0100 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: <20f69c3b-9800-b146-b03e-86c46aba68c1@redhat.com> References: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> <20f69c3b-9800-b146-b03e-86c46aba68c1@redhat.com> Message-ID: <6316e674-04f8-b981-beff-a40b1655ab5d@redhat.com> Sorry, I mixed up this change with the subsequent concurrent roots cleaning here. Let's step back and get this part in shape first. Wait for next webrev, ok? Thanks, Roman > Second thought: I am not sure what problem you are trying to solve here, > let's talk tomorrow. > > Thanks, > > -Zhengyu > > On 12/11/19 5:12 PM, Roman Kennke wrote: >> After discussing off-line with Zhengyu, I am proposing those changes: >> >> - Reinstate returning object for GC threads (apparently needed b/c of >> bug in JVMTI) >> - Always heal nmethods in barrier. We can only get there during evac >> (see below) >> - ShenandoahEvacUpdateOopStorageRootsClosure renamed to >> ShenandoahEvacUpdateCleanupRootsClosure and let it also handle cleanup. >> - Changed order of cleanup and unload: first do cleanup, then do unload. >> - only call prepare_unloading() when we have a cset. This arms nmethods. >> We only ever want to get into nmethod-barriers when we have a cset/are >> doing evacuation. >> >> Incremental: >> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01.diff/ >> Full: >> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01/ >> >> Good now? >> >> Roman >> >>> Shenandoah can short-cut a cycle when the collection set remains empty, >>> and doesn't dive into concurrent evacuation and updating refs phases >>> then. However, this currently also precludes concurrent roots processing >>> and concurrent class unloading. This is only a minor nuisance now >>> (effectively skipping class unloading for short-cut-cycles), but amounts >>> to a real bug when we're going to do weak-roots-cleaning concurrently >>> too. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8234974 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ >>> >>> Testing: hotspot_gc_shenandoah >>> >>> Can I please get a review? >>> >>> Roman >>> >> > From stefan.johansson at oracle.com Thu Dec 12 12:27:26 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 12 Dec 2019 13:27:26 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> Message-ID: Hi Stefan, On 2019-12-12 13:05, Thomas Schatzl wrote: > Hi, > > On 12.12.19 13:01, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix a problem with unintialized values in >> our generation counters. >> >> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8226797 >> >> The jstat values NGCMN and OGCMN both return uninitialized values. >> >> I stumbled upon this while creating a patch to remove the >> GenerationSpec class. >> >> GenerationSpec::_min_size is never initialized, and then used to >> create the generations: >> >> ???? case Generation::DefNew: >> ?????? return new DefNewGeneration(rs, _init_size, _min_size, _max_size); >> >> ???? case Generation::MarkSweepCompact: >> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >> _max_size, remset); >> >> That in turn uses it to initialize the perf counters: >> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >> ??????????????????????????????????? size_t initial_size, >> ??????????????????????????????????? size_t min_size, >> ??????????????????????????????????? size_t max_size, >> ??????????????????????????????????? const char* policy) >> ... >> ?? _gen_counters = new GenerationCounters("new", 0, 3, >> ?????? min_size, max_size, &_virtual_space); >> >> I'm setting the value to _init_size, because it reflects how >> MinNewSize and MinOldSize relates to NewSize and OldSize. > > Great find! > > Looks good. Looks good to me too, StefanJ > > ?Thomas From suenaga at oss.nttdata.com Thu Dec 12 12:51:12 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 12 Dec 2019 21:51:12 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 Message-ID: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> Hi all, Please review this trivial change: JBS: https://bugs.openjdk.java.net/browse/JDK-8235819 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ I saw format-overflow warnings in g1GCPhaseTimes.cpp when I built jdk/jdk with GCC 9 on Fedora 31 as below: ------------------ /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:319:17: error: '%s' directive argument is null [-Werror=format-overflow=] 319 | out->print("%s", Indents[indent + 1]); | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------ Indents[] seems to be insufficient. We need to give enough entries to it. This patch passed all tests on submit repo (mach5-one-ysuenaga-JDK-8235819-20191212-0925-7464553). Thanks, Yasumasa From stefan.karlsson at oracle.com Thu Dec 12 12:52:55 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Dec 2019 13:52:55 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> Message-ID: <94fa3936-2613-f811-6466-98ddc62a24ba@oracle.com> Thanks, Thomas. StefanK On 2019-12-12 13:05, Thomas Schatzl wrote: > Hi, > > On 12.12.19 13:01, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix a problem with unintialized values in >> our generation counters. >> >> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8226797 >> >> The jstat values NGCMN and OGCMN both return uninitialized values. >> >> I stumbled upon this while creating a patch to remove the >> GenerationSpec class. >> >> GenerationSpec::_min_size is never initialized, and then used to >> create the generations: >> >> ???? case Generation::DefNew: >> ?????? return new DefNewGeneration(rs, _init_size, _min_size, _max_size); >> >> ???? case Generation::MarkSweepCompact: >> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >> _max_size, remset); >> >> That in turn uses it to initialize the perf counters: >> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >> ??????????????????????????????????? size_t initial_size, >> ??????????????????????????????????? size_t min_size, >> ??????????????????????????????????? size_t max_size, >> ??????????????????????????????????? const char* policy) >> ... >> ?? _gen_counters = new GenerationCounters("new", 0, 3, >> ?????? min_size, max_size, &_virtual_space); >> >> I'm setting the value to _init_size, because it reflects how >> MinNewSize and MinOldSize relates to NewSize and OldSize. > > Great find! > > Looks good. > > ?Thomas From stefan.karlsson at oracle.com Thu Dec 12 12:53:23 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Dec 2019 13:53:23 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> Message-ID: <7b09fd3b-da73-780f-30e1-d20cca83e53c@oracle.com> Thanks, StefanJ. StefanK On 2019-12-12 13:27, Stefan Johansson wrote: > Hi Stefan, > > On 2019-12-12 13:05, Thomas Schatzl wrote: >> Hi, >> >> On 12.12.19 13:01, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to fix a problem with unintialized values in >>> our generation counters. >>> >>> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8226797 >>> >>> The jstat values NGCMN and OGCMN both return uninitialized values. >>> >>> I stumbled upon this while creating a patch to remove the >>> GenerationSpec class. >>> >>> GenerationSpec::_min_size is never initialized, and then used to >>> create the generations: >>> >>> ???? case Generation::DefNew: >>> ?????? return new DefNewGeneration(rs, _init_size, _min_size, >>> _max_size); >>> >>> ???? case Generation::MarkSweepCompact: >>> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >>> _max_size, remset); >>> >>> That in turn uses it to initialize the perf counters: >>> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >>> ??????????????????????????????????? size_t initial_size, >>> ??????????????????????????????????? size_t min_size, >>> ??????????????????????????????????? size_t max_size, >>> ??????????????????????????????????? const char* policy) >>> ... >>> ?? _gen_counters = new GenerationCounters("new", 0, 3, >>> ?????? min_size, max_size, &_virtual_space); >>> >>> I'm setting the value to _init_size, because it reflects how >>> MinNewSize and MinOldSize relates to NewSize and OldSize. >> >> Great find! >> >> Looks good. > Looks good to me too, > StefanJ > >> >> ??Thomas From leo.korinth at oracle.com Thu Dec 12 14:26:26 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 12 Dec 2019 15:26:26 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> Message-ID: <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> Hi, Your fix looks good to me (I am not a reviewer). Thanks for fixing this! In the long run, I believe a better solution would be two have a separate function for doing the indentation so that one could use format strings to make the indentation level work for any level or, at least, assert on over-run. This is a good fix for now however. Thanks, Leo On 12/12/2019 13:51, Yasumasa Suenaga wrote: > Hi all, > > Please review this trivial change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8235819 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ > > I saw format-overflow warnings in g1GCPhaseTimes.cpp when I built > jdk/jdk with GCC 9 on Fedora 31 as below: > > ------------------ > /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:319:17: > error: '%s' directive argument is null [-Werror=format-overflow=] > ? 319 | out->print("%s", Indents[indent + 1]); > ????? | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ > ------------------ > > Indents[] seems to be insufficient. > We need to give enough entries to it. > > This patch passed all tests on submit repo > (mach5-one-ysuenaga-JDK-8235819-20191212-0925-7464553). > > > Thanks, > > Yasumasa From stefan.karlsson at oracle.com Thu Dec 12 15:23:09 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Dec 2019 16:23:09 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> Message-ID: <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> In the interest to get this integrated before the RDP cut-off I'm going to push this ASAP. This has gone through tier1-tier3 testing. StefanK On 2019-12-12 13:01, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix a problem with unintialized values in > our generation counters. > > https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8226797 > > The jstat values NGCMN and OGCMN both return uninitialized values. > > I stumbled upon this while creating a patch to remove the GenerationSpec > class. > > GenerationSpec::_min_size is never initialized, and then used to create > the generations: > > ??? case Generation::DefNew: > ????? return new DefNewGeneration(rs, _init_size, _min_size, _max_size); > > ??? case Generation::MarkSweepCompact: > ????? return new TenuredGeneration(rs, _init_size, _min_size, > _max_size, remset); > > That in turn uses it to initialize the perf counters: > DefNewGeneration::DefNewGeneration(ReservedSpace rs, > ?????????????????????????????????? size_t initial_size, > ?????????????????????????????????? size_t min_size, > ?????????????????????????????????? size_t max_size, > ?????????????????????????????????? const char* policy) > ... > ? _gen_counters = new GenerationCounters("new", 0, 3, > ????? min_size, max_size, &_virtual_space); > > I'm setting the value to _init_size, because it reflects how MinNewSize > and MinOldSize relates to NewSize and OldSize. > > Thanks, > StefanK From daniel.daugherty at oracle.com Thu Dec 12 16:06:14 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Dec 2019 11:06:14 -0500 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> Message-ID: <8ee949e7-b7c2-b8b7-e7fc-eaaff444e59f@oracle.com> src/hotspot/share/gc/shared/generationSpec.hpp ??? No comments. test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCapacityResults.java ??? No comments. Thumbs up. Dan On 12/12/19 10:23 AM, Stefan Karlsson wrote: > In the interest to get this integrated before the RDP cut-off I'm > going to push this ASAP. This has gone through tier1-tier3 testing. > > StefanK > > On 2019-12-12 13:01, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix a problem with unintialized values in >> our generation counters. >> >> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8226797 >> >> The jstat values NGCMN and OGCMN both return uninitialized values. >> >> I stumbled upon this while creating a patch to remove the >> GenerationSpec class. >> >> GenerationSpec::_min_size is never initialized, and then used to >> create the generations: >> >> ???? case Generation::DefNew: >> ?????? return new DefNewGeneration(rs, _init_size, _min_size, >> _max_size); >> >> ???? case Generation::MarkSweepCompact: >> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >> _max_size, remset); >> >> That in turn uses it to initialize the perf counters: >> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >> ??????????????????????????????????? size_t initial_size, >> ??????????????????????????????????? size_t min_size, >> ??????????????????????????????????? size_t max_size, >> ??????????????????????????????????? const char* policy) >> ... >> ?? _gen_counters = new GenerationCounters("new", 0, 3, >> ?????? min_size, max_size, &_virtual_space); >> >> I'm setting the value to _init_size, because it reflects how >> MinNewSize and MinOldSize relates to NewSize and OldSize. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu Dec 12 16:19:23 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Dec 2019 17:19:23 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: <8ee949e7-b7c2-b8b7-e7fc-eaaff444e59f@oracle.com> References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> <8ee949e7-b7c2-b8b7-e7fc-eaaff444e59f@oracle.com> Message-ID: <50c7ec6f-5cd1-3363-02be-1a9058942d89@oracle.com> Thanks, Dan. StefanK On 2019-12-12 17:06, Daniel D. Daugherty wrote: > src/hotspot/share/gc/shared/generationSpec.hpp > ??? No comments. > > test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCapacityResults.java > > ??? No comments. > > Thumbs up. > > Dan > > > On 12/12/19 10:23 AM, Stefan Karlsson wrote: >> In the interest to get this integrated before the RDP cut-off I'm >> going to push this ASAP. This has gone through tier1-tier3 testing. >> >> StefanK >> >> On 2019-12-12 13:01, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to fix a problem with unintialized values in >>> our generation counters. >>> >>> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8226797 >>> >>> The jstat values NGCMN and OGCMN both return uninitialized values. >>> >>> I stumbled upon this while creating a patch to remove the >>> GenerationSpec class. >>> >>> GenerationSpec::_min_size is never initialized, and then used to >>> create the generations: >>> >>> ???? case Generation::DefNew: >>> ?????? return new DefNewGeneration(rs, _init_size, _min_size, >>> _max_size); >>> >>> ???? case Generation::MarkSweepCompact: >>> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >>> _max_size, remset); >>> >>> That in turn uses it to initialize the perf counters: >>> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >>> ??????????????????????????????????? size_t initial_size, >>> ??????????????????????????????????? size_t min_size, >>> ??????????????????????????????????? size_t max_size, >>> ??????????????????????????????????? const char* policy) >>> ... >>> ?? _gen_counters = new GenerationCounters("new", 0, 3, >>> ?????? min_size, max_size, &_virtual_space); >>> >>> I'm setting the value to _init_size, because it reflects how >>> MinNewSize and MinOldSize relates to NewSize and OldSize. >>> >>> Thanks, >>> StefanK > From rkennke at redhat.com Thu Dec 12 17:02:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 12 Dec 2019 18:02:29 +0100 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: References: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> Message-ID: <84db9fbf-e097-ad29-b10e-b82bc935e870@redhat.com> Sorry, I mixed up this patch with parts of concurrent weakroots cleaning. Here's the cleaned-up patch: http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.02/ What do you think? Roman > Hi Roman, > > This patch is a bit confusing, as it along, cleaning up weak roots > during concurrent roots phase is unnecessary, because they are cleaned > in parallel cleaning during final mark pause. Should it be part of > concurrent weak root processing,? e.g. JDK-8228818? > > Nit: probably should rename > ShenandoahCodeRoots::prepare_concurrent_unloading() to > ShenandoahCodeRoots::arm_nmethods() > > Otherwise, looks good. > > Thanks, > > -Zhengyu > > > On 12/11/19 5:12 PM, Roman Kennke wrote: >> After discussing off-line with Zhengyu, I am proposing those changes: >> >> - Reinstate returning object for GC threads (apparently needed b/c of >> bug in JVMTI) >> - Always heal nmethods in barrier. We can only get there during evac >> (see below) >> - ShenandoahEvacUpdateOopStorageRootsClosure renamed to >> ShenandoahEvacUpdateCleanupRootsClosure and let it also handle cleanup. >> - Changed order of cleanup and unload: first do cleanup, then do unload. >> - only call prepare_unloading() when we have a cset. This arms nmethods. >> We only ever want to get into nmethod-barriers when we have a cset/are >> doing evacuation. >> >> Incremental: >> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01.diff/ >> Full: >> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01/ >> >> Good now? >> >> Roman >> >>> Shenandoah can short-cut a cycle when the collection set remains empty, >>> and doesn't dive into concurrent evacuation and updating refs phases >>> then. However, this currently also precludes concurrent roots processing >>> and concurrent class unloading. This is only a minor nuisance now >>> (effectively skipping class unloading for short-cut-cycles), but amounts >>> to a real bug when we're going to do weak-roots-cleaning concurrently >>> too. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8234974 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ >>> >>> Testing: hotspot_gc_shenandoah >>> >>> Can I please get a review? >>> >>> Roman >>> >> > From zgu at redhat.com Thu Dec 12 17:26:31 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Dec 2019 12:26:31 -0500 Subject: RFR: 8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary In-Reply-To: <84db9fbf-e097-ad29-b10e-b82bc935e870@redhat.com> References: <46399c52-aa0a-7a3a-ded1-ad27b220a240@redhat.com> <84db9fbf-e097-ad29-b10e-b82bc935e870@redhat.com> Message-ID: Okay. Thanks, -Zhengyu On 12/12/19 12:02 PM, Roman Kennke wrote: > Sorry, I mixed up this patch with parts of concurrent weakroots > cleaning. Here's the cleaned-up patch: > > http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.02/ > > What do you think? > > Roman > > >> Hi Roman, >> >> This patch is a bit confusing, as it along, cleaning up weak roots >> during concurrent roots phase is unnecessary, because they are cleaned >> in parallel cleaning during final mark pause. Should it be part of >> concurrent weak root processing,? e.g. JDK-8228818? >> >> Nit: probably should rename >> ShenandoahCodeRoots::prepare_concurrent_unloading() to >> ShenandoahCodeRoots::arm_nmethods() >> >> Otherwise, looks good. >> >> Thanks, >> >> -Zhengyu >> >> >> On 12/11/19 5:12 PM, Roman Kennke wrote: >>> After discussing off-line with Zhengyu, I am proposing those changes: >>> >>> - Reinstate returning object for GC threads (apparently needed b/c of >>> bug in JVMTI) >>> - Always heal nmethods in barrier. We can only get there during evac >>> (see below) >>> - ShenandoahEvacUpdateOopStorageRootsClosure renamed to >>> ShenandoahEvacUpdateCleanupRootsClosure and let it also handle cleanup. >>> - Changed order of cleanup and unload: first do cleanup, then do unload. >>> - only call prepare_unloading() when we have a cset. This arms nmethods. >>> We only ever want to get into nmethod-barriers when we have a cset/are >>> doing evacuation. >>> >>> Incremental: >>> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01.diff/ >>> Full: >>> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.01/ >>> >>> Good now? >>> >>> Roman >>> >>>> Shenandoah can short-cut a cycle when the collection set remains empty, >>>> and doesn't dive into concurrent evacuation and updating refs phases >>>> then. However, this currently also precludes concurrent roots processing >>>> and concurrent class unloading. This is only a minor nuisance now >>>> (effectively skipping class unloading for short-cut-cycles), but amounts >>>> to a real bug when we're going to do weak-roots-cleaning concurrently >>>> too. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8234974 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8234974/webrev.00/ >>>> >>>> Testing: hotspot_gc_shenandoah >>>> >>>> Can I please get a review? >>>> >>>> Roman >>>> >>> >> > From zgu at redhat.com Thu Dec 12 20:17:33 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Dec 2019 15:17:33 -0500 Subject: RFR(XS) 8235842: Shenandoah: Implement native LRB for narrow oop Message-ID: Thanks Jie for reporting and verifying the problem. Shenandoah used to assume that no compressed oops store in roots, but leak profiler store compressed oops in UnifiedOopRef. This patch adds native LRB for compressed oop. Bug: https://bugs.openjdk.java.net/browse/JDK-8235842 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235842/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Jie verified original bug with jmc. Thanks, -Zhengyu From rkennke at redhat.com Thu Dec 12 20:18:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 12 Dec 2019 21:18:56 +0100 Subject: RFR(XS) 8235842: Shenandoah: Implement native LRB for narrow oop In-Reply-To: References: Message-ID: <59e587aa-ff43-182e-371c-867bfa3067a7@redhat.com> Looks good. Go! Thanks, Roman > Thanks Jie for reporting and verifying the problem. > > Shenandoah used to assume that no compressed oops store in roots, but > leak profiler store compressed oops in UnifiedOopRef. > > This patch adds native LRB for compressed oop. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235842 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8235842/webrev.00/ > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) > ? Jie verified original bug with jmc. > > Thanks, > > -Zhengyu > From serguei.spitsyn at oracle.com Fri Dec 13 00:41:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Dec 2019 16:41:12 -0800 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> Message-ID: <35c25ed3-948b-482d-2f21-1ffffdf1afd9@oracle.com> Hi Stefan, It looks good to me. Sorry, I was on the meeting, wrote this email and forgot to push 'send' button. Just now discovered that it has not been really sent. :( Thanks, Serguei On 12/12/19 07:23, Stefan Karlsson wrote: > In the interest to get this integrated before the RDP cut-off I'm > going to push this ASAP. This has gone through tier1-tier3 testing. > > StefanK > > On 2019-12-12 13:01, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix a problem with unintialized values in >> our generation counters. >> >> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8226797 >> >> The jstat values NGCMN and OGCMN both return uninitialized values. >> >> I stumbled upon this while creating a patch to remove the >> GenerationSpec class. >> >> GenerationSpec::_min_size is never initialized, and then used to >> create the generations: >> >> ???? case Generation::DefNew: >> ?????? return new DefNewGeneration(rs, _init_size, _min_size, >> _max_size); >> >> ???? case Generation::MarkSweepCompact: >> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >> _max_size, remset); >> >> That in turn uses it to initialize the perf counters: >> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >> ??????????????????????????????????? size_t initial_size, >> ??????????????????????????????????? size_t min_size, >> ??????????????????????????????????? size_t max_size, >> ??????????????????????????????????? const char* policy) >> ... >> ?? _gen_counters = new GenerationCounters("new", 0, 3, >> ?????? min_size, max_size, &_virtual_space); >> >> I'm setting the value to _init_size, because it reflects how >> MinNewSize and MinOldSize relates to NewSize and OldSize. >> >> Thanks, >> StefanK From suenaga at oss.nttdata.com Fri Dec 13 02:03:18 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 13 Dec 2019 11:03:18 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> Message-ID: Hi Leo, Thank you for your review. On 2019/12/12 23:26, Leo Korinth wrote: > Hi, > > Your fix looks good to me (I am not a reviewer). Thanks for fixing this! > > In the long run, I believe a better solution would be two have a separate function for doing the indentation so that one could use format strings to make the indentation level work for any level or, at least, assert on over-run. This is a good fix for now however. Did you suggest like this? http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/indent-function/ I agree with you basically, but this code is for logging. So I think it prefers simple. In addition, we can catch the overrun via compiler warnings. Indents[] is also used with literal in G1GCPhaseTimes::info_time() and more. If we change Indents[] in future, they might be broken. Of course we can add assert() to each codes, but it is strange, IMHO. Thus I think we can take two approaches: 1) Extends Indents[] if we need (webrev.00) 2) Add a function to generate indent string (indent-function) I prefer 1) at this time. Thanks, Yasumasa > Thanks, > Leo > > > On 12/12/2019 13:51, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this trivial change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8235819 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ >> >> I saw format-overflow warnings in g1GCPhaseTimes.cpp when I built jdk/jdk with GCC 9 on Fedora 31 as below: >> >> ------------------ >> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:319:17: error: '%s' directive argument is null [-Werror=format-overflow=] >> ?? 319 | out->print("%s", Indents[indent + 1]); >> ?????? | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ------------------ >> >> Indents[] seems to be insufficient. >> We need to give enough entries to it. >> >> This patch passed all tests on submit repo (mach5-one-ysuenaga-JDK-8235819-20191212-0925-7464553). >> >> >> Thanks, >> >> Yasumasa From stefan.karlsson at oracle.com Fri Dec 13 08:39:29 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Dec 2019 09:39:29 +0100 Subject: RFR: 8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity) In-Reply-To: <35c25ed3-948b-482d-2f21-1ffffdf1afd9@oracle.com> References: <93c9ec14-a371-0121-d758-7e213cde9c85@oracle.com> <1fc22506-3e64-fb98-8f7d-acb460c986f5@oracle.com> <35c25ed3-948b-482d-2f21-1ffffdf1afd9@oracle.com> Message-ID: <5b5bbdd0-b1a0-4c1c-ee13-ce8adbbca592@oracle.com> Hi Serguei, On 2019-12-13 01:41, serguei.spitsyn at oracle.com wrote: > Hi Stefan, > > It looks good to me. Thanks for reviewing. > > Sorry, I was on the meeting, wrote this email and forgot to push 'send' > button. > Just now discovered that it has not been really sent. :( No problem. I pushed this yesterday to make the JDK 14 fork cut-off. Thanks, StefanK > > Thanks, > Serguei > > > On 12/12/19 07:23, Stefan Karlsson wrote: >> In the interest to get this integrated before the RDP cut-off I'm >> going to push this ASAP. This has gone through tier1-tier3 testing. >> >> StefanK >> >> On 2019-12-12 13:01, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to fix a problem with unintialized values in >>> our generation counters. >>> >>> https://cr.openjdk.java.net/~stefank/8226797/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8226797 >>> >>> The jstat values NGCMN and OGCMN both return uninitialized values. >>> >>> I stumbled upon this while creating a patch to remove the >>> GenerationSpec class. >>> >>> GenerationSpec::_min_size is never initialized, and then used to >>> create the generations: >>> >>> ???? case Generation::DefNew: >>> ?????? return new DefNewGeneration(rs, _init_size, _min_size, >>> _max_size); >>> >>> ???? case Generation::MarkSweepCompact: >>> ?????? return new TenuredGeneration(rs, _init_size, _min_size, >>> _max_size, remset); >>> >>> That in turn uses it to initialize the perf counters: >>> DefNewGeneration::DefNewGeneration(ReservedSpace rs, >>> ??????????????????????????????????? size_t initial_size, >>> ??????????????????????????????????? size_t min_size, >>> ??????????????????????????????????? size_t max_size, >>> ??????????????????????????????????? const char* policy) >>> ... >>> ?? _gen_counters = new GenerationCounters("new", 0, 3, >>> ?????? min_size, max_size, &_virtual_space); >>> >>> I'm setting the value to _init_size, because it reflects how >>> MinNewSize and MinOldSize relates to NewSize and OldSize. >>> >>> Thanks, >>> StefanK > From per.liden at oracle.com Fri Dec 13 11:47:42 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 13 Dec 2019 12:47:42 +0100 Subject: RFR: 8235905: ZGC: Rework how ZRootsIterator visits threads Message-ID: <05f553ce-8bea-2958-97dc-f41cf8556da6@oracle.com> In preparation for concurrent thread stack scanning, this patch reworks how we visit threads during roots scanning, so that the part visiting Java threads can be easily moved to a concurrent phase at a later stage. The new ZJavaThreadIterator is also a performance optimization over Threads::possibly_parallel_threads_do(), since it will do fewer atomic operations (by a factor of ParallelGCThreads). Bug: https://bugs.openjdk.java.net/browse/JDK-8235905 Webrev: http://cr.openjdk.java.net/~pliden/8235905/webrev.0 /Per From stefan.karlsson at oracle.com Fri Dec 13 12:24:53 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Dec 2019 13:24:53 +0100 Subject: RFR: 8235905: ZGC: Rework how ZRootsIterator visits threads In-Reply-To: <05f553ce-8bea-2958-97dc-f41cf8556da6@oracle.com> References: <05f553ce-8bea-2958-97dc-f41cf8556da6@oracle.com> Message-ID: <367a36a5-8f12-b541-3e81-ffe228b299c5@oracle.com> Looks good. StefanK On 2019-12-13 12:47, Per Liden wrote: > In preparation for concurrent thread stack scanning, this patch reworks > how we visit threads during roots scanning, so that the part visiting > Java threads can be easily moved to a concurrent phase at a later stage. > > The new ZJavaThreadIterator is also a performance optimization over > Threads::possibly_parallel_threads_do(), since it will do fewer atomic > operations (by a factor of ParallelGCThreads). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235905 > Webrev: http://cr.openjdk.java.net/~pliden/8235905/webrev.0 > > /Per From leo.korinth at oracle.com Fri Dec 13 13:33:25 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 13 Dec 2019 14:33:25 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> Message-ID: <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> On 13/12/2019 03:03, Yasumasa Suenaga wrote: > Hi Leo, > > Thank you for your review. > > On 2019/12/12 23:26, Leo Korinth wrote: >> Hi, >> >> Your fix looks good to me (I am not a reviewer). Thanks for fixing this! >> >> In the long run, I believe a better solution would be two have a >> separate function for doing the indentation so that one could use >> format strings to make the indentation level work for any level or, at >> least, assert on over-run. This is a good fix for now however. > > Did you suggest like this? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/indent-function/ no, I thought something more like this (not tested): const char* indent(unsigned n) { static const char* indents[] = {"", " ", " ", " ", " ", " "}; assert(n < ARRAY_SIZE(indents), "overflow"); return indents[n]; } or maybe: const char* indent(unsigned n) { static const char spaces[] = " "; const unsigned SPACE_COUNT = 2; const unsigned len = ARRAY_SIZE(spaces) - 1; assert(n*SPACE_COUNT <= len, "underflow"); return &spaces[len - n*SPACE_COUNT]; } Both of these will just change the code on the caller side from Indent[expression] to indent(expression), with the benefit of a runtime assert that will fail when the compiler can not infer the overrun at compile time. Another solution would be to use format strings, and something like this: expression("%*s%s", 2*indent, "", "indented string"); This requires no assert, but is harder to understand and requires more changes. But as I said, I think your original fix is good. Thanks, Leo > > I agree with you basically, but this code is for logging. So I think it > prefers simple. > In addition, we can catch the overrun via compiler warnings. > > Indents[] is also used with literal in G1GCPhaseTimes::info_time() and > more. > If we change Indents[] in future, they might be broken. > Of course we can add assert() to each codes, but it is strange, IMHO. > > Thus I think we can take two approaches: > > ? 1) Extends Indents[] if we need (webrev.00) > ? 2) Add a function to generate indent string (indent-function) > > I prefer 1) at this time. > > > Thanks, > > Yasumasa > > >> Thanks, >> Leo >> >> >> On 12/12/2019 13:51, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this trivial change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8235819 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ >>> >>> I saw format-overflow warnings in g1GCPhaseTimes.cpp when I built >>> jdk/jdk with GCC 9 on Fedora 31 as below: >>> >>> ------------------ >>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:319:17: >>> error: '%s' directive argument is null [-Werror=format-overflow=] >>> ?? 319 | out->print("%s", Indents[indent + 1]); >>> ?????? | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> ------------------ >>> >>> Indents[] seems to be insufficient. >>> We need to give enough entries to it. >>> >>> This patch passed all tests on submit repo >>> (mach5-one-ysuenaga-JDK-8235819-20191212-0925-7464553). >>> >>> >>> Thanks, >>> >>> Yasumasa From per.liden at oracle.com Fri Dec 13 14:01:30 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 13 Dec 2019 15:01:30 +0100 Subject: RFR: 8235905: ZGC: Rework how ZRootsIterator visits threads In-Reply-To: <367a36a5-8f12-b541-3e81-ffe228b299c5@oracle.com> References: <05f553ce-8bea-2958-97dc-f41cf8556da6@oracle.com> <367a36a5-8f12-b541-3e81-ffe228b299c5@oracle.com> Message-ID: <996aca1f-b777-247e-f88a-59cadc7e925c@oracle.com> Thanks Stefan! /Per On 2019-12-13 13:24, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-12-13 12:47, Per Liden wrote: >> In preparation for concurrent thread stack scanning, this patch >> reworks how we visit threads during roots scanning, so that the part >> visiting Java threads can be easily moved to a concurrent phase at a >> later stage. >> >> The new ZJavaThreadIterator is also a performance optimization over >> Threads::possibly_parallel_threads_do(), since it will do fewer atomic >> operations (by a factor of ParallelGCThreads). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235905 >> Webrev: http://cr.openjdk.java.net/~pliden/8235905/webrev.0 >> >> /Per From suenaga at oss.nttdata.com Fri Dec 13 14:42:02 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 13 Dec 2019 23:42:02 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> Message-ID: <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> Hi Leo, Thanks for clarifying. I continue to wait Reviewer for webrev.00 . >>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ Thanks, Yasumasa On 2019/12/13 22:33, Leo Korinth wrote: > On 13/12/2019 03:03, Yasumasa Suenaga wrote: >> Hi Leo, >> >> Thank you for your review. >> >> On 2019/12/12 23:26, Leo Korinth wrote: >>> Hi, >>> >>> Your fix looks good to me (I am not a reviewer). Thanks for fixing this! >>> >>> In the long run, I believe a better solution would be two have a separate function for doing the indentation so that one could use format strings to make the indentation level work for any level or, at least, assert on over-run. This is a good fix for now however. >> >> Did you suggest like this? >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/indent-function/ > no, I thought something more like this (not tested): > > const char* indent(unsigned n) { > ? static const char* indents[] = {"", "? ", "??? ", "????? ", " ", "????????? "}; > ? assert(n < ARRAY_SIZE(indents), "overflow"); > ? return indents[n]; > } > > or maybe: > > const char* indent(unsigned n) { > ? static const char spaces[] = "?????????????????????????????? "; > ? const unsigned SPACE_COUNT = 2; > ? const unsigned len = ARRAY_SIZE(spaces) - 1; > > ? assert(n*SPACE_COUNT <= len, "underflow"); > ? return &spaces[len - n*SPACE_COUNT]; > } > > Both of these will just change the code on the caller side from Indent[expression] to indent(expression), with the benefit of a runtime assert that will fail when the compiler can not infer the overrun at compile time. > > Another solution would be to use format strings, and something like this: > > expression("%*s%s", 2*indent, "", "indented string"); > > This requires no assert, but is harder to understand and requires more changes. > > But as I said, I think your original fix is good. > > Thanks, > Leo > >> >> I agree with you basically, but this code is for logging. So I think it prefers simple. >> In addition, we can catch the overrun via compiler warnings. >> >> Indents[] is also used with literal in G1GCPhaseTimes::info_time() and more. >> If we change Indents[] in future, they might be broken. >> Of course we can add assert() to each codes, but it is strange, IMHO. >> >> Thus I think we can take two approaches: >> >> ?? 1) Extends Indents[] if we need (webrev.00) >> ?? 2) Add a function to generate indent string (indent-function) >> >> I prefer 1) at this time. >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, >>> Leo >>> >>> >>> On 12/12/2019 13:51, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this trivial change: >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8235819 >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ >>>> >>>> I saw format-overflow warnings in g1GCPhaseTimes.cpp when I built jdk/jdk with GCC 9 on Fedora 31 as below: >>>> >>>> ------------------ >>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:319:17: error: '%s' directive argument is null [-Werror=format-overflow=] >>>> ?? 319 | out->print("%s", Indents[indent + 1]); >>>> ?????? | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> ------------------ >>>> >>>> Indents[] seems to be insufficient. >>>> We need to give enough entries to it. >>>> >>>> This patch passed all tests on submit repo (mach5-one-ysuenaga-JDK-8235819-20191212-0925-7464553). >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From thomas.schatzl at oracle.com Fri Dec 13 19:28:49 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 Dec 2019 20:28:49 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> Message-ID: <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> Hi, On 13.12.19 15:42, Yasumasa Suenaga wrote: > Hi Leo, > > Thanks for clarifying. > I continue to wait Reviewer for webrev.00 . > >>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ > I would prefer to implement Leo's suggestion. Looking at the code, the warning is a false positive, as in actual execution the index never goes to 5 (e.g. YoungFreeCSet does not have sub-items afaict), and the _work_items != NULL check prevents it from being an actual issue. I am open to making GCC happy by extending the array *if* the manual check/assert does not help, which gcc very likely does not recognize, too. Thanks, Thomas From thomas.schatzl at oracle.com Fri Dec 13 19:46:01 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 Dec 2019 20:46:01 +0100 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: References: Message-ID: Hi all, ??? can I have reviews for this small change that removes uses of the flag UseParallelOldGC from testing? With jdk15 this flag has been obsoleted, so all tests using it error out. There are follow-up RFEs to remove and eventually clean out parallel gc serial old code, but this at least makes the failures go away. CR: https://bugs.openjdk.java.net/browse/JDK-8235907 Webrev: http://cr.openjdk.java.net/~tschatzl/8235907/webrev/ Testing: hs-tier1-5 (still running, almost complete) Thanks, ? Thomas From igor.ignatyev at oracle.com Fri Dec 13 21:55:27 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 13 Dec 2019 13:55:27 -0800 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: References: Message-ID: <968935BB-6CE1-47B3-8CBF-DEFA99FBDE76@oracle.com> Hi Thomas, (not a review) Dean and/or Igor might know better, but I believe src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py needs a special handling as it part of graal source; so its changes will be reverted by a next graal update. -- Igor > On Dec 13, 2019, at 11:46 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this small change that removes uses of the > flag UseParallelOldGC from testing? With jdk15 this flag has been > obsoleted, so all tests using it error out. > > There are follow-up RFEs to remove and eventually clean out parallel gc > serial old code, but this at least makes the failures go away. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235907 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235907/webrev/ > Testing: > hs-tier1-5 (still running, almost complete) > > Thanks, > Thomas > From dean.long at oracle.com Sat Dec 14 00:31:08 2019 From: dean.long at oracle.com (Dean Long) Date: Fri, 13 Dec 2019 16:31:08 -0800 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: <968935BB-6CE1-47B3-8CBF-DEFA99FBDE76@oracle.com> References: <968935BB-6CE1-47B3-8CBF-DEFA99FBDE76@oracle.com> Message-ID: I don't think it matters.? It looks like .mx.graal was added by mistake, and I can't find a corresponding sanitycheck.py in upstream Graal anymore.? I think you can just skip that file and file an RFE to delete src/jdk.internal.vm.compiler/.mx.graal. dl On 12/13/19 1:55 PM, Igor Ignatyev wrote: > Hi Thomas, > > (not a review) > > Dean and/or Igor might know better, but I believe src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py needs a special handling as it part of graal source; so its changes will be reverted by a next graal update. > > -- Igor > >> On Dec 13, 2019, at 11:46 AM, Thomas Schatzl wrote: >> >> Hi all, >> >> can I have reviews for this small change that removes uses of the >> flag UseParallelOldGC from testing? With jdk15 this flag has been >> obsoleted, so all tests using it error out. >> >> There are follow-up RFEs to remove and eventually clean out parallel gc >> serial old code, but this at least makes the failures go away. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235907 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235907/webrev/ >> Testing: >> hs-tier1-5 (still running, almost complete) >> >> Thanks, >> Thomas >> From suenaga at oss.nttdata.com Sun Dec 15 06:08:15 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sun, 15 Dec 2019 15:08:15 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> Message-ID: <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> Hi Thomas, Leo, How about this change? http://hg.openjdk.java.net/jdk/submit/rev/10816e67561a It generates indent string via alloca(). So get_indent() should be inlined. However it was failed at TestGCLogMessages on macOS only on submit repo (mach5-one-ysuenaga-JDK-8235819-1-20191215-0359-7545712). If you are generally ok to this change, could you share details of this failure? I will fix it. Thanks, Yasumasa On 2019/12/14 4:28, Thomas Schatzl wrote: > Hi, > > On 13.12.19 15:42, Yasumasa Suenaga wrote: >> Hi Leo, >> >> Thanks for clarifying. >> I continue to wait Reviewer for webrev.00 . >> >>>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ >> > > ? I would prefer to implement Leo's suggestion. > > Looking at the code, the warning is a false positive, as in actual execution the index never goes to 5 (e.g. YoungFreeCSet does not have sub-items afaict), and the _work_items != NULL check prevents it from being an actual issue. > > I am open to making GCC happy by extending the array *if* the manual check/assert does not help, which gcc very likely does not recognize, too. > > Thanks, > ? Thomas From leo.korinth at oracle.com Mon Dec 16 09:53:34 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 16 Dec 2019 10:53:34 +0100 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: References: Message-ID: <38dba6bb-4797-0428-60fe-561f22500934@oracle.com> This change looks good to me. Thanks, Leo On 13/12/2019 20:46, Thomas Schatzl wrote: > Hi all, > > ???? can I have reviews for this small change that removes uses of the > flag UseParallelOldGC from testing? With jdk15 this flag has been > obsoleted, so all tests using it error out. > > There are follow-up RFEs to remove and eventually clean out parallel gc > serial old code, but this at least makes the failures go away. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235907 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235907/webrev/ > Testing: > hs-tier1-5 (still running, almost complete) > > Thanks, > ?? Thomas > From suenaga at oss.nttdata.com Mon Dec 16 10:12:04 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 16 Dec 2019 19:12:04 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> Message-ID: <661d07f3-82b2-e5aa-a3f4-d0d2ac0f72ed@oss.nttdata.com> Also we can use macro to resolve this issue: http://hg.openjdk.java.net/jdk/submit/rev/219fdca61e3a I prefer to use dynamic allocation and format string because it is more secure. This change makes not so large. It passed tests on submit repo (mach5-one-ysuenaga-JDK-8235819-3-20191216-0731-7570580). Thanks, Yasumasa On 2019/12/15 15:08, Yasumasa Suenaga wrote: > Hi Thomas, Leo, > > How about this change? > > ? http://hg.openjdk.java.net/jdk/submit/rev/10816e67561a > > It generates indent string via alloca(). > So get_indent() should be inlined. > > However it was failed at TestGCLogMessages on macOS only on submit repo (mach5-one-ysuenaga-JDK-8235819-1-20191215-0359-7545712). > > If you are generally ok to this change, could you share details of this failure? > I will fix it. > > > Thanks, > > Yasumasa > > > On 2019/12/14 4:28, Thomas Schatzl wrote: >> Hi, >> >> On 13.12.19 15:42, Yasumasa Suenaga wrote: >>> Hi Leo, >>> >>> Thanks for clarifying. >>> I continue to wait Reviewer for webrev.00 . >>> >>>>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.00/ >>> >> >> ?? I would prefer to implement Leo's suggestion. >> >> Looking at the code, the warning is a false positive, as in actual execution the index never goes to 5 (e.g. YoungFreeCSet does not have sub-items afaict), and the _work_items != NULL check prevents it from being an actual issue. >> >> I am open to making GCC happy by extending the array *if* the manual check/assert does not help, which gcc very likely does not recognize, too. >> >> Thanks, >> ?? Thomas From thomas.schatzl at oracle.com Mon Dec 16 10:19:59 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Dec 2019 11:19:59 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> Message-ID: Hi, On 15.12.19 07:08, Yasumasa Suenaga wrote: > Hi Thomas, Leo, > > How about this change? > > ? http://hg.openjdk.java.net/jdk/submit/rev/10816e67561a > > It generates indent string via alloca(). > So get_indent() should be inlined. (typical Hotspot style is without the "get_" prefix). > > However it was failed at TestGCLogMessages on macOS only on submit repo > (mach5-one-ysuenaga-JDK-8235819-1-20191215-0359-7545712). > > If you are generally ok to this change, could you share details of this > failure? > I will fix it. The alloca-allocated buffer will be freed at the exit of the get_indent() method, so the new code effectively accesses freed memory as get_indent() returns a pointer to it. The intent of our comments has basically been: - remove the "5" (or "4") in the Indents static. - add a static indent() method that does something like: static const char* indent(uint level) { assert(level < ARRAY_SIZE(Indents), "Too high indent level %u", level); return Indents[level]; } And replace the direct access to the Indents array in the code with a call to the indent() method. If gcc still complains, add that additional indent level you added in webrev.00. I do not like easily avoidable pragmas in the code, and the additional level does not hurt, but others might disagree. Probably also file a bug with gcc. Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 16 10:47:03 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Dec 2019 11:47:03 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <661d07f3-82b2-e5aa-a3f4-d0d2ac0f72ed@oss.nttdata.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> <661d07f3-82b2-e5aa-a3f4-d0d2ac0f72ed@oss.nttdata.com> Message-ID: <1ad482f1-c8e2-21d4-03f9-9fb6ea574545@oracle.com> Hi, On 16.12.19 11:12, Yasumasa Suenaga wrote: > Also we can use macro to resolve this issue: > > ? http://hg.openjdk.java.net/jdk/submit/rev/219fdca61e3a > > I prefer to use dynamic allocation and format string because it is more > secure. > This change makes not so large. It passed tests on submit repo > (mach5-one-ysuenaga-JDK-8235819-3-20191216-0731-7570580). I do not like this change. It introduces unnecessary allocations, and makes the use of indents cumbersome for what I understand is a compiler bug. Please reconsider the suggestions we made in this thread instead. Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 16 11:18:17 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Dec 2019 12:18:17 +0100 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: References: <968935BB-6CE1-47B3-8CBF-DEFA99FBDE76@oracle.com> Message-ID: <0f8a3ed5-b55c-7a6c-0fb9-670bc51bf1cc@oracle.com> Hi, On 14.12.19 01:31, Dean Long wrote: > I don't think it matters.? It looks like .mx.graal was added by mistake, > and I can't find a corresponding sanitycheck.py in upstream Graal > anymore.? I think you can just skip that file and file an RFE to delete > src/jdk.internal.vm.compiler/.mx.graal. > done and done (JDK-8235995). New webrev: http://cr.openjdk.java.net/~tschatzl/8235907/webrev.1 Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 16 11:18:47 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Dec 2019 12:18:47 +0100 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: <38dba6bb-4797-0428-60fe-561f22500934@oracle.com> References: <38dba6bb-4797-0428-60fe-561f22500934@oracle.com> Message-ID: <4d5ae169-da95-8f6b-b515-8d23ba388ddf@oracle.com> Hi Leo, On 16.12.19 10:53, Leo Korinth wrote: > This change looks good to me. thanks for your review. Thomas From leo.korinth at oracle.com Mon Dec 16 11:48:44 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 16 Dec 2019 12:48:44 +0100 Subject: RFR (M): 8235907: Fix tests referencing UseParallelOldGC In-Reply-To: <0f8a3ed5-b55c-7a6c-0fb9-670bc51bf1cc@oracle.com> References: <968935BB-6CE1-47B3-8CBF-DEFA99FBDE76@oracle.com> <0f8a3ed5-b55c-7a6c-0fb9-670bc51bf1cc@oracle.com> Message-ID: On 16/12/2019 12:18, Thomas Schatzl wrote: > Hi, > > On 14.12.19 01:31, Dean Long wrote: >> I don't think it matters.? It looks like .mx.graal was added by >> mistake, and I can't find a corresponding sanitycheck.py in upstream >> Graal anymore.? I think you can just skip that file and file an RFE to >> delete src/jdk.internal.vm.compiler/.mx.graal. >> > > ? done and done (JDK-8235995). > > New webrev: > http://cr.openjdk.java.net/~tschatzl/8235907/webrev.1 Looks good. Thanks, Leo > > Thanks, > ? Thomas From thomas.schatzl at oracle.com Mon Dec 16 12:17:21 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Dec 2019 13:17:21 +0100 Subject: RFR (XS): 8235996: Move obsolete flag G1RSetScanBlockSize in flags list Message-ID: <2d7980eb-3f16-db2f-7e92-3dd81a4f8a3c@oracle.com> Hi all, can I have reviews for this change that removes the now obsolete flag G1RSetScanBlockSize in the code, and move it down the flag lists in arguments.cpp? CR: https://bugs.openjdk.java.net/browse/JDK-8235996 Webrev: http://cr.openjdk.java.net/~tschatzl/8235996/webrev/ Testing: local compilation; there is no use of this flag anywhere in Hotspot code - verified implicitly by our CI not giving any additional failure because of this even before this change. Thanks, Thomas From stefan.johansson at oracle.com Mon Dec 16 12:46:35 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 16 Dec 2019 13:46:35 +0100 Subject: RFR (XS): 8235996: Move obsolete flag G1RSetScanBlockSize in flags list In-Reply-To: <2d7980eb-3f16-db2f-7e92-3dd81a4f8a3c@oracle.com> References: <2d7980eb-3f16-db2f-7e92-3dd81a4f8a3c@oracle.com> Message-ID: Hi Thomas, On 2019-12-16 13:17, Thomas Schatzl wrote: > Hi all, > > ? can I have reviews for this change that removes the now obsolete flag > G1RSetScanBlockSize in the code, and move it down the flag lists in > arguments.cpp? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235996 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235996/webrev/ Looks good, StefanJ > Testing: > local compilation; there is no use of this flag anywhere in Hotspot code > - verified implicitly by our CI not giving any additional failure > because of this even before this change. > > Thanks, > ? Thomas From suenaga at oss.nttdata.com Mon Dec 16 13:46:59 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 16 Dec 2019 22:46:59 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> Message-ID: <6ea36fc2-ac28-a236-674d-99965f804bc3@oss.nttdata.com> Hi Thomas, I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.01/ I guess static analyzer in GCC cannot trace each condition deeply. However, G1 might have a bug to access out of Indents[] in future. It is the motivation of this fix. This webrev introduces indent() to generate indent string. indent() has assert() to check indent level, but it would not affect in release build (we can see same error). So I extends Indents[] in this webrev. `indent` is already used in some place. So I renamed it to avoid confusion. Thanks, Yasumasa On 2019/12/16 19:19, Thomas Schatzl wrote: > Hi, > > On 15.12.19 07:08, Yasumasa Suenaga wrote: >> Hi Thomas, Leo, >> >> How about this change? >> >> ?? http://hg.openjdk.java.net/jdk/submit/rev/10816e67561a >> >> It generates indent string via alloca(). >> So get_indent() should be inlined. > > (typical Hotspot style is without the "get_" prefix). > >> >> However it was failed at TestGCLogMessages on macOS only on submit repo (mach5-one-ysuenaga-JDK-8235819-1-20191215-0359-7545712). >> >> If you are generally ok to this change, could you share details of this failure? >> I will fix it. > > The alloca-allocated buffer will be freed at the exit of the get_indent() method, so the new code effectively accesses freed memory as get_indent() returns a pointer to it. > > The intent of our comments has basically been: > > - remove the "5" (or "4") in the Indents static. > - add a static indent() method that does something like: > > static const char* indent(uint level) { > ? assert(level < ARRAY_SIZE(Indents), "Too high indent level %u", level); > ? return Indents[level]; > } > > And replace the direct access to the Indents array in the code with a call to? the indent() method. > > If gcc still complains, add that additional indent level you added in webrev.00. I do not like easily avoidable pragmas in the code, and the additional level does not hurt, but others might disagree. > > Probably also file a bug with gcc. > > Thanks, > ? Thomas From leo.korinth at oracle.com Mon Dec 16 14:08:53 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 16 Dec 2019 15:08:53 +0100 Subject: RFR (XS): 8235996: Move obsolete flag G1RSetScanBlockSize in flags list In-Reply-To: References: <2d7980eb-3f16-db2f-7e92-3dd81a4f8a3c@oracle.com> Message-ID: Looks good to me too. Thanks, Leo On 16/12/2019 13:46, Stefan Johansson wrote: > Hi Thomas, > > On 2019-12-16 13:17, Thomas Schatzl wrote: >> Hi all, >> >> ?? can I have reviews for this change that removes the now obsolete >> flag G1RSetScanBlockSize in the code, and move it down the flag lists >> in arguments.cpp? >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235996 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235996/webrev/ > Looks good, > StefanJ > >> Testing: >> local compilation; there is no use of this flag anywhere in Hotspot >> code - verified implicitly by our CI not giving any additional failure >> because of this even before this change. >> >> Thanks, >> ?? Thomas From leo.korinth at oracle.com Mon Dec 16 18:59:24 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 16 Dec 2019 19:59:24 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <6ea36fc2-ac28-a236-674d-99965f804bc3@oss.nttdata.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> <6ea36fc2-ac28-a236-674d-99965f804bc3@oss.nttdata.com> Message-ID: <199a1c73-3b95-5c88-fa82-b20c39851d1f@oracle.com> On 16/12/2019 14:46, Yasumasa Suenaga wrote: > Hi Thomas, > > I uploaded new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.01/ > > I guess static analyzer in GCC cannot trace each condition deeply. > However, G1 might have a bug to access out of Indents[] in future. It is > the motivation of this fix > This webrev introduces indent() to generate indent string. > indent() has assert() to check indent level, but it would not affect in > release build (we can see same error). > So I extends Indents[] in this webrev. Just to be sure I understand this correctly: - the code compiled with debug configuration AND without the extra indentation entry. But failed when using release build as the assert could not help the compiler when the assert was preprocessed away? - you did run the tests with assert and /without/ extra indentation entry and it worked? If both are correct I think your webrev is good. > > `indent` is already used in some place. So I renamed it to avoid confusion. I am okay with your rename. Thanks, Leo > > Thanks, > > Yasumasa > > > On 2019/12/16 19:19, Thomas Schatzl wrote: >> Hi, >> >> On 15.12.19 07:08, Yasumasa Suenaga wrote: >>> Hi Thomas, Leo, >>> >>> How about this change? >>> >>> ?? http://hg.openjdk.java.net/jdk/submit/rev/10816e67561a >>> >>> It generates indent string via alloca(). >>> So get_indent() should be inlined. >> >> (typical Hotspot style is without the "get_" prefix). >> >>> >>> However it was failed at TestGCLogMessages on macOS only on submit >>> repo (mach5-one-ysuenaga-JDK-8235819-1-20191215-0359-7545712). >>> >>> If you are generally ok to this change, could you share details of >>> this failure? >>> I will fix it. >> >> The alloca-allocated buffer will be freed at the exit of the >> get_indent() method, so the new code effectively accesses freed memory >> as get_indent() returns a pointer to it. >> >> The intent of our comments has basically been: >> >> - remove the "5" (or "4") in the Indents static. >> - add a static indent() method that does something like: >> >> static const char* indent(uint level) { >> ?? assert(level < ARRAY_SIZE(Indents), "Too high indent level %u", >> level); >> ?? return Indents[level]; >> } >> >> And replace the direct access to the Indents array in the code with a >> call to? the indent() method. >> >> If gcc still complains, add that additional indent level you added in >> webrev.00. I do not like easily avoidable pragmas in the code, and the >> additional level does not hurt, but others might disagree. >> >> Probably also file a bug with gcc. >> >> Thanks, >> ?? Thomas From thomas.schatzl at oracle.com Mon Dec 16 19:12:32 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Dec 2019 20:12:32 +0100 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <199a1c73-3b95-5c88-fa82-b20c39851d1f@oracle.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> <6ea36fc2-ac28-a236-674d-99965f804bc3@oss.nttdata.com> <199a1c73-3b95-5c88-fa82-b20c39851d1f@oracle.com> Message-ID: <3f6eeebf-1014-8602-9bbf-e320241f6561@oracle.com> Hi Yasumasa, On 16.12.19 19:59, Leo Korinth wrote: > On 16/12/2019 14:46, Yasumasa Suenaga wrote: >> Hi Thomas, >> >> I uploaded new webrev: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.01/ >> >> I guess static analyzer in GCC cannot trace each condition deeply. >> However, G1 might have a bug to access out of Indents[] in future. It >> is the motivation of this fix >> This webrev introduces indent() to generate indent string. >> indent() has assert() to check indent level, but it would not affect >> in release build (we can see same error). >> So I extends Indents[] in this webrev. > > Just to be sure I understand this correctly: > > - the code compiled with debug configuration AND without the extra > indentation entry. But failed when using release build as the assert > could not help the compiler when the assert was preprocessed away? > > - you did run the tests with assert and /without/ extra indentation > entry and it worked? > > If both are correct I think your webrev is good. Same here. Please push this change to jdk14, as this issue will otherwise most likely annoy people too much in the future too. It should apply without issues at this time :) The change will automatically propagated to jdk/jdk next time the sync happens (I think Thursdays or so). Thanks, Thomas From suenaga at oss.nttdata.com Tue Dec 17 01:06:52 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 17 Dec 2019 10:06:52 +0900 Subject: RFR (trivial): 8235819: -Wformat-overflow is reported from GCC 9 In-Reply-To: <3f6eeebf-1014-8602-9bbf-e320241f6561@oracle.com> References: <0d1abd39-a732-107e-20c1-cabb85390770@oss.nttdata.com> <603eb912-36e7-347d-17b3-467a04fa36a9@oracle.com> <1f656481-5f4b-d181-3690-2d0511b9f590@oracle.com> <53464c59-69f9-7d21-6605-47a5d9d61b9c@oss.nttdata.com> <288ce710-4014-5cbb-c8eb-e4df8f3de85e@oracle.com> <2659669a-c87a-092b-5034-3a51de207898@oss.nttdata.com> <6ea36fc2-ac28-a236-674d-99965f804bc3@oss.nttdata.com> <199a1c73-3b95-5c88-fa82-b20c39851d1f@oracle.com> <3f6eeebf-1014-8602-9bbf-e320241f6561@oracle.com> Message-ID: <53b8e010-8571-38de-7700-298337ec581b@oss.nttdata.com> Hi Thomas, Leo, Thanks for your review! I've tested this change with both release build and fastdebug, then it works fine. (Of course, it also works fine on submit repo.) So I pushed it to jdk14. Thanks, Yasumasa On 2019/12/17 4:12, Thomas Schatzl wrote: > Hi Yasumasa, > > On 16.12.19 19:59, Leo Korinth wrote: >> On 16/12/2019 14:46, Yasumasa Suenaga wrote: >>> Hi Thomas, >>> >>> I uploaded new webrev: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8235819/webrev.01/ >>> >>> I guess static analyzer in GCC cannot trace each condition deeply. >>> However, G1 might have a bug to access out of Indents[] in future. It is the motivation of this fix >>> This webrev introduces indent() to generate indent string. >>> indent() has assert() to check indent level, but it would not affect in release build (we can see same error). >>> So I extends Indents[] in this webrev. >> >> Just to be sure I understand this correctly: >> >> - the code compiled with debug configuration AND without the extra indentation entry. But failed when using release build as the assert could not help the compiler when the assert was preprocessed away? >> >> - you did run the tests with assert and /without/ extra indentation entry and it worked? >> >> If both are correct I think your webrev is good. > > Same here. Please push this change to jdk14, as this issue will otherwise most likely annoy people too much in the future too. > > It should apply without issues at this time :) > > The change will automatically propagated to jdk/jdk next time the sync happens (I think Thursdays or so). > > Thanks, > ? Thomas From nick.gasson at arm.com Tue Dec 17 06:22:51 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 17 Dec 2019 14:22:51 +0800 Subject: [14] RFR: 8235982: AArch64: gc/stress/jfr/TestStressAllocationGCEventsWithParallel.java assertion failure Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8235982 Webrev: http://cr.openjdk.java.net/~ngasson/8235982/webrev.01/ The above test has been intermittently failing with an assertion error on AArch64 since the changes in "8220465: Use shadow regions for faster ParallelGC full GCs". PSParallelCompact::decrement_destination_counts assumes that shadow_region() is valid if mark_copied() succeeded (i.e. _shadow_state was FilledShadow before). MoveAndUpdateShadowClosure::complete_region sets these with the following code: // Record the shadow region index region_ptr->set_shadow_region(_shadow); // Mark the shadow region as filled to indicate the data is ready to be // copied back region_ptr->mark_filled(); set_shadow_region() does an ordinary store to a volatile variable and mark_filled() uses a CAS to set _shadow_state to FilledShadow with relaxed memory ordering. On a non-TSO architecture like AArch64 these two stores may be reordered when observed from another thread. Fix by making the CAS to set _shadow_state use the default conservative memory order which inserts a full barrier (see the discussion on the JBS entry). Thanks, Nick From thomas.schatzl at oracle.com Tue Dec 17 09:16:24 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 10:16:24 +0100 Subject: RFR (XS): 8235996: Move obsolete flag G1RSetScanBlockSize in flags list In-Reply-To: References: <2d7980eb-3f16-db2f-7e92-3dd81a4f8a3c@oracle.com> Message-ID: <89a6ac81-e78d-ccaf-7553-bb5f30fb165e@oracle.com> Hi Leo, Stefan, On 16.12.19 15:08, Leo Korinth wrote: > Looks good to me too. > > Thanks, > Leo > > On 16/12/2019 13:46, Stefan Johansson wrote: >> Hi Thomas, >> >> On 2019-12-16 13:17, Thomas Schatzl wrote: >>> Hi all, >>> >>> ?? can I have reviews for this change that removes the now obsolete >>> flag G1RSetScanBlockSize in the code, and move it down the flag lists >>> in arguments.cpp? >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8235996 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8235996/webrev/ >> Looks good, >> StefanJ Thanks for your reviews. Thomas From thomas.schatzl at oracle.com Tue Dec 17 09:27:00 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 10:27:00 +0100 Subject: [14] RFR (S): 8235934: gc/g1/TestGCLogMessages.java fails with 'DerivedPointerTable Update' found Message-ID: <41e652e0-b843-e2da-c196-37b9b327d4aa@oracle.com> Hi all, can I have reviews for this testbug where there is a mismatch between "C2 compiler is enabled" and "C2 compiler is compiled in" in verifying output messages. I.e. G1 prints some additional log messages if the C2 compiler is compiled in, but the test checks this message for (non-)existence if the C2 compiler is enabled. Since there are a few flags that can toggle compiler use even when compiled in (UseCompiler, TieredStopAtLevel<=3, ...) the GC prints that message but the test does not expect it. The fix is to add a whitebox method that specifically returns whether the C2 compiler is compiled in or not, to be used by the test. I would like to push this to 14 even if it is P4 because of the test bug exemption, returning unnecessary reproducable errors. CR: https://bugs.openjdk.java.net/browse/JDK-8235934 Webrev: http://cr.openjdk.java.net/~tschatzl/8235934/webrev/ Testing: hs-tier1-3, local runs of TestGCLogMessages.java Thanks, Thomas From stefan.johansson at oracle.com Tue Dec 17 11:04:53 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 17 Dec 2019 12:04:53 +0100 Subject: [14] RFR (S): 8235934: gc/g1/TestGCLogMessages.java fails with 'DerivedPointerTable Update' found In-Reply-To: <41e652e0-b843-e2da-c196-37b9b327d4aa@oracle.com> References: <41e652e0-b843-e2da-c196-37b9b327d4aa@oracle.com> Message-ID: <61703388-b72f-8d5f-1395-87c402f11ceb@oracle.com> Hi Thomas, On 2019-12-17 10:27, Thomas Schatzl wrote: > Hi all, > > ? can I have reviews for this testbug where there is a mismatch between > "C2 compiler is enabled" and "C2 compiler is compiled in" in verifying > output messages. > > I.e. G1 prints some additional log messages if the C2 compiler is > compiled in, but the test checks this message for (non-)existence if the > C2 compiler is enabled. > > Since there are a few flags that can toggle compiler use even when > compiled in (UseCompiler, TieredStopAtLevel<=3, ...) the GC prints that > message but the test does not expect it. > > The fix is to add a whitebox method that specifically returns whether > the C2 compiler is compiled in or not, to be used by the test. > > I would like to push this to 14 even if it is P4 because of the test bug > exemption, returning unnecessary reproducable errors. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235934 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235934/webrev/ Looks good, StefanJ > Testing: > hs-tier1-3, local runs of TestGCLogMessages.java > > Thanks, > ? Thomas From thomas.schatzl at oracle.com Tue Dec 17 11:22:55 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 12:22:55 +0100 Subject: [14] RFR (S): 8235934: gc/g1/TestGCLogMessages.java fails with 'DerivedPointerTable Update' found In-Reply-To: <61703388-b72f-8d5f-1395-87c402f11ceb@oracle.com> References: <41e652e0-b843-e2da-c196-37b9b327d4aa@oracle.com> <61703388-b72f-8d5f-1395-87c402f11ceb@oracle.com> Message-ID: <5d2249e1-0a78-53f4-c8d9-2e3ea3a09c77@oracle.com> Hi Stefan, On 17.12.19 12:04, Stefan Johansson wrote: > Hi Thomas, > > On 2019-12-17 10:27, Thomas Schatzl wrote: >> Hi all, >> >> ?? can I have reviews for this testbug where there is a mismatch >> between "C2 compiler is enabled" and "C2 compiler is compiled in" in >> verifying output messages. >>[...] >> I would like to push this to 14 even if it is P4 because of the test >> bug exemption, returning unnecessary reproducable errors. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235934 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235934/webrev/ > Looks good, > StefanJ > thanks for your review. Thomas From thomas.schatzl at oracle.com Tue Dec 17 13:19:00 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 14:19:00 +0100 Subject: RFR (S/M): 8231670: Remove TaskExecutor abstraction used in preserved marks processing Message-ID: Hi all, can I get reviews for this cleanup of the preserved marks handling that removes the unnecessary TaskExecutor "framework". This code is obsolete since parallel gc also uses WorkGangs (JDK-8204951). CR: https://bugs.openjdk.java.net/browse/JDK-8231670 Webrev: http://cr.openjdk.java.net/~tschatzl/8231670/webrev/ Testing: hs-tier1-5 almost completed without issues Thanks, Thomas From stefan.johansson at oracle.com Tue Dec 17 13:53:22 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 17 Dec 2019 14:53:22 +0100 Subject: [14] RFR: 8235982: AArch64: gc/stress/jfr/TestStressAllocationGCEventsWithParallel.java assertion failure In-Reply-To: References: Message-ID: <2df9f250-deaa-c897-e713-8bebdb32e8cf@oracle.com> Hi Nick, Thanks for fixing this issue. On 2019-12-17 07:22, Nick Gasson wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235982 > Webrev: http://cr.openjdk.java.net/~ngasson/8235982/webrev.01/ > > The above test has been intermittently failing with an assertion error > on AArch64 since the changes in "8220465: Use shadow regions for faster > ParallelGC full GCs". > > PSParallelCompact::decrement_destination_counts assumes that > shadow_region() is valid if mark_copied() succeeded (i.e. _shadow_state > was FilledShadow before). MoveAndUpdateShadowClosure::complete_region > sets these with the following code: > > ? // Record the shadow region index > ? region_ptr->set_shadow_region(_shadow); > ? // Mark the shadow region as filled to indicate the data is ready to be > ? // copied back > ? region_ptr->mark_filled(); > > set_shadow_region() does an ordinary store to a volatile variable and > mark_filled() uses a CAS to set _shadow_state to FilledShadow with > relaxed memory ordering. On a non-TSO architecture like AArch64 these > two stores may be reordered when observed from another thread. > > Fix by making the CAS to set _shadow_state use the default conservative > memory order which inserts a full barrier (see the discussion on the JBS > entry). I agree with the conclusions in the JBS entry and this fix looks good, StefanJ > > > Thanks, > Nick From stefan.johansson at oracle.com Tue Dec 17 14:10:21 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 17 Dec 2019 15:10:21 +0100 Subject: RFR (S/M): 8231670: Remove TaskExecutor abstraction used in preserved marks processing In-Reply-To: References: Message-ID: <6d88001e-11ad-b63e-abc6-ffe408c53cb8@oracle.com> Hi Thomas, Nice cleanup! On 2019-12-17 14:19, Thomas Schatzl wrote: > Hi all, > > ? can I get reviews for this cleanup of the preserved marks handling > that removes the unnecessary TaskExecutor "framework". This code is > obsolete since parallel gc also uses WorkGangs (JDK-8204951). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8231670 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8231670/webrev/ Looks good, StefanJ > Testing: > hs-tier1-5 almost completed without issues > > Thanks, > ? Thomas From thomas.schatzl at oracle.com Tue Dec 17 14:43:10 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 15:43:10 +0100 Subject: RFR (S/M): 8231670: Remove TaskExecutor abstraction used in preserved marks processing In-Reply-To: <6d88001e-11ad-b63e-abc6-ffe408c53cb8@oracle.com> References: <6d88001e-11ad-b63e-abc6-ffe408c53cb8@oracle.com> Message-ID: Hi, On 17.12.19 15:10, Stefan Johansson wrote: > Hi Thomas, > > Nice cleanup! > > On 2019-12-17 14:19, Thomas Schatzl wrote: >> Hi all, >> >> ?? can I get reviews for this cleanup of the preserved marks handling >> that removes the unnecessary TaskExecutor "framework". This code is >> obsolete since parallel gc also uses WorkGangs (JDK-8204951). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8231670 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8231670/webrev/ > Looks good, > StefanJ > thanks for your review. Thomas From thomas.schatzl at oracle.com Tue Dec 17 14:47:38 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 15:47:38 +0100 Subject: [14] RFR: 8235982: AArch64: gc/stress/jfr/TestStressAllocationGCEventsWithParallel.java assertion failure In-Reply-To: <2df9f250-deaa-c897-e713-8bebdb32e8cf@oracle.com> References: <2df9f250-deaa-c897-e713-8bebdb32e8cf@oracle.com> Message-ID: <220356e6-6aa1-32a4-894a-befcbed779fd@oracle.com> Hi, On 17.12.19 14:53, Stefan Johansson wrote: > Hi Nick, > > Thanks for fixing this issue. yes :) > > On 2019-12-17 07:22, Nick Gasson wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235982 >> Webrev: http://cr.openjdk.java.net/~ngasson/8235982/webrev.01/ >> >> The above test has been intermittently failing with an assertion error >> on AArch64 since the changes in "8220465: Use shadow regions for >> faster ParallelGC full GCs". >> >> PSParallelCompact::decrement_destination_counts assumes that >> shadow_region() is valid if mark_copied() succeeded (i.e. >> _shadow_state was FilledShadow before). >> MoveAndUpdateShadowClosure::complete_region sets these with the >> following code: >> >> ?? // Record the shadow region index >> ?? region_ptr->set_shadow_region(_shadow); >> ?? // Mark the shadow region as filled to indicate the data is ready >> to be >> ?? // copied back >> ?? region_ptr->mark_filled(); >> >> set_shadow_region() does an ordinary store to a volatile variable and >> mark_filled() uses a CAS to set _shadow_state to FilledShadow with >> relaxed memory ordering. On a non-TSO architecture like AArch64 these >> two stores may be reordered when observed from another thread. >> >> Fix by making the CAS to set _shadow_state use the default >> conservative memory order which inserts a full barrier (see the >> discussion on the JBS entry). > I agree with the conclusions in the JBS entry and this fix looks good, > StefanJ > Looks good. If you need a sponsor to push the change I could do that. Thomas From thomas.schatzl at oracle.com Tue Dec 17 15:51:18 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Dec 2019 16:51:18 +0100 Subject: RFR (M): 8235860: Obsolete the UseParallelOldGC option Message-ID: <292ab94f-f2c8-b373-d5a5-46a45470540e@oracle.com> Hi all, can I get reviews for this change that implements obsoletion of the UseParallelOldGC option, i.e. removal of the Parallel GC Serial Old collector? ((I am counting this as "M" because it's 99% removal of code) CR: https://bugs.openjdk.java.net/browse/JDK-8235860 Webrev: http://cr.openjdk.java.net/~tschatzl/8235860/webrev/ Testing: hs-tier1-5 almost done Thanks, Thomas From vladimir.kozlov at oracle.com Wed Dec 18 03:18:35 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Dec 2019 19:18:35 -0800 Subject: [14] RFR (S) 8236000: VM build without C2 fails Message-ID: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> https://cr.openjdk.java.net/~kvn/8236000/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8236000 C2 flags should be checked only when C2 is present. Running debug VM build with JVMCI but without C2 found other issues which were fixed too: # Internal Error (src/hotspot/share/jvmci/jvmci_globals.cpp:121), pid=2398, tid=2403 # assert(MaxVectorSizechecked) failed: MaxVectorSize flag not checked and # Internal Error (src/hotspot/share/gc/serial/genMarkSweep.cpp:98), pid=10108, tid=10118 # assert(DerivedPointerTable::is_active()) failed: Sanity Tested build with --with-jvm-features=-compiler2 and --with-jvm-features=-compiler2,-jvmci and tier1. Thanks, Vladimir From kim.barrett at oracle.com Wed Dec 18 04:09:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Dec 2019 23:09:16 -0500 Subject: [14] RFR (S) 8236000: VM build without C2 fails In-Reply-To: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> References: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> Message-ID: > On Dec 17, 2019, at 10:18 PM, Vladimir Kozlov wrote: > > https://cr.openjdk.java.net/~kvn/8236000/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8236000 > > C2 flags should be checked only when C2 is present. Running debug VM build with JVMCI but without C2 found other issues which were fixed too: > > # Internal Error (src/hotspot/share/jvmci/jvmci_globals.cpp:121), pid=2398, tid=2403 > # assert(MaxVectorSizechecked) failed: MaxVectorSize flag not checked > > and > > # Internal Error (src/hotspot/share/gc/serial/genMarkSweep.cpp:98), pid=10108, tid=10118 > # assert(DerivedPointerTable::is_active()) failed: Sanity > > Tested build with --with-jvm-features=-compiler2 and --with-jvm-features=-compiler2,-jvmci > and tier1. > > Thanks, > Vladimir Looks good. From vladimir.kozlov at oracle.com Wed Dec 18 04:34:34 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Dec 2019 20:34:34 -0800 Subject: [14] RFR (S) 8236000: VM build without C2 fails In-Reply-To: References: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> Message-ID: <3819390f-c0fe-5752-b52e-9f957ab04830@oracle.com> Thank you, Kim Vladimir On 12/17/19 8:09 PM, Kim Barrett wrote: >> On Dec 17, 2019, at 10:18 PM, Vladimir Kozlov wrote: >> >> https://cr.openjdk.java.net/~kvn/8236000/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8236000 >> >> C2 flags should be checked only when C2 is present. Running debug VM build with JVMCI but without C2 found other issues which were fixed too: >> >> # Internal Error (src/hotspot/share/jvmci/jvmci_globals.cpp:121), pid=2398, tid=2403 >> # assert(MaxVectorSizechecked) failed: MaxVectorSize flag not checked >> >> and >> >> # Internal Error (src/hotspot/share/gc/serial/genMarkSweep.cpp:98), pid=10108, tid=10118 >> # assert(DerivedPointerTable::is_active()) failed: Sanity >> >> Tested build with --with-jvm-features=-compiler2 and --with-jvm-features=-compiler2,-jvmci >> and tier1. >> >> Thanks, >> Vladimir > > Looks good. > From kim.barrett at oracle.com Wed Dec 18 05:44:20 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Dec 2019 00:44:20 -0500 Subject: RFR (M): 8235860: Obsolete the UseParallelOldGC option In-Reply-To: <292ab94f-f2c8-b373-d5a5-46a45470540e@oracle.com> References: <292ab94f-f2c8-b373-d5a5-46a45470540e@oracle.com> Message-ID: <2A4B1955-26D5-4544-B476-6E9E5E8009D4@oracle.com> > On Dec 17, 2019, at 10:51 AM, Thomas Schatzl wrote: > > Hi all, > > can I get reviews for this change that implements obsoletion of the UseParallelOldGC option, i.e. removal of the Parallel GC Serial Old collector? > > ((I am counting this as "M" because it's 99% removal of code) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235860 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235860/webrev/ > Testing: > hs-tier1-5 almost done > > Thanks, > Thomas Looks good. One very minor issue and some pre-existing issues with the block comment before SplitInfo. That block comment should be dealt with separately from this change. ------------------------------------------------------------------------------ src/hotspot/share/gc/parallel/parallelArguments.cpp 47 assert(UseParallelGC, "Error"); 48 FLAG_SET_DEFAULT(UseParallelGC, true); I think line 48 was to account for the possibility that we got here via +UseParallelOldGC. It's redundant now. ------------------------------------------------------------------------------ src/hotspot/share/gc/parallel/psParallelCompact.hpp 886 // ... The permanent generation is Pre-existing lingering comments about permgen. ------------------------------------------------------------------------------ src/hotspot/share/gc/parallel/psParallelCompact.hpp Pre-existing: It seems like the big block comment before SplitInfo should have received some updates as part of the recent shadow-region patch, but it wasn't touched. ------------------------------------------------------------------------------ From tobias.hartmann at oracle.com Wed Dec 18 06:59:29 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 18 Dec 2019 07:59:29 +0100 Subject: [14] RFR (S) 8236000: VM build without C2 fails In-Reply-To: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> References: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> Message-ID: Hi Vladimir, looks good to me. Best regards, Tobias On 18.12.19 04:18, Vladimir Kozlov wrote: > https://cr.openjdk.java.net/~kvn/8236000/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8236000 > > C2 flags should be checked only when C2 is present. Running debug VM build with JVMCI but without C2 > found other issues which were fixed too: > > #? Internal Error (src/hotspot/share/jvmci/jvmci_globals.cpp:121), pid=2398, tid=2403 > #? assert(MaxVectorSizechecked) failed: MaxVectorSize flag not checked > > and > > # Internal Error (src/hotspot/share/gc/serial/genMarkSweep.cpp:98), pid=10108, tid=10118 > # assert(DerivedPointerTable::is_active()) failed: Sanity > > Tested build with --with-jvm-features=-compiler2 and --with-jvm-features=-compiler2,-jvmci > and tier1. > > Thanks, > Vladimir From kim.barrett at oracle.com Wed Dec 18 07:14:19 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Dec 2019 02:14:19 -0500 Subject: RFR (S/M): 8231670: Remove TaskExecutor abstraction used in preserved marks processing In-Reply-To: References: Message-ID: <6ABEB7F9-B3C7-4D79-A891-B7B015FD9F21@oracle.com> > On Dec 17, 2019, at 8:19 AM, Thomas Schatzl wrote: > > Hi all, > > can I get reviews for this cleanup of the preserved marks handling that removes the unnecessary TaskExecutor "framework". This code is obsolete since parallel gc also uses WorkGangs (JDK-8204951). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8231670 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8231670/webrev/ > Testing: > hs-tier1-5 almost completed without issues > > Thanks, > Thomas Looks good. From nick.gasson at arm.com Wed Dec 18 08:07:44 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 18 Dec 2019 16:07:44 +0800 Subject: [14] RFR: 8235982: AArch64: gc/stress/jfr/TestStressAllocationGCEventsWithParallel.java assertion failure In-Reply-To: <220356e6-6aa1-32a4-894a-befcbed779fd@oracle.com> References: <2df9f250-deaa-c897-e713-8bebdb32e8cf@oracle.com> <220356e6-6aa1-32a4-894a-befcbed779fd@oracle.com> Message-ID: Hi Thomas, On 17/12/2019 22:47, Thomas Schatzl wrote: > > Looks good. If you need a sponsor to push the change I could do that. > One of my colleagues at Arm is a committer but he's out at the moment, would you mind pushing it for me? Thanks, Nick From thomas.schatzl at oracle.com Wed Dec 18 09:44:55 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Dec 2019 10:44:55 +0100 Subject: RFR (S/M): 8231670: Remove TaskExecutor abstraction used in preserved marks processing In-Reply-To: <6ABEB7F9-B3C7-4D79-A891-B7B015FD9F21@oracle.com> References: <6ABEB7F9-B3C7-4D79-A891-B7B015FD9F21@oracle.com> Message-ID: Hi Kim, On 18.12.19 08:14, Kim Barrett wrote: >> On Dec 17, 2019, at 8:19 AM, Thomas Schatzl wrote: >> >> Hi all, >> >> can I get reviews for this cleanup of the preserved marks handling that removes the unnecessary TaskExecutor "framework". This code is obsolete since parallel gc also uses WorkGangs (JDK-8204951). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8231670 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8231670/webrev/ >> Testing: >> hs-tier1-5 almost completed without issues >> >> Thanks, >> Thomas > > Looks good. > thanks for your review. Thomas From thomas.schatzl at oracle.com Wed Dec 18 09:52:30 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Dec 2019 10:52:30 +0100 Subject: RFR (M): 8235860: Obsolete the UseParallelOldGC option In-Reply-To: <2A4B1955-26D5-4544-B476-6E9E5E8009D4@oracle.com> References: <292ab94f-f2c8-b373-d5a5-46a45470540e@oracle.com> <2A4B1955-26D5-4544-B476-6E9E5E8009D4@oracle.com> Message-ID: <5e21e50d-a026-98ba-d03d-3f7aa1c31e21@oracle.com> Hi, On 18.12.19 06:44, Kim Barrett wrote: >> On Dec 17, 2019, at 10:51 AM, Thomas Schatzl wrote: >> >> Hi all, >> >> can I get reviews for this change that implements obsoletion of the UseParallelOldGC option, i.e. removal of the Parallel GC Serial Old collector? >> >> ((I am counting this as "M" because it's 99% removal of code) >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8235860 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8235860/webrev/ >> Testing: >> hs-tier1-5 almost done >> >> Thanks, >> Thomas > > Looks good. One very minor issue and some pre-existing issues with > the block comment before SplitInfo. That block comment should be > dealt with separately from this change. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/parallel/parallelArguments.cpp > 47 assert(UseParallelGC, "Error"); > 48 FLAG_SET_DEFAULT(UseParallelGC, true); > > I think line 48 was to account for the possibility that we got here > via +UseParallelOldGC. It's redundant now. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/parallel/psParallelCompact.hpp > 886 // ... The permanent generation is > > Pre-existing lingering comments about permgen. Fixed in http://cr.openjdk.java.net/~tschatzl/8235860/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8235860/webrev.1 (full) > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/parallel/psParallelCompact.hpp > > Pre-existing: It seems like the big block comment before SplitInfo > should have received some updates as part of the recent shadow-region > patch, but it wasn't touched. > > ------------------------------------------------------------------------------ > I am filing a CR for that. Thanks, Thomas From thomas.schatzl at oracle.com Wed Dec 18 10:22:56 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Dec 2019 11:22:56 +0100 Subject: [14] RFR: 8235982: AArch64: gc/stress/jfr/TestStressAllocationGCEventsWithParallel.java assertion failure In-Reply-To: References: <2df9f250-deaa-c897-e713-8bebdb32e8cf@oracle.com> <220356e6-6aa1-32a4-894a-befcbed779fd@oracle.com> Message-ID: <5449bb69-22bd-7bc7-e903-e0e3e330c510@oracle.com> Hi Nick, On 18.12.19 09:07, Nick Gasson wrote: > Hi Thomas, > > On 17/12/2019 22:47, Thomas Schatzl wrote: >> >> Looks good. If you need a sponsor to push the change I could do that. >> > > One of my colleagues at Arm is a committer but he's out at the moment, > would you mind pushing it for me? > done. Thanks for your fix! The change will automatically show up in jdk/jdk in a few days as it will be synchronized with jdk/jdk14. Thomas From kim.barrett at oracle.com Wed Dec 18 15:45:37 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Dec 2019 10:45:37 -0500 Subject: RFR (M): 8235860: Obsolete the UseParallelOldGC option In-Reply-To: <5e21e50d-a026-98ba-d03d-3f7aa1c31e21@oracle.com> References: <292ab94f-f2c8-b373-d5a5-46a45470540e@oracle.com> <2A4B1955-26D5-4544-B476-6E9E5E8009D4@oracle.com> <5e21e50d-a026-98ba-d03d-3f7aa1c31e21@oracle.com> Message-ID: <56A9296B-089E-4A00-9C43-5E3CBDF4A29B@oracle.com> > On Dec 18, 2019, at 4:52 AM, Thomas Schatzl wrote: > > Fixed in > http://cr.openjdk.java.net/~tschatzl/8235860/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8235860/webrev.1 (full) Looks good. > >> ------------------------------------------------------------------------------ >> src/hotspot/share/gc/parallel/psParallelCompact.hpp >> Pre-existing: It seems like the big block comment before SplitInfo >> should have received some updates as part of the recent shadow-region >> patch, but it wasn't touched. >> ------------------------------------------------------------------------------ > > I am filing a CR for that. The comment before PSParallelCompact in the same file might also need some updating. (I was a bit confused in my earlier review about where the relevant comments were.) From vladimir.kozlov at oracle.com Wed Dec 18 17:40:50 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Dec 2019 09:40:50 -0800 Subject: [14] RFR (S) 8236000: VM build without C2 fails In-Reply-To: References: <41aa561d-56a7-a7f9-2460-f2d20b6721a1@oracle.com> Message-ID: Thank you, Tobias Vladimir On 12/17/19 10:59 PM, Tobias Hartmann wrote: > Hi Vladimir, > > looks good to me. > > Best regards, > Tobias > > On 18.12.19 04:18, Vladimir Kozlov wrote: >> https://cr.openjdk.java.net/~kvn/8236000/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8236000 >> >> C2 flags should be checked only when C2 is present. Running debug VM build with JVMCI but without C2 >> found other issues which were fixed too: >> >> #? Internal Error (src/hotspot/share/jvmci/jvmci_globals.cpp:121), pid=2398, tid=2403 >> #? assert(MaxVectorSizechecked) failed: MaxVectorSize flag not checked >> >> and >> >> # Internal Error (src/hotspot/share/gc/serial/genMarkSweep.cpp:98), pid=10108, tid=10118 >> # assert(DerivedPointerTable::is_active()) failed: Sanity >> >> Tested build with --with-jvm-features=-compiler2 and --with-jvm-features=-compiler2,-jvmci >> and tier1. >> >> Thanks, >> Vladimir From stefan.karlsson at oracle.com Wed Dec 18 17:52:30 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Dec 2019 18:52:30 +0100 Subject: RFR: 8236110: Windows (MSVC 2013) build failures after JDK-8233299 Message-ID: <5f79ceea-1e8d-69ad-5ad9-d51d70237688@oracle.com> Hi all, Please review this patch to add a configure check to see if the SDK supports the APIs needed to build ZGC on Windows. https://cr.openjdk.java.net/~stefank/8236110 https://bugs.openjdk.java.net/browse/JDK-8236110 Verified that this configures and builds ZGC with the SDK used by Oracle: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms and that it excludes ZGC for older SDKs by testing with VS2017 15.5. This patch is intended for both JDK 14 and JDK 15. Thanks, StefanK From stefan.karlsson at oracle.com Wed Dec 18 17:58:01 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Dec 2019 18:58:01 +0100 Subject: RFR: 8236110: Windows (MSVC 2013) build failures after JDK-8233299 In-Reply-To: <5f79ceea-1e8d-69ad-5ad9-d51d70237688@oracle.com> References: <5f79ceea-1e8d-69ad-5ad9-d51d70237688@oracle.com> Message-ID: Adding build-dev. StefanK On 2019-12-18 18:52, Stefan Karlsson wrote: > Hi all, > > Please review this patch to add a configure check to see if the SDK > supports the APIs needed to build ZGC on Windows. > > https://cr.openjdk.java.net/~stefank/8236110 > https://bugs.openjdk.java.net/browse/JDK-8236110 > > Verified that this configures and builds ZGC with the SDK used by Oracle: > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > and that it excludes ZGC for older SDKs by testing with VS2017 15.5. > > This patch is intended for both JDK 14 and JDK 15. > > Thanks, > StefanK From erik.joelsson at oracle.com Thu Dec 19 08:22:25 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Dec 2019 09:22:25 +0100 Subject: RFR: 8236110: Windows (MSVC 2013) build failures after JDK-8233299 In-Reply-To: References: <5f79ceea-1e8d-69ad-5ad9-d51d70237688@oracle.com> Message-ID: <79cf2656-31e4-0f78-27f6-7b329bbd9ea0@oracle.com> Looks good! /Erik On 2019-12-18 18:58, Stefan Karlsson wrote: > Adding build-dev. > > StefanK > > On 2019-12-18 18:52, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to add a configure check to see if the SDK >> supports the APIs needed to build ZGC on Windows. >> >> https://cr.openjdk.java.net/~stefank/8236110 >> https://bugs.openjdk.java.net/browse/JDK-8236110 >> >> Verified that this configures and builds ZGC with the SDK used by >> Oracle: >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> >> and that it excludes ZGC for older SDKs by testing with VS2017 15.5. >> >> This patch is intended for both JDK 14 and JDK 15. >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Thu Dec 19 09:51:30 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Dec 2019 10:51:30 +0100 Subject: RFR: 8236110: Windows (MSVC 2013) build failures after JDK-8233299 In-Reply-To: <79cf2656-31e4-0f78-27f6-7b329bbd9ea0@oracle.com> References: <5f79ceea-1e8d-69ad-5ad9-d51d70237688@oracle.com> <79cf2656-31e4-0f78-27f6-7b329bbd9ea0@oracle.com> Message-ID: <6dddcc16-d5ad-2357-3ea8-7f0c226ec5cc@oracle.com> Thanks, Erik! StefanK On 2019-12-19 09:22, Erik Joelsson wrote: > Looks good! > > /Erik > > On 2019-12-18 18:58, Stefan Karlsson wrote: >> Adding build-dev. >> >> StefanK >> >> On 2019-12-18 18:52, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to add a configure check to see if the SDK >>> supports the APIs needed to build ZGC on Windows. >>> >>> https://cr.openjdk.java.net/~stefank/8236110 >>> https://bugs.openjdk.java.net/browse/JDK-8236110 >>> >>> Verified that this configures and builds ZGC with the SDK used by >>> Oracle: >>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >>> >>> and that it excludes ZGC for older SDKs by testing with VS2017 15.5. >>> >>> This patch is intended for both JDK 14 and JDK 15. >>> >>> Thanks, >>> StefanK >> From stefan.johansson at oracle.com Thu Dec 19 13:27:28 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 19 Dec 2019 14:27:28 +0100 Subject: RFR: 8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions Message-ID: Hi, Please review this fix for JDK-8235119, it's intended for both JDK 14 and 15. Webrev: http://cr.openjdk.java.net/~sjohanss/8235119/00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8235119 Summary When we parallelized the evacuation preparation in JDK-8141637 we made a small change to how we initialize the scan state. The problem with this change was that free and unavailable regions didn't get cleared and reset as before. This will lead to regions being allocated during the GC can have an inconsistent state. This fix reverts a small part of JDK-8141637, so that we continue to clear and reset all regions regardless of state and then just update the state for the regions needing it. Testing Functional testing in mach5 tier1-3 and Kim has done manual verification with tests that previously reproduced the failure. Also big thanks to Kim, Sangheon and Thomas for all the work with reproducing and digging into the issue. Cheers, Stefan From thomas.schatzl at oracle.com Thu Dec 19 14:50:35 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 19 Dec 2019 15:50:35 +0100 Subject: RFR: 8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions In-Reply-To: References: Message-ID: Hi, On Thu, 2019-12-19 at 14:27 +0100, Stefan Johansson wrote: > Hi, > > Please review this fix for JDK-8235119, it's intended for both JDK > 14 and 15. > > Webrev: http://cr.openjdk.java.net/~sjohanss/8235119/00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8235119 > looks good. Thomas From kim.barrett at oracle.com Thu Dec 19 16:47:47 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 19 Dec 2019 11:47:47 -0500 Subject: RFR: 8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions In-Reply-To: References: Message-ID: > On Dec 19, 2019, at 8:27 AM, Stefan Johansson wrote: > > Hi, > > Please review this fix for JDK-8235119, it's intended for both JDK 14 and 15. > > Webrev: http://cr.openjdk.java.net/~sjohanss/8235119/00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8235119 > > Summary > When we parallelized the evacuation preparation in JDK-8141637 we made a small change to how we initialize the scan state. The problem with this change was that free and unavailable regions didn't get cleared and reset as before. This will lead to regions being allocated during the GC can have an inconsistent state. > > This fix reverts a small part of JDK-8141637, so that we continue to clear and reset all regions regardless of state and then just update the state for the regions needing it. > > Testing > Functional testing in mach5 tier1-3 and Kim has done manual verification with tests that previously reproduced the failure. > > Also big thanks to Kim, Sangheon and Thomas for all the work with reproducing and digging into the issue. > > Cheers, > Stefan Looks good. I dislike the casts, but understand why they are there. It seems there are inconsistencies regarding the range for number of regions, with some code using size_t and other code using uint. It would be good to clean that up, but that should be a separate RFE from this bug fix. From stefan.johansson at oracle.com Thu Dec 19 17:06:47 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 19 Dec 2019 18:06:47 +0100 Subject: RFR: 8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions In-Reply-To: References: Message-ID: Hi Kim, On 2019-12-19 17:47, Kim Barrett wrote: >> On Dec 19, 2019, at 8:27 AM, Stefan Johansson wrote: >> >> Hi, >> >> Please review this fix for JDK-8235119, it's intended for both JDK 14 and 15. >> >> Webrev: http://cr.openjdk.java.net/~sjohanss/8235119/00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8235119 >> >> Summary >> When we parallelized the evacuation preparation in JDK-8141637 we made a small change to how we initialize the scan state. The problem with this change was that free and unavailable regions didn't get cleared and reset as before. This will lead to regions being allocated during the GC can have an inconsistent state. >> >> This fix reverts a small part of JDK-8141637, so that we continue to clear and reset all regions regardless of state and then just update the state for the regions needing it. >> >> Testing >> Functional testing in mach5 tier1-3 and Kim has done manual verification with tests that previously reproduced the failure. >> >> Also big thanks to Kim, Sangheon and Thomas for all the work with reproducing and digging into the issue. >> >> Cheers, >> Stefan > > Looks good. Thanks for the review. I will push this to jdk-14 tomorrow afternoon. > > I dislike the casts, but understand why they are there. It seems there are inconsistencies > regarding the range for number of regions, with some code using size_t and other code > using uint. It would be good to clean that up, but that should be a separate RFE from this > bug fix. I totally agree, I actually looked at how much needed to change to get better consistency here but I came to the same conclusion, that it was out of scope for this change. I don't have time to create the RFE right now, so feel free to create one if you like. Cheers, Stefan From stefan.johansson at oracle.com Thu Dec 19 17:09:11 2019 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 19 Dec 2019 18:09:11 +0100 Subject: RFR: 8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions In-Reply-To: References: Message-ID: Hi Thomas, On 2019-12-19 15:50, Thomas Schatzl wrote: > Hi, > > On Thu, 2019-12-19 at 14:27 +0100, Stefan Johansson wrote: >> Hi, >> >> Please review this fix for JDK-8235119, it's intended for both JDK >> 14 and 15. >> >> Webrev: http://cr.openjdk.java.net/~sjohanss/8235119/00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8235119 >> > > looks good. Thanks for the review, Stefan > > Thomas > > From sangheon.kim at oracle.com Thu Dec 19 18:55:01 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Thu, 19 Dec 2019 10:55:01 -0800 Subject: RFR: 8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions In-Reply-To: References: Message-ID: <8560fd6f-c402-2612-32ba-30030404c7dd@oracle.com> Hi Stefan, On 12/19/19 5:27 AM, Stefan Johansson wrote: > Hi, > > Please review this fix for JDK-8235119, it's intended for both JDK 14 > and 15. > > Webrev: http://cr.openjdk.java.net/~sjohanss/8235119/00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8235119 > > Summary > When we parallelized the evacuation preparation in JDK-8141637 we made > a small change to how we initialize the scan state. The problem with > this change was that free and unavailable regions didn't get cleared > and reset as before. This will lead to regions being allocated during > the GC can have an inconsistent state. > > This fix reverts a small part of JDK-8141637, so that we continue to > clear and reset all regions regardless of state and then just update > the state for the regions needing it. > > Testing > Functional testing in mach5 tier1-3 and Kim has done manual > verification with tests that previously reproduced the failure. > > Also big thanks to Kim, Sangheon and Thomas for all the work with > reproducing and digging into the issue. Looks good to me too. I chased with logs added and the result shows that your thought above is correct. i.e. at the time of crash the problematic region is gc allocating region and its scan_top is top which previously was 0 (if it was properly reset). I reassigned the bug to you as you have the patch. Thanks, Sangheon > > Cheers, > Stefan From manc at google.com Sun Dec 22 16:50:14 2019 From: manc at google.com (Man Cao) Date: Sun, 22 Dec 2019 08:50:14 -0800 Subject: Work-in-progress: 8236485: Epoch synchronization protocol for G1 concurrent refinement Message-ID: Hi all, I have written up a description and challenges for implementing an epoch synchronization protocol. This protocol is necessary for removing the StoreLoad fence in G1's post-write barrier (JDK-8226731) Description: https://bugs.openjdk.java.net/browse/JDK-8236485 Work-in-progress webrev: https://cr.openjdk.java.net/~manc/8236485/webrev_wip0/ There are two main challenges that I'm not sure how to resolve: - Triggering a thread-local handshake is a blocking operation that can pass a safepoint. - There are native post-write barriers executed by threads in native/VM state. Discussions and suggestions are highly appreciated! -Man From kim.barrett at oracle.com Tue Dec 31 03:01:14 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Dec 2019 22:01:14 -0500 Subject: RFR[14]: 8235751: Assertion when triggering concurrent cycle during shutdown Message-ID: <695EF54D-675F-4162-8518-115CC9F63F8D@oracle.com> Please review this change to G1's handling of requests to initiate concurrent marking. When such a request is made during shutdown processing, after the cm thread has been stopped, the request to initiate concurrent marking is ignored. This could lead to an assertion failure for user requested GCs (System.gc and via agent) by a thread that has not yet been brought to a halt, because the possibility of such a request being ignored was missed when the assertion was recently added by JDK-8232588. We now report to the GC-invoking thread when initiation of concurrent marking has been suppressed because termination of the cm thread has been requested. In that case the GC invocation is considered finished. CR: https://bugs.openjdk.java.net/browse/JDK-8235751 Webrev: https://cr.openjdk.java.net/~kbarrett/8235751/open.00/ Testing: mach5 tier1-5 Locally (linux-x64) reproduced fairly quickly the failure using the approach described in the CR; after applying the proposed chage, failed to reproduce. From kim.barrett at oracle.com Tue Dec 31 07:09:46 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 31 Dec 2019 02:09:46 -0500 Subject: [14] RFR (S): 8235934: gc/g1/TestGCLogMessages.java fails with 'DerivedPointerTable Update' found In-Reply-To: <41e652e0-b843-e2da-c196-37b9b327d4aa@oracle.com> References: <41e652e0-b843-e2da-c196-37b9b327d4aa@oracle.com> Message-ID: > On Dec 17, 2019, at 4:27 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this testbug where there is a mismatch between "C2 compiler is enabled" and "C2 compiler is compiled in" in verifying output messages. > > I.e. G1 prints some additional log messages if the C2 compiler is compiled in, but the test checks this message for (non-)existence if the C2 compiler is enabled. > > Since there are a few flags that can toggle compiler use even when compiled in (UseCompiler, TieredStopAtLevel<=3, ...) the GC prints that message but the test does not expect it. > > The fix is to add a whitebox method that specifically returns whether the C2 compiler is compiled in or not, to be used by the test. > > I would like to push this to 14 even if it is P4 because of the test bug exemption, returning unnecessary reproducable errors. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8235934 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8235934/webrev/ > Testing: > hs-tier1-3, local runs of TestGCLogMessages.java > > Thanks, > Thomas ------------------------------------------------------------------------------ src/hotspot/share/prims/whitebox.cpp 1990 #if COMPILER2_OR_JVMCI 1991 return true; 1992 #else 1993 return false; 1994 #endif This could perhaps be just return bool(COMPILER_OR_JVMCI); That will fail to compile if COMPILER_OR_JVMCI is not defined at all; not sure whether that's a pro or con for this alternative form. ------------------------------------------------------------------------------ src/hotspot/share/prims/whitebox.cpp 1989 WB_ENTRY(jboolean, WB_isC2OrGraalIncludedInVmBuild(JNIEnv* env)) I think the name ought to use "Jvmci" rather than "Graal". ------------------------------------------------------------------------------