The previous commit (fix symbol resolution order) caused a regression -
tst-pipe.so stopped working, aborting on segfault while handling an
expected exception (one of the only places in OSV where we use an
exception to signal an error - running out of file descriptors).

However, it turns that commit just exposed an already existing bug
in our exception unwinding support. The following trivial test of
exceptions, throwing an integer and catching it, crashes both with
the previous commit, and without it.

Christoph discovered a bug in our dynamic linker, where symbols which
exist in the kernel cannot be used in a shared object, which can
cause nasty bugs when trying to run existing programs.

This test demonstrates this bug, and verifies its fix (in the
previous commit).

2 threads are created on 2 different vcpus, one consumer and one producer.

Both threads are pushing and popping concurrently 1,000,000,000 elements,
the producer is pushing a random number between 0 and 7 and consumer pops
those numbers. Both of the threads keeps track on the values they
pushed/popped. per each value, the number of pushed elements
should be equal to the number of popped elements.

 - ring_spsc: 14.8 Mop/s per core

Add tst-epoll.cc for testing the epoll_*() functions.
This test finds a bug, which will be fixed in a separate patch.

This reverts commit ccaad30c.

Added a test for wake_with(). It tries to ensure that the problematic
case solved by wake_with() actually happens quickly, by:
 1. Spin a long time between the setting of the flag and t->wake()
 2. Do a spurious wake() to ensure that the waiting thread is woken
    up right after setting the flag, before the intended wake.
 3. Use mprotect() to ensure that working with an already join()ed
    thread crashes immediately, instead of just maybe crashing.

This test fails when wake_with() doesn't use ref()/unref(), and succeeds
with the full wake_with().

tst-wake contains a second test, which does the same thing but without
the additional measures we used to show the bug (spinning, spurious
wake and mprotect). Without these additional measures the test iteration
is much faster, which allows us to stress wake/join much more.

Usage:

  perf list (lists all tracepoints)
  perf stat tp... (counts tracepoints)

Example:

[/]$ perf stat mutex_lock ctxsw=sched_switch mutex_unlock wake=sched_wake
  mutex_lock   ctxsw  mutex_unlock    wake
          40       3          1909       2
        2075     147           190      82
         193     138           193      78
         146     139           146      92
         317     179           317      78
         146     139           146      78
         146     139           186      78
         205     139           165      78
         146     139           146      78
         146     139           146      78
         146     139           146      80
         193     143           193      81
         151     147           151      78
         146     139           146      78
         146     139           146      78
         146     139           146      78
         159     139           159      78
         149     139           149      78
         146     139           146      78
         164     139           164      78
         146     139           176      78
         176     139           146      78
         149     139           149      78
         146     139           146      78
         146     139           146      78
  mutex_lock   ctxsw  mutex_unlock    wake
         146     139           146      79
         715     147           715      80
         188     139           204      78

Exposes tracepoints and counters

Add a "java" command to the CLI, using the same syntax of java.so and
attempting to emulate as closely as possible the "java" command on Linux.
So for example one can run

        java Hello

to run /java/Hello.class (/java is on the classpath by default), or

        java -jar /java/bench.jar

to run the main class of this jar, or a more sophisticated
command lines, such as the following which runs Jetty (if the
appropriate files are in your image):

        java -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration /jetty/jetty.xml

Note that like java.so, the new "java" command basically runs the RunJava
class (/java/RunJava.class). Remember that java.so adds /java to the parent
class loader, so we can always find the RunJava class even though it's not
in cli.jar or cloudius.jar).

these tests are a bit outdated, they change the system configuration and are
not useful anymore, they were basically written to understand how stuff works.

tst-bsd-netdriver.c - was made just to figure out the network driver model of
                      freebsd.
tst-bsd-netisr.c    - same for isr layer, this tests runs over the ARP isr and
                      the system is badly wounded after it runs, it is useless today
                      and was written to figure out how netisr works.
tst-virtionet.c     - testing network interface creation using virtio,
                      today the interface is created anyway.

This patch adds pipe(). The pipes are built using the same FIFO implementation,
"af_local_buffer", as used by the existing unix-domain socketpair
implementation - while the socket-pair used two of these buffers, a pipe
uses one.

This implementation deviates from traditional POSIX pipe behavior in two
ways that we should fix in followup-patches:

1. SIGPIPE is not supported: A write to a pipe whose read end is closed
   will always return EPIPE, and not generate a SIGPIPE signal.
   Programs that rely on SIGPIPE will break, but SIGPIPE is completely out
   of fashion, and normally ignored.

2. Unix-style "atomic writes" are not obeyed. A write(), even if smaller
   than PIPE_BUF (=4096 on Linux, whose ABI we're emulating), may partially
   succeed if the pipe's buffer is nearly full. Only a write() of a single
   byte is guaranteed to be atomic.

   We hope that Java doesn't rely on multi-byte write() atomicity
   (single-byte writes are enough for waking poll, for example), and users
   of Java's "Pipe" class definitely can't (as Java is not Posix-only),
   so we hope this will not cause problems. Fixing this issue (which is easy)
   is left as a TODO in the code.

Additionally, this patch marks with a FIXME (but doesn't fix) a serious
bug in the code's iovec handling, so writev() and readv() are expected
not to work in this version of pipe() - and also on the existing socketpair.

Added a simple readdir() and readdir_r() test.
The test is successful - it turns out readdir() had no bug, and the bug
was in mkbootfs.py, but since I already wrote the test I guess might as
well add it.

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"

Builds on osv an Linux.

Tests context switch performance:
  - between threads co-located on the same cpu
  - between threads on different cpus
  - between threads placed by the scheduler policy

The following test currently frequently crashes - with an abort or
assertion failure.

It's a very simple test, where 10 threads do an endless yield() loop.
While yield() itself is not very important - and doesn't even implement
the promise of sched_yield(2) to move the thread to the end of the run
queue - this test failure may be the sign of a scheduler bug that needs to
be fixed.

Until now, OSV's console defaulted to raw mode, to make the CLI
happy. The problem is that on Linux, applications expect to be
run in cooked mode, so if we ever run a simple application that
tries to read user input, it can be confused.

This patch makes OSV console default to cooked mode, and the
CLI switch to raw mode before reading an input line - and reset
to the default mode just before running the user's command.

Unfortunately, we had to resort to adding a JNI class "Stty",
since Java has no builtin support for the ioctls required for
changing the tty settings.

While trying to run the "compiler.compiler" benchmark from SPECjvm2008,
I noticed we seem to have a problem with concurrent use of filesystem
operations - which often hang (waiting on a vn_lock()) or cause
assertion failures.

This trivial test - which does stat() calls in 10 concurrent threads -
reproduces this bug, and usually (but not always) crashes on one of
several assertion failures, or hangs.

APIs. In particular, the "crypto.aes" and "crypto.rsa" benchmarks
fail without them.

At some point, we should consider just adding most of the stuff in
/usr/lib/jvm/java/jre/lib to our distribution... Everything in that
directory has to be useful for something, and it might take a while
before we try all possible APIs in OSV...

split cloudius.jar to cloudius.jar an cli.jar
the following patch will introduce proper code reusing between the two jars
basically, cli.jar will be dependant on cloudius.jar

Clean up the lockfree/mutex.hh code. This introduces no new algorithms or
major bug fixes - what was blocking the lockfree mutex from working were
mainly preemption bugs and a bug in the lockfree queue implementation.

Also introduced a test for the mutex variants (mutex, lockfree::mutex and
spinlock) - several threads do a non-atomic increment to a shared variables,
and unless a mutex is used, the sum ends up being wrong. The test seems to
be working correctly, and also exercising the interesting cases of the code
(the "responsibility hand-off" protocol), but does so very rarely, so we'll
still need more testing before we can fully trust this new code.

The test also begins to do performance testing on the mutex variants.
uncontended lockfree::mutex is currently twice slower than uncontended
mutex, so some more work is needed in this area.