It is already deduced using the masklen parameter

A running thread's vruntime is biased by the current time, so we need
to adjust it when reading it back.

Pointed out by Nadav.

To avoid boost::intrusive::rbtree complaining.

Rather than push_back() directly.

Now our Isa serial device can read characters.
Using it by calling readln(char *msg, size_t len);
Note that the calls block until the len input chars or a newline.

No need to explicitly construct a temporary function object.

Threads with borrowed time have been treated "too well" by the scheduler
in the past, so preempt them sooner.  This allows the other threads to catch
up more quickly.

If a thread has very high vruntime, it will be ignored by the scheduler
until all threads with lower vruntime catch up or block.  Limit the damage
by allowing the thread to "borrow" vruntime and place itself in line for
execution.  Overall vruntime accounting is unchanged.

Avoid excessive context switches among cpu-bound threads by biasing the
scheduler towards the currently running thread.

This avoids the possibly expensive insert operation (if there are many
runnable threads) and allows us to add hysteresis to vruntime (since the
vruntime value for the running thread will be biased).

Keep vruntime updated after each schedule.  Note that vruntime for the
currently running thread has a bogus value.

vruntime not accounted for yet.

Though the application should test mprotect()'s success before assuming it
succeeded, let's be extra sure and kill it. (By Avi's request)

mprotect() is normally used on mmap()ed memory. It usually makes little
sense to for applications to mprotect() memory they got from malloc()ed,
for several reasons including the fact that free()ing this memory without
mprotect()ing it back to normal back is a recipe for big trouble (while
with munmap(), there is no need to mprotect() back). We therefore don't
expect Java to use mprotect() on malloc()ed memory.

For us, mprotect() on malloc() memory is particularly undesirable, because
malloc() returns addresses in the linear map, and mprotect()ing that can
"downgrade" this map (change huge pages into small pages) which will never
be fixed later, not even when if mprotect()ing the memory back to normal.
So for now, I'll just forbid mprotect() on addresses in the linear map.

I've written a slightly more advanced version of the old scripts/run.sh,
which also gives control over qemu's memory size and the number of vcpus
used, using command line options:
	-d (or --debug): run the debug build instead of the release build.
	-c N (or --vcpus): number of vcpus (defaults to 4).
	-m M (or --memsize): VM memory size (defaults to 1 GB).

I did not remove the old "scripts/run.sh" - I named the new script
scripts/run - if everyone likes it we can remove the old scripts/run.sh.
We don't need to call it ".sh" - in Unix it isn't customary for command line
tools to have extensions.

In the existing code, #PF was handled correctly (generating a SIGSEGV),
but on most other x86 hardware exceptions, we just abort()ed the kernel.

The #DE (divide error) exception should, like #PF, generate a signal
(the inappropriately-named SIGFPE), and this patch does this. Strangely,
the SPECjvm2008 benchmark depends on this behavior (I didn't check its
source code to figure out why).

To make it easier to generate other signals in the future, I abstracted
the existing function handle_segmentation_fault() into a more general
generate_signal() which is used in both #PF and #DE handling.

The previous code created certain empty directories in the boot file system
(/tmp, /java, /usr/lib) and the bootfs.manifest could only put files in
those directories - attempting to include a file "/foo/bar" would fail
unpacking.

Now, we just create one empty directory (/tmp, I don't even know if it's
necessary), and got rid of the hard-code list of directories - directories
are automatically created as needed. I.e., if the bootfs.manifest contains
a file path /foo/bar/dog, we mkdir() /foo, then mkdir() /foo/bar, and only
then creat() /foo/bar/dog.