RFR: Reduce waste in humongous allocations

[Aleksey Shipilev]

On 12/13/2016 06:11 PM, Roman Kennke wrote:
> as Aleksey has shown, when repeatedly allocating humongous objects, we
> tend to leave gaps between them. The reason is that we start looking
> for contigous regions starting one region after the current
> (allocation) region, and then discard that alloc region, starting a new
> one after the humongous object.
> 
> The fix is two-fold:
> - Instead of discarding currently active allocation regions, we re-
> append them to the free-list (together with any free regions that we
> skipped while searching a contiguous block). This should be useful,
> e.g. when we have a not-totally-filled alloc region and then allocate a
> humongous object.
> - When searching for contigous space, also consider the current alloc
> region. The complication here is that we must prevent concurrent
> allocations from it. This patch does it by pre-emptively allocating
> region-sized chunk, which has two effects: it blocks concurrent
> allocations and it tells us if the region is free in a concurrency-safe 
> manner. If our search for contiguous block fails, we revert that by
> freeing such regions again.
> 
> It passes jtreg tests and SPECjvm.
> 
> http://cr.openjdk.java.net/~rkennke/fixhumongousalloc/webrev.00/

Ugh. The code got even more confusing than it was before... At this point I
wonder if acquiring a lock when claiming free regions is saner than trying to do
this in a lock-free manner. With TLAB allocations, this shouldn't be that painful?

Seeing mutations in ShenandoahFreeSet::is_contiguous() makes me all itchy, it
should be called differently.

Also, does the code claim the regions one-by-one? What if we have two competing
multi-region humongous allocations? Does it guarantee to allocate both (e.g. are
they stepping on each other's toes, preventing global progress?)

Thanks,
-Aleksey