RFR: Parallel heap region iteration

Aleksey Shipilev shade at redhat.com
Thu Oct 25 15:41:07 UTC 2018


On 10/25/2018 05:34 PM, Roman Kennke wrote:
> I'd have two suggestions/question:
> - should we lift/raise the 32MB limit? This is totally random and
> basically 'derived' from the similar code in G1, and doesn't seem to
> make much sense in Shenandoah context.

I considered it. Larger regions mean less immediate garbage, and (theoretically) large waste. Even
with 100 GB heap, it sometimes makes sense to tune the region sizes _down_ to expose more immediate
garbage opportunities. So, while larger region sizes are interesting to consider, we have to be
prepared to accept several hundred thousands smaller regions too.

> - What would stop us from moving the 'build cset' stuff at the beginning
> of the conc-evac phase? Are there any gotchas?

Evacuation races, I would think. You have to make all threads understand what is the collection set,
atomically, otherwise to-space invariant can be broken when one thread does the write into cset (not
knowing it is cset), and another evacs and updates "old" copy (knowing the region is cset). So, to
do concurrent cset selection, you either have to do _two_ pauses (final mark pause, conc cset
selection, start evac pause), or do some handshaking dance.

-Aleksey




More information about the shenandoah-dev mailing list