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>

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>

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>

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>

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>

JavaVMOption has extraInfo member that's not initialized in mkoption().
It only used by few special case options that provide a function pointer
hook to the JVM so it's harmless but fix it anyway.

Spotted by Coverity.

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

Add Cloudius copyright statement to files in java/. All of these (one C++
java.cc and the rest Java source code) are our own code.

Pass the "-D" command line options that are used to configure JMX, for
example, to the JVM.

Pass -X* (and of course also -XX*) options to the JVM.
The -Xmx option is the most useful example.

The JVM options end with the first "-jar" *or* classname, not *and*.
Fix the typo.

The recent change, to add the program name as argv[0] for C code's
main(), make sense for C code, but less for Java code, where main()
normally expects args[0] to be the first argument, not the program name.

So the change to RunJava.java was un-Java-like; It also broke the "java"
CLI command which didn't put "java" in argv[0] for the arguments to
RunJava.main(), so the "java" command no longer worked after the previous
patch.

Instead, we change java.cc (which compiles to java.so). This is what
calls RunJava.class, and it should remove the new argv[0] before calling its
main() - instead of expecting that RunJava.class to do this.

java.cc would exit right after the main() method finished. But in Java,
this is not the correct behavior. Rather, even if main() returns, we
need to wait for all other threads to end (or more accurately, wait
for all threads not marked with setDaemon(true)).

Calling jvm->DestroyJavaVM() does this for us, and it's probably the
Right Thing(TM) to do anyway.

Before this patch, the Jetty benchmark exited immediately after
startup.  After this patch, its worker threads keep the whole VM running.

Java.so used to correctly support the "-jar" option, but did not fully
allow the other "mode" of running Java: specifying a class name which is
supposed to be searched in the class path. The biggest problem was that
it only know to find class files, but not a class inside a jar in the class
path - even if the classpath was correctly set.

Unfortunately, fixing this C code was impossible, as JNI's FindClass()
simply doesn't know to look in Jars.

So this patch overhauls java.so: Java.so now only runs a fixed class,
/java/RunJava.class. This class, in turn, is the one that parses the
command line arguments, sets the class path, finds the jar or class to
run, etc.. The code is now much easier to understand, and actually works
as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*"
benchmarks, which forced us to tweak the class path manually.

The new code supports running a class from the classpath, and also the
"-classpath" option to set the class path. Like the "java" command line
tool in Linux, this one also recognizes wildcard classpaths. For example,
to run Jetty, whose code is in a dozen jars in /jetty, one can do:

        run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"

eventually causing a suspicious segfault.

This allows running either testrunner.so, or one of the tests (e.g.
test/tst-fpu.so), as they now both export the same entry point.

-jar terminates the JVM arguments, so that 'java -jar foo.jar -x' passes
-x to foo.jar, not the JVM.

A silly error causes a crash whenever arguments to the Java class are
supplied.

This will allow running unmodified tests with a main() entry point even
after splitting the test loader out of the kernel.

Note that the glue code to set up the class path is written in Java.

The test code assumes /tests contains shared objects.

Set with the imgedit tool.

This standardizes our method of running a payload: run a shared object with
argc/argv.  No special treatment for the jvm.