[10] RFR (M/L): 8137099: G1 needs to "upgrade" GC within the safepoint if it can't allocate during that safepoint to avoid OoME
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Jan 10 16:47:20 UTC 2018
Hi Erik,
On Wed, 2018-01-10 at 16:50 +0100, Erik Helin wrote:
> Hi Thomas,
>
> thanks for taking on this work and cleaning this up!
thanks for your review.
>
> On 01/09/2018 10:52 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> > Erik Duveblad had some offline comments:
> >
> > New webrevs:
> > http://cr.openjdk.java.net/~tschatzl/8137099/webrev.2_to_3/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/8137099/webrev.3/ (full)
>
> this looks good to me now, pending one small comment: please rename
> G1CollectedHeap::no_more_regions_left_for_allocation to
> G1CollectedHeap::has_regions_left_for_allocation (and of course
> change the method). This way you can use the ! operator in the if
> condition, which reads a bit easier.
>
New webrev:
http://cr.openjdk.java.net/~tschatzl/8137099/webrev.3_to_4/ (diff)
http://cr.openjdk.java.net/~tschatzl/8137099/webrev.4/ (full)
> And thanks for putting this into 11, it is the right decision IMO.
>
No problem.
Thanks,
Thomas
> Thanks,
> Erik
>
> > - inverting some conditions in the clauses to read better
> >
> > - extract out the condition to do the maximally compacting full gc
> > added in this change into a separate method.
> >
> > Erik Duveblad also noted that this change contains some slight
> > behavioral change in when a collection is started. I.e. previously
> > TLAB
> > allocation by itself could not cause a GC. Since this change is
> > already
> > quite big, he suggested to fix this in a follow-up, and push them
> > together.
> >
> > Thanks,
> > Thomas
> >
More information about the hotspot-gc-dev
mailing list