ZGC heap size and RSS counters

[Roman Kennke]

>> I agree that's kernel's job to account this properly. But I am also
>> concerned about the practicalities with real deployments on current
>> kernels :( Shenandoah is also about do to double-mapping for related
> 
> Interesting. Do you also plan to do some kind of colored pointers or do 
> you have some other use case for multi-mapping in Shenandoah?

We intend to use it for failure handling.

If a thread T1 fails to evacuate an object in a write-barrier (e.g. 
because it runs OOM), it flips a bit in the object's forwarding pointer, 
and thus prevents any future CASes on it (i.e. evacuations by other 
threads). It can then safely carry on to write into the object, even 
though it hasn't been evacuated. (Subsequent full-gc sorts out the mess 
left behind by this.)

However, it would require to mask out that bit in all read-barriers 
(what you call load-barriers) and write-barriers, and thus impact 
performance in the very common paths (oom-during-evac basically never 
happens. except when it does). When we double-map the heap, we can flip 
the bit such that the fwd ptr now points to he alias mapping, and that 
aliased fwd pointer can still be used for memory addressing.

Nice to see other uses of aliased memory mapping, and that we're not the 
only folks that need an os.hpp API for this ;-)

Cheers,
Roman