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>

The system classloader should have classes which were
specified in the command line using -cp/-classpath/-jar.
Before this change only runjava.jar was included.

System class loader is queried explicitly by
java.util.logging framework to lookup classes
configred in logging properties file.

To solve this problem a custom system classloader
is set when starting JVM. It delegates to the application
classloader created when java program was started.

It also handles the case when a new java application
is started within the same JVM. Such application
should have its own view of system classes. However
we are able to install only one system classloader
per JVm. To solve this we start each java application
in a separate thread and use InheritableThreadLocal
to hold the application class loader which should be
used as system class loader view for the thread family.

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

Building with ant requires no changes in the build scripts
when new classes are added. It is a standrd tool to build
java programs.

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

This is patch v2, incorporating most of the comments from the previous round.

Solves issue #47:

elf::program's API - add_object() and remove_object() was problematic in
two respects:

1. It did not do reference-counting on the loaded object, so if add_object()
   was done 5 times, a single remove_object() would unmap the object and
  its 4 other users will crash.

2. It is un-C++-like.

This patch replaces these two functions by a single function get_library():

  std::shared_ptr<elf::object>
   get_library(std::string lib, std::vector<std::string> extra_path = {});

get_library() returns a shared_ptr, which is reference counting and does
proper C++-style RAII. For example in the code:

	auto lib = elf::get_program()->get_library(path);
	auto main = lib->lookup<int (int, char**)>("main");
	int rc = main(argc, argv);

once lib out of scope, the reference count of the elf::object automatically
goes down, and if nobody else holds another shared-pointer to the same
library, the object is destroyed (causing the shared library to be unloaded).

This patch also documents, with Doxygen, all the functions it touches.

IMPORTANT NOTE: This reference count is completely unrelated to the issue
of concurrent use of dlopen()/dlclose()/dl_iterate_phdr(), which is still
buggy and we need to fix (I have a patch for that, but it's too long to fit
in the margin).

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

URLClassLoader determines whether URL denotes a jar or directory
by checking the last character of the path.

Before:

   [/]% java -cp java Hello
   Uncaught Java exception:
   java.lang.ClassNotFoundException: Hello
       at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
       at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
       at io.osv.RunJava.loadClass(RunJava.java:175)
       at io.osv.RunJava.runClass(RunJava.java:115)
       at io.osv.RunJava.parseArgs(RunJava.java:81)
       at io.osv.RunJava.main(RunJava.java:27)

After:

   [/]% java -cp java Hello
   Hello, world.

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

Currently we call abort() if something is wrong whith
java.so command. Now that we allow to run processes from
the command line this may not be the best behavior because
a problem with starting a less import program will abort
the system:

  [/]% run java.so -cp java Hello
  run_elf(): running main() in the context of thread 0xffffc0000c30b010
  java.so: Can't create VM.
  Aborted

Instead of that we could just return and the system can
be still usable:

  [/]% run java.so -cp java Hello
  run_elf(): running main() in the context of thread 0xffffc0000c30b010
  java.so: Can't create VM.
  run: finished with exitcode 1

  [/]%

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

This is needed to start the JVM with debugger interface.

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

We use the RunJava Java class to run Java applications (both java.so
and the "java" CLI command use it). We used to have RunJava.class
uncompressed, in the /java directory, but this caused two problems:

1. Or noticed that having a directory (/java) on the classpath causes
   thousands of stat() calls when Java tries to look for all classes
   in this directory. With a jar, its contents are read only once.

2. The "java" CLI command (java.groovy) didn't work because apparently
   Groovy cannot deal with classes being in the top-level package.

   So this patch moves RunJava into the io.osv package, and put it into a jar
   /java/runjava.jar.

   Note that java.groovy is changed in a separate patch (because it's in
   a different sub-repository....)

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

Add "-version" option to RunJava, and therefore to java.so and the "java"
CLI command.

java -version now shows:

  java version "1.7.0_25"
  OpenJDK Runtime Environment (1.7.0_25-mockbuild_2013_07_27_13_36-b00)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

I can't explain why the version on the second line is different than what
"java -version" on Fedora 18 shows for the same libjvm.so:

  java version "1.7.0_25"
  OpenJDK Runtime Environment (fedora-2.3.10.4.fc18-x86_64)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>