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.

This is only causing confusion; change all callers to add '\n' explicitly
and drop the optional argument.

With a ring buffer, we need to know the size before writing to determine
if we wrap around.

Strangely, the compiler is able to remove the test code (including the
assert) entirely, as it is able to deduce it passed at compile time.

Thread object creation used to leak one page for the FPU state (thanks
Avi for spotting this). Fix this (add a destructor which frees the page)
and add to the test-suite a test for checking that thread creation doesn't
leak memory - and while we're at it, also checked that alloc_page() and
malloc() at various sizes do not leak memory.

It is already deduced using the masklen parameter

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.

interface we cannot get an answer and it stalls the test execution.

Added the missing TLB flush to the mmap()/munmap()/mprotect() operations.
Note that currently I only do this on the processor running mmap(), which
is incorrect (I put in a TODO), but is good enough for Java's use case
(which is to do these things on startup).

Also added more tests, and fixed a bug on mmap(PROT_NONE) (mprotect(PROT_NONE)
used to work, but mmap(PROT_NONE) didn't).

Automate the tests for mprotect() using sigaction() - verifing that writing
to read-only page causes SIGSEGV, and so on.

One *failing* test is left commented out - currently we're missing a TLB
flush on mprotect(), so if we write to a page and then make it read-only,
the new read-only status isn't noticed by the processor.

The fpu test was written to be run standalone, but that doesn't work
running from testrunner.so since the entry points are different (main vs.
osv_main).

once the destination interface owns the hard coded mac addr

Java uses mprotect(..., PROT_NONE) for guard pages (e.g., to catch stack
overflow). This patch implements it by removing the present bit on these
pages' mappings, which does not mean the pages have been unmapped (their
memory is kept intact, and running mprotect again can make them readable
again.

Test that preemption does not corrupt fpu registers.

is not currently supported, and PROT_READ is used instead (i.e., instead of
inaccessible memory, one gets read-only memory). Inaccessible memory
complicates the code because it means using the non-present bit on
still-allocated pages, and then unpopulate() can't use the present bit to
decide which pages are allocated and need to be freed.
To fix this, I'll need to:
1. unpopulate_page() and unpopulate_huge_page() should assume it is only
ever called on allocated pages (evacute() actually ensures that!), and not
return on non-present ptes.
2. change_perm() should use the read_perm to set the present bit.
3. protect() shouldn't rely on present bit to know when to return 0 or 1,
   rather it must be wrapped in something like evacute() which knows to
   find mapped ranges, and only call protect() for actually mapped ranges.
I'll try this tomorrow.

the version at the time of commit. Git is overrated :(

implementation of both was completely broken - not only did evacuate()
never free the physical memory backing the removed mapping, it was
sometimes even called with wrong parameters ;-)
Added tests to check that some of the mmap/munmap combinations no longer
leak memory.

embarrassing errors ;-)

Rename all 'log' functions of class log into 'wrt'. The reason is that BSD has a #define log line and there was a clash

As an actual benchmark, it's more or less worthless, since the JVM sees
a lot of SEGVs and inserts an inline check eventually, so the test takes
1 ns per iteration.

length N and runs the simple Sieve of Eratosthenes (of finding all the
prime numbers below N), which jumps around the array at various strides
and therefore exercises, among other things, the TLB, and can be effected
by whether we use huge pages or normal pages for storing the array.

To allow running this benchmark without increasing the VM's memory,
main() uses N=100,000. But to really see the effect of huge pages,
try N=200,000,000 (commented out in main()).