RFC: TLAB allocation and garbage-first policy

[Aleksey Shipilev]

On 09/20/2017 02:58 PM, Aleksey Shipilev wrote:
> On 09/20/2017 02:44 PM, Christine Flood wrote:
>> Another potential solution would be to treat these regions specially.  When a tlab allocation fails
>> in a region we could fill that particular region with a filler array.  Therefore we now have
>> garbage.  This differs from your solution in that regular regions that are perfectly happy with
>> normal sized tlab spaces available aren't going to get prematurely compacted.
> 
> Aha, sounds interesting. So the only thing that does seem to help is the half-full regions we never
> tried to allocate in, right? Otherwise it is the same as looking at "live" for cset selection.

Dang. Now that I try to implement it, it does not seem to work better, because the filler object has
quite a chance to be allocated after TAMS, and thus be treated as implicitly live, and then evac'd.
The kernel idea seems to inflate "used", but we can't really do that without the actual allocation
(whether with filler or not), because "used" is $top-$bottom, and $top is the object iteration
boundary within the region. That is, if we need to inflate "used", we have to move "top", and then
we have to have some object in there, and then it can be live.

Seems like "pick your poison" situation here: either allow copying some filler objects (that got a
chance to be allocated after TAMS), or allow compacting some non-fully-used regions (that were never
fully retired because allocation did not touch them).

I'd say that since we try to take most of the heap before the cycle starts, most of the regions
would get tried to be allocated in, and so the risk of excess work is lower than copying fillers.
Which gets me back to "count live during cset construction".



-Aleksey