The JVM may unmap certain areas of the heap completely, which was confirmed by
code inspection by Gleb. In that case, the current balloon code will break.

This is because we were deleting the vma from finish_move(), and recreating the
old mapping implicitly in the process. With this new patch, the tear down of
the jvm balloon mapping is done by a separate function. Unmapping or evacuating
the region won't trigger it.

It still needs to communicate to the balloon code that this address is out of
the balloons list. We do that by calling the page fault handler with an empty
frame. jvm_balloon_fault will is patched to interpret an empty frame correctly.

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

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This is the old and obsolete sshd implementation.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This was previously added to Stty under the mgmt tree.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Combined java/cli and java/cloudius packages into one.
Added java/cloudius.jar as a jar to the build.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Delete the sched::thread::sleep_until() function. All users of this
function actually wanted a relative time, not absolute time, and can
use the simpler new sched::thread::sleep() instead.

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

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>

This patch introduces a separate operation, "conciliate", that calculates
the balloon parameters given an arbitrary address

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

We should always remove the last balloon we've created. There are two main
reasons for that:

1) The older balloons are likely to be already in more tenured generations,
and will move less, whereas younger balloons could be in younger generations.
So by removing them like a stack, we'll avoid needless moves

2) The probe, when inserted, should stay for as long as we can.

That was always the intended behavior but I made the small mistake of inserting
them in the wrong order. Fix that.

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

At least in its current incarnation, it is risky to start the balloon without
the monitor. Tomek found a problem under which a problem with Tomcat's logging
system would cause an exception to be thrown.

While we were mistaken about the effects of that problem, namely, the exception
seems to caught by the logger itself and won't affect the functioning of the
monitor, it drew our attention to the fact that exceptions do can happen. And if
they do, we should be prepared to catch them and abort.

Reviewed-by: Tomasz Grabiec <tgrabiec@gmail.com>
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>

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

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

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

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

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

Dor Laor writes:

  - Ballooning causes to issues and we like to disable it:

    1. Parallel GC
        2 GC threads are trying to move memory around and they
        do it optimistically without locking. This fools our memmov logic.
        Gleb and Glauber have a solution (to use GCmonitor) but will take
        time to implement.

    2. Logger clash
        The existing GCmonitor bean access the logger early and we don't
        have the tomcat logger handy. Tomek is working on a solution but
        it will take few days to complete.

Therefore, disable the JVM balloon for v0.05.

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

As noted by many of you, we need a mechanism to control whether or not the
balloon mechanism is enabled. A trivial way is to allow for a boot option that
will control it, and that may (or may not) be the right route in the future.

But (at least) right now the safest way to proceed is to view -Xmx as a
declaration of intent. In that case, we disable the balloon, leaving it enabled
only for people who didn't went through the trouble of calculating a value.

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

Make the JVM heap autotuning message silent by default.

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

We respect -Xmx when instructed by the user, but when that is left blank, we
set that to be all remaining memory that we have. That is not 100 % perfect
because the JVM itself will use some memory, but that should be good enough of
an estimate. Specially given that some of the memory currently in use by OSv
could be potentially freed in the future should we need it.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@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>

To find out which vmas hold the Java heap, we will use a technique that is very
close to ballooning (in the implementation, it is effectively the same)

What we will do is we will insert a very small element (2 pages), and mark the
vma where the object is present as containing the JVM heap. Due to the way the
JVM allocates objects, that will end up in the young generation. As time
passes, the object will move the same way the balloon moves, and every new vma
that is seen will be marked as holding the JVM heap.

That mechanism should work for every generational GC, which should encompass
most of the JDK7 GCs (it not all). It shouldn't work with the G1GC, but that
debuts at JDK8, and for that we can do something a lot simpler, namely: having
the JVM to tell us in advance which map areas contain the heap.

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

The best possible criteria for deflating balloons is heap pressure: Whenever
there is pressure in the JVM, we should give back memory so pressure stops.

To accomplish that, we need to somehow tap into the JVM. This patch register
a MXBean that will send us notifications about collections. We will ignore
minor collections and act upon major collections by deflating any existing
balloons.

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

There are restrictions on when and how a shrinker can run. For instance, if we
have no balloons inflated, there is nothing to deflate (the relaxer should,
then, be deactivated). Or also, when the JVM fails to allocate memory for an
extra balloon, it is pointless to keep trying (which would only lead to
unnecessary spins) until *at least* the next garbage collection phase.

I believe this behavior of activation / deactivation ought to be shrinker
specific. The reclaiming framework will only provide the infrastructure to do
so.

In this patch, the JVM Balloon uses that to inform the reclaimer when it makes
sense for the shrinker or relaxer to be called.

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>

MultiJarLoader reads the command line parameters from a file
and uses split to make a list of params out of them before
calling parseArgs.

Currently the regular expression is \\s which means that
consecutive space will be split it to an empty string.
It should be \\s+ so consecutive spaces will be ignored.

Found by code inspection.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>

As pointed out by Tomek, the call to printStackTrace() will already
print out the exception message.

Drop the "uncaught exception" messages to simplify things.

Acked-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

The uncaught exception handler did not state what the exception is.

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

Use ISIG flag for our stty call from jline, in order to translate INT to ^C.
ISIG was added in "Add interrupt and quit keys" (d7292625).

This is related to issue #53.

Reviewed-by: Tomasz Grabiec <tgrabiec@gmail.com>
Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

When using the MultiJarLoader as the main class, it will use a
configuration file for the java loading.  Each line in the file will be
used to start a main, you can use -jar in each line or specify a main
class.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Reviewed-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Use four spaces for indentation and use UNIX linefeeds.

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

This patch adds to support multiple NIC initialization on loader.cc.

Signed-off-by: Takuya ASADA <syuu@dokukino.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Makes this go away:

  Note: io/osv/OsvSystemClassLoader.java uses unchecked or unsafe
  operations.  Note: Recompile with -Xlint:unchecked for details.

Unfortunately javac does not recognize statement level suppressions
like this:

  //noinspection unchecked
  return (T) method.invoke(target, args);

I need to switch to more coarse grained suppression on method level:

  @SuppressWarnings("unchecked")

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

When system classloader is used as a parent some of its protected
methods are called to lookup resources.

This also adds delegation for all remaining protected and public
methods.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Signed-off-by: Or Cohen <orc@fewbytes.com>

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Related changes previously made in java/build.xml
were reverted and moved to java/runjava/build.xml

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>