In such case current context was not initialized. The fix is to default to master context.

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

All fixes for all (known) problems with the balloon are now in the tree.
Reenable it.

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

The tests can be run on the host, using host's JRE like this:

  cd java; mvn test

This is mainly useful during development to have a short modify-test
cycle. The tests should be eventually executed on OSv and support for
that will follow.

The test code is split into two modules which yield two separate jars:

 tests          - contains test cases
 tests-isolates - contains code which is started in isolated context

We need separate jars for these two to have different classpath in the
isolate and thus more realistic tests.

Since class space is now isolated I cannot exchange objects between
contexts using static fields anymore. I will need some mechanism to
pass objects to isolates started in tests to be able to coordinate
their execution.

The solution is a simple send/receive support which allows to pass
objects around.

This helps the invoker to determine if isolate executed successfuly or not.

Tomcat tries to invoke that method on the class loader if it is not instance
of URLClassLoader.

Makes the messages like this go away:

 Jan 22, 2014 12:30:21 PM org.apache.catalina.loader.WebappLoader buildClassPath
 INFO: Unknown loader io.osv.OsvSystemClassLoader@fce56f8 class io.osv.OsvSystemClassLoader

This is an optimization which saves the isolate code from going
through OsvSystemClassLoader proxy.

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>