As we have recently discovered, some parallel GCs will move an object to two
different locations at times, and later on decide on which one to use. This
breaks our implementation if the final object is the second one to be copied,
because by then the original region is already mapped - so we won't fault, and
the unmapped region will not be the actual balloon, so we will have a bogus
fault

The core of this solution is to keep all the regions unmapped. Because they had
only garbage before, we know Java shouldn't read anything from it before it
writes something new. And when it does that, we declare that to be no longer a
balloon.

Movement is then split in two phases: the normal phase, and the finish phase.
In the finish phase we will remove the old VMA and create the new VMA again,
with heap characteristics.

Special care needs to be taken when "conciliating" the array: because we use
the difference between first faulting address and original array address to
calculate how many bytes we are skipping, we need to store that information
somewhere. We're using an unordered_map (hash) for that. We'll keep track of
all in-flight ballooned regions and hold the original address of the array.

When we detect movement *from* that region, we know it is the new location
and update the balloon object with the new address.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

The biggest problem I am seeing with the balloon is that right now the only
time we call the balloon is when we're seeing memory pressure. If pressure is
coming from the JVM, we can livelock in quite interesting ways. We need to
detect that and disable the ballon in those situations, since ballooning when
the pressure comes from the JVM will only trash our workloads.

It's not yet working reliably, but this is the direction I plan to start from.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This patch implements the JVM balloon driver, that is responsible for borrowing
memory from the JVM when OSv is short on memory, and giving it back when we are
plentiful. It works by allocating a java byte array, and then unmapping a large
page-aligned region inside it (as big as our size allows).

This array is good to go until the GC decides to move us. When that happens, we
need to carefuly emulate the memcpy fault and put things back in place.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>