We don't want cglib classes needed by io.osv.* classes to be
accessible from application classes. This could cause problems
if application would want to use its own version of cglib. In this
case the application provided cglib would be masked by the one
inside OSv.

To solve this problem we do not set the current class loader
as application class loader parent, but instead we link it with
a proxy which combines bootstrap class loader and the original
system class loader allowing only classes from io.osv.* package
to be loaded from the system class loader.

Class loader diagram:

 +-----------+
 | Bootstrap |<---------------+
 +-----------+                |
      ^                       |
      |                       |
      |                       |
 +----+------+  io.osv.*  +-----------+
 | System    |<-----------| Filtering |
 +-----------+            +-----------+
                              ^
                              |
                              |
            +-----------+     |
            | App 1     |-----+
            +-----------+     |
                              |
            +-----------+     |
            | App 2     |-----+
            +-----------+

This way the application may still use OSv java APIs, but does
not see classes from our dependencies and may load its own version
of these classes.

The solution is using Java reflection API to replace Properties object
in System.prop with a version which delegates to per-context
properties.

This allows each application to see different values for the same
property. This works with properties set via both command line
parameter (-D) and programatically with System.setProperty().

File.listFiles() may return null. Spotted by IntelliJ.

This makes API more friendly.

We don't use it and I can hardly think of a way this could be useful.

Currently the error is just printed on the console. Throwing exception
allows API user to react on this situation in the most appropriate
way. For example if new application is started using a web interface
printing on console is useless.

It does not belong in the isolate API but to the
command line java starter.

Auto reformat performed from IntelliJ (alt+ctrl+L)

Interrupting a thread which is blocked waiting for an isolate to
complete which was started via runSync() should interrupt the isolate.
The waiter should return only after isolate terminated.

I think this is what users would expect to happen when interrupting a
foreground process.

ContextIsolator is a generic API for starting new applications inside
a single JVM. RunJava should be just a command-line starter which uses
that API.

I tried to change as little as possible during the code move so that
any changes to that logic are clearly visible. The changes which adapt
the code to a more generic API are in the next patches.

The j.u.l framework allows only one log manager to exist. To isolate
logging configurations we need to install our own log manager which
delegates to context-local log managers.

See #172.

In order to have a fully isolated logging config system properties
need to also be isolated. This will come in the following patches.

It will allow to use automatic dependency management.

It slows down the build a bit. Incremental build takes 3 seconds
longer than previously.

First build takes longer due to downloading of maven artifacts.
This is once per machine.

There is a convention to organize java modules in the following way:

src/main/java - source root for production code
src/test/java - source root for test code

I need static-initialization-like semantics in several places.
This abstraction makes it easier.

We aim to support running multiple isolated Java applications in one
JVM. Some work has already been done to isolate system class
loaders. There is much more to it than that. Isolated applications
(aka Contexts) do not map 1-1 to class loaders. One context may have
many different class loaders.

This change extracts context-specific logic to separate classes as a
base for further additions.

env->FindClass() triggers class initialization which may throw
exceptions. Instead of printing misleading information that the class
was not found we should print the exception stack-trace.

Currently debug messages are not printed on console by default.

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>