As I was researching OSv ability to run unmodified Linux pie as is from
host I did quick experiment with Java 8.
I created an app that took all java 8 artifacts as is from host (so no
wrapper):
cat usr.manifest
/usr/lib/jvm/java-8-openjdk-amd64/jre/**:
/usr/lib/jvm/java-8-openjdk-amd64/jre/**
/usr/lib/libjli.so: ->
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jli/libjli.so
/Hello.class: ${MODULE_DIR}/Hello.class
and I was able to run it with two caveats
1. After executing java apps OSv did not terminate and after I connected
with gdb and some Java threads were stuck like this:
(gdb) bt
#0 sched::thread::switch_to (this=0xffff800000aa7040,
this@entry=0xffff800001e73040) at arch/x64/arch-switch.hh:108
#1 0x00000000003fd104 in sched::cpu::reschedule_from_interrupt
(this=0xffff80000096b040,
called_from_yield=called_from_yield@entry=false, preempt_after=...,
preempt_after@entry=...) at core/sched.cc:339
#2 0x00000000003fd5fc in sched::cpu::schedule () at
include/osv/sched.hh:1309
#3 0x00000000003fdd22 in sched::thread::wait
(this=this@entry=0xffff800002f87040) at core/sched.cc:1214
#4 0x00000000003e096f in
sched::thread::do_wait_until<sched::noninterruptible,
sched::thread::dummy_lock, waiter::wait(sched::timer*)
const::{lambda()#1}>(sched::thread::dummy_lock&,
waiter::wait(sched::timer*) const::{lambda()#1}) (pred=...,
mtx=<synthetic pointer>...) at include/osv/sched.hh:938
#5 sched::thread::wait_until<waiter::wait(sched::timer*)
const::{lambda()#1}>(waiter::wait(sched::timer*) const::{lambda()#1})
(pred=...) at include/osv/sched.hh:1076
#6 waiter::wait (tmr=0x0, this=0x2000105ce670) at
include/osv/wait_record.hh:46
#7 condvar::wait (this=0xffffa00002c61280, user_mutex=0xffffa00002c5b140,
tmr=<optimized out>) at core/condvar.cc:43
#8 0x0000100000c9842b in
SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle, int,
BasicType*, VMRegPair*, BasicType) ()
#9 0x0000100000c8036d in
SharedRuntime::throw_StackOverflowError(JavaThread*) ()
#10 0x0000000000000000 in ?? ()
I wonder if that is similar to why we have special logic to terminate all
java threads in wrapper (java.cc). Ctrl-C does not work.
2. I believe there is a bug in elf.cc::program::load_object() where I had
to hack it to force finding and loading one of the shared object java pie
executable depended on (all other so loaded fine). There may be actually 2
bugs:
- there is a bug that prevents loading libjli.so by java pie; adding
this nasty hack worked:
@@ -1149,6 +1150,9 @@ std::shared_ptr<elf::object>
program::load_object(std::string name, std::vector<std::string> extra_path,
std::vector<std::shared_ptr<object>> &loaded_objects)
{
+ if( name == "libjli.so" ) {
+ name =
"/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jli/libjli.so";
+ }
fileref f;
- there is a bug that silently ignores the fact that shared file has not
been loaded and ends up OSv report this:
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java: failed looking up symbol
JLI_Launch
[backtrace]
0x000000000035cb8d <elf::object::symbol(unsigned int, bool)+1325>
0x000000000035cc4f <elf::object::resolve_pltgot(unsigned int)+127>
0x000000000035ce29 <elf_resolve_pltgot+57>
0x00000000003a2d1f <???+3812639>
0x00002000001ffe9f <???+2096799>
0x000000000042e97c <osv::application::run_main()+60>
0x000000000042eaae <__libc_start_main+46>
0x00001000000060c9 <???+24777>
I also ran more complicated examples like vertx REST service one and it
worked perfectly.
Waldek
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
