java: Add chained exception to ContextIsolator:runjar

This is for somewhat better error reporting.

Signed-off-by: Calle Wilund <calle@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
java: Fix JVM stack protection issues

Run JVM init, main thread, JVM destroy in child thread to avoid stack
protection issues in HS.

Tomek captured a JVM crash in one of the Jenkins builds:

  Aborted

  [backtrace]
  0x0000100000fd1ea8 <JVM_FindSignal+1647320>
  0x00001000011595fe <JVM_handle_linux_signal+1569582>
  0x0000100000fda4f6 <JVM_handle_linux_signal+550>
  0x0000000000368722 <call_signal_handler+338>
  0x000000000036c53d <call_signal_handler_thunk+7>
  0x000010000103f079 <JVM_handle_linux_signal+413097>
  0x0000100000d48c61 <AsyncGetCallTrace+238721>
  0x0000100000fd0f21 <JVM_FindSignal+1643345>
  0x0000000000419ad5 <setpgid()+229>
  0x00000000003b6dca <thread_main_c+26>
  0x000000000036c535 <thread_main+7>

Calle explains:

  So, this is the problem:

  * java.so does CreateJavaVM

      - This attaches the thread to the JVM, the "initial thread", which
	on linuxes are somewhat special, as in it is hard to get
	accurate stack info on it, thus the attach/init code is filles
	with horrendous stuff to figure out what is reasonable stack
	bounds for it, all in order to add stack guard pages somewhere
        appropriately.

      - This goes pretty fine, it finds something reasonable and
        continues. Lets call the now protected region X.

  * java.so calls io.osv.MultiJarLoader, which in turn starts a bunch of
    threads, then returns.

  * java.so main thread detaches. HS now "unprotects" the stack guard
    pages. However, due to Linux and its somewhat glued-on thread
   library,this is actually done by munmap:ing the pages in question (X).

  Now, at the same time:

  * A java thread loads a zip file. It asks to map a section of the
    file. The vma code finds a nice, empty hole at X and uses it.

  And at the same time:

  * Main thread calls DestroyJavaVM. This re-attaches the main thread.
    Now, main thread stack info is already collected, so HS just
    re-protects region X (mmap fixed). Woho. Except we just wrote over the
    file mapping above.

  So, in a way the problem is that OSv does not treat memory regions
  that are / has been / could be stack area (or be interpreted as it by
  HS) special, and allows mmap to give back these pages.

  But, the solution is way easier, and is in fact that which all JDK
  launchers have employed for quite some time now, namely _never_ use the
  main thread for anything Java.

  All java launchers will create, run and destroy the JVM from an
  immediate child thread to avoid just this problem above, with
  misinterpreted stack areas. By doing this, the VM will only use
  (hopefully) the info returned by pthread_attr_getstack-blabla.

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