RFR (M/L): 8057003: Large reference arrays cause extremely long synchronization times
erik.helin at oracle.com
Wed Nov 23 12:47:39 UTC 2016
On 11/23/2016 01:13 PM, Thomas Schatzl wrote:
> Hi all,
> On Fri, 2016-10-28 at 15:09 +0200, Thomas Schatzl wrote:
>> Hi all,
>> I would like to have reviews for the following change that fixes
>> long synchronization times for G1 when marking large objArrays. We
>> split large objArrays into a header and a continuation, so that
>> complete processing of the entire array is not required before a GC
>> pause can be started.
>> Also fixes most cases of mark stack overflows ("concurrent-mark-
>> reset-for-overflow") ultimately causing full gcs by not pushing the
>> entire objArray on the mark stack at once.
>> There is the enhancement, JDK-8168467, suggested in an internal
>> review, to change the type of the mark stack elements to "not an
>> oop", as this is not the case anymore - there may be continuations on
>> it. I decided to split this out because that change impacts a lot
>> more places (the entire mark stack handling) unrelated to this
>> mechanism in the code.
>> jprt, various benchmarks, vm.gc, gc-nightly
>> This change alredy has its FC extension approved.
> Erik Helin kindly reviewed the change, with the following issues
> fixed at
> http://cr.openjdk.java.net/~tschatzl/8057003/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8057003/webrev.1 (full)
This looks good to me, Reviewed.
> - remove the new G1CMTask::process_object(), putting the relevant code
> into G1CMTask::scan_object().
> - improved the asserts in G1CMTask::scan_object() to remove some
> duplicate asserts elsewhere.
> - removed a few "const"
> - remove word_size parameter in G1CMObjArrayProcessor::process_obj.
> That value can be calculated within the method, there is no advantage
> passing it.
> - some renamings.
> Testing: Passed jprt, common and gc tests tier2-5, local testing
More information about the hotspot-gc-dev