java: Add helper class to create Json like list

This helper class is used when it is needed to create an array or an
object in a Json like format.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Java Json generator: Add a Helper class for JSON generator

The JavaInfo class retrieve information from the java and pass it to the
C++.  Some of the information is in a json format.

This helper class add some static method to create JSON formatted
string.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
java: JavaInfo Garbage collection information

This is a helper class to holds the garbage collection information, it
simplified getting the data in the c++ side.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
java: Adding the JavaIno class

The JavaInfo simplify getting information from the java and return it
via the JNI to the API.

It sets a simple front end for the internal java information.

Currently it support get and set mbean information, get the garbage
collection information and system properties.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
java: add an interface for the java from the api

The API requires to retrieve and modify information in the jvm. To
simplify this the java_api is used as a C++ front-end to the java, it is
backed up by a java class (JavaInfo) that acts as a front-end of the
java.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
java: set the JavaVM in the java_api

The java_api used by the API uses JNI to connect to the running jvm. It
needs the JavaVM pointer to get be able to connect to the JVM.

The JavaVM is been set after the jvm is created.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
build.mk: Add the java_api to the compilation and packaging

The java_api.cc is a helper class that the API use to get information
from the java. It need to be compiled and added to the image.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Merge github.com:amnonh/osv
mgmt: update to latest

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
loader: Print OSv version info correctly

On VBOX and VMW, the version info is not printed correctly.
Fix it by only print after our console is initialized.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Asias He <asias@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Support 'make osv.vmdk' without 'make all'

Add 'all' as dependent target of osv.vmdk/.vdi, to prevent build error.

Signed-off-by: Takuya ASADA <syuu@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
bsd: set a smaller default stack for BSD threads.

All threads created through the bsd/porting/kthread interface are threads that
used to be kernel threads in BSD, which means they are expected to use less
stack. Although I have no idea what is the default stack size for BSD, in Linux
things need as little as 4k. More importantly, they are threads whose memory
usage are under our control, and we could fix heavy offenders without a
problem.

If we don't say anything, they will start with 64k which is way, way, too much.
I am proposing here we go lower and get to 16k - which is even still quite
conservative, but so am I.

Measuring memory before and after the mount - because ZFS is currently our
heaviest user, I can save around 7Mb with this patch.

Passes make check (except for tst-kill, which is broken AFAICT) and misc-fs-stress.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
tst-kill: fix crash

tst-kill runs various signal handlers, which we run in separate threads.
When the test completes, we may be unlucky enough for the last signal
handler to still be running, at which point when the module's memory
is unmapped (e.g., in test.py -s each test is unmapped when it ends)
we can get a page fault and a crash.

This patch sleeps for a second at the end of tst-kill, to make sure that
the signal handler has completed; This sleep is a bit ugly, but I can't
think of a cleaner way - Posix provides no way to check if there's a
running handler, and I wouldn't like to add a new API just for this test.

Fixes #249.

Reviewed-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
scripts: Print number of threads in 'osv info threads'

The id of the last thread might mislead people's thinking about
the number of threads in OSv, so let's simply print the nr after all
threads were already printed.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
sched: add atomic reset() operation to timer_base

It is needed by the new async framework.
sched: introduce thread migration lock

This can be useful when there's a need to perform operations on
per-CPU structure(s) and all need to be executed on the same CPU but
there is code in between which may sleep (eg malloc).

For example this can be used to ensure that dynamically allocated
object is always freed on the same CPU on which it was allocated:

  WITH_LOCK(migration_lock) {
    auto _owner = *percpu_owner;
    auto x = new X();
    _owner->enqueue(x);
  }
core: introduce deferred work framework

The design behind timer_task

timer_task was design for making cancel() and reschedule() scale well
with the number of threads and CPUs in the system. These methods may
be called frequently and from different CPUs. A task scheduled on one
CPU may be rescheduled later from another CPU. To avoid expensive
coordination between CPUs a lockfree per-CPU worker was implemented.

Every CPU has a worker (async_worker) which has task registry and a
thread to execute them. Most of the worker's state may only be changed
from the CPU on which it runs.

When timer_task is rescheduled it registers its percpu part in current
CPU's worker. When it is then rescheduled from another CPU, the
previous registration is marked as not valid and new percpu part is
registerred. When percpu task fires it checks if it is the last
registration - only then it can fire.

Because timer_task's state is scattered across CPUs some extra
housekeeping needs to be done before it can be destroyed.  We need to
make sure that no percpu task will try to access timer_task object
after it is destroyed. To ensure that we walk the list of
registrations of given timer_task and atomically flip their state from
ACTIVE to RELEASED. If that succeeds it means the task is now revoked
and worker will not try to execute it. If that fails it means the task
is in the middle of firing and we need to wait for it to finish. When
the per-CPU task is moved to RELEASED state it is appended to worker's
queue of released percpu tasks using lockfree mpsc queue. These
objects may be later reused for registrations.
net: add tracepoints for inpcb life cycle
net: comment-out dead code
net: replace callouts with the new async framework

The callout subsystem is using a shared global lock for most of its
operations. This became a bottleneck after merging net channels.
Explanation for this phenomena is that before net channels
were merged packet processing on the receive side was done form one
(virtio) thread and there was no contention on that lock. After the
merge the packets started to be processed from many CPUs which made
taking the lock expensive.

The new framework uses only per-timer locks, the worker is lock-free.

Below are measurements of the improvement. The measurements (both
before and after) were taken with Nadav's per-CPU rcu_defer()
improvement applied, because it was also a bottleneck.

The value measured was HTTP request-response throughput of tomcat
server as reported by the wrk tool. Server and client on different
machines, 4 vCPUs, 3g of guest memory.

=== 16 connections ===

Before:

  avg = 39272.61
  stdev = 3611.84

After:

  avg = 52701.82
  stdev = 3953.76

Improvement: 34%

=== 256 connections ===

Before:

 avg = 35225.19
 stdev = 2504.27

After:

 avg = 50576.67
 stdev = 3533.39

Improvement: 43%

One challenge in integrating the new framework with TCP stack was a
proper teardown of timers. Current code assumed that after calling
callout_cancel() it is safe to free the timer's memory. This was not
correct because the timer may have already fired and will try to
access memory which has been freed. This is even less correct with the
new framework in which timers have state distributed over many CPUs
and an explicit shutdown() or timer_task destructor need to be
run. The TCP stack had a workaround for this race, each timer checked
the inp field of the tcpcb block for NULL, which was supposed to
indicate that the block has been freed. It still was not perfect
though because the timer may have performed the check before the field
was nulled-out in the tcp_discardcb and then block on a mutex which
will be promptly freed. The solution I went for is to delegate the
release of memory into an async deferred task, which will be executed
as soon as possible but in a safe context, in which we can wait until
all timers are shut down and then free the memory.