Uh oh!
There was an error while loading. Please reload this page.
[enhancement](java-udf) Support loading libjvm at runtime - #13660
Conversation
hello-stephen
commented
Oct 25, 2022
TeamCity pipeline, clickbench performance test result: |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
hello-stephen
commented
Oct 27, 2022
TeamCity pipeline, clickbench performance test result: |
PR approved by at least one committer and no changes requested. |
## Proposed changes Revert #13660 `-l` and `dlopen` load Dynamic Link Library, will use the Allocator of main program, Doris use Jemalloc by default. but, `dlopen` load libjvm.so and use Jemalloc compiled with prefix, overwriting malloc/free will incompatible with libjvm.so. see #34578 for details. In addition, jemalloc not recommend `dlopen` to load Dynamic Link Library, `dlclose` will memory leak in that case. jemalloc/jemalloc#2404jemalloc/jemalloc#1321jemalloc/jemalloc#1890 `export LD_PRELOAD` to force `libjvm.so` use a separate `jemalloc.so` will not solve the problem, but may cause a new crash. ``` received by PID 2368 (TID 2391 OR 0x7f445cafb700) from PID 0; stack trace: *** 0# doris::signal::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) at /root/selectdb-core/be/src/common/signal_handler.h:421 1# PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0] in /opt/jdk/lib/server/libjvm.so 2# JVM_handle_linux_signal in /opt/jdk/lib/server/libjvm.so 3# 0x00007F448DB40400 in /lib64/libc.so.6 4# je_arena_dalloc_promoted at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/arena.c:1277 5# je_free_default at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/jemalloc.c:3014 6# __pthread_create_2_1 in /lib64/libpthread.so.0 7# os::create_thread(Thread*, os::ThreadType, unsigned long) in /opt/jdk/lib/server/libjvm.so 8# CompilerThread::CompilerThread(CompileQueue*, CompilerCounters*) in /opt/jdk/lib/server/libjvm.so 9# CompileBroker::make_thread(CompileBroker::ThreadType, _jobject*, CompileQueue*, AbstractCompiler*, JavaThread*) [clone .constprop.0] in /opt/jdk/lib/server/libjvm.so 10# CompileBroker::possibly_add_compiler_threads(JavaThread*) in /opt/jdk/lib/server/libjvm.so 11# CompileBroker::compiler_thread_loop() in /opt/jdk/lib/server/libjvm.so 12# JavaThread::thread_main_inner() in /opt/jdk/lib/server/libjvm.so 13# Thread::call_run() in /opt/jdk/lib/server/libjvm.so 14# thread_native_entry(Thread*) in /opt/jdk/lib/server/libjvm.so 15# start_thread in /lib64/libpthread.so.0 16# clone in /lib64/libc.so.6 ``` <!--Describe your changes.-->
## Proposed changes Revert apache#13660 `-l` and `dlopen` load Dynamic Link Library, will use the Allocator of main program, Doris use Jemalloc by default. but, `dlopen` load libjvm.so and use Jemalloc compiled with prefix, overwriting malloc/free will incompatible with libjvm.so. see apache#34578 for details. In addition, jemalloc not recommend `dlopen` to load Dynamic Link Library, `dlclose` will memory leak in that case. jemalloc/jemalloc#2404jemalloc/jemalloc#1321jemalloc/jemalloc#1890 `export LD_PRELOAD` to force `libjvm.so` use a separate `jemalloc.so` will not solve the problem, but may cause a new crash. ``` received by PID 2368 (TID 2391 OR 0x7f445cafb700) from PID 0; stack trace: *** 0# doris::signal::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) at /root/selectdb-core/be/src/common/signal_handler.h:421 1# PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0] in /opt/jdk/lib/server/libjvm.so 2# JVM_handle_linux_signal in /opt/jdk/lib/server/libjvm.so 3# 0x00007F448DB40400 in /lib64/libc.so.6 4# je_arena_dalloc_promoted at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/arena.c:1277 5# je_free_default at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/jemalloc.c:3014 6# __pthread_create_2_1 in /lib64/libpthread.so.0 7# os::create_thread(Thread*, os::ThreadType, unsigned long) in /opt/jdk/lib/server/libjvm.so 8# CompilerThread::CompilerThread(CompileQueue*, CompilerCounters*) in /opt/jdk/lib/server/libjvm.so 9# CompileBroker::make_thread(CompileBroker::ThreadType, _jobject*, CompileQueue*, AbstractCompiler*, JavaThread*) [clone .constprop.0] in /opt/jdk/lib/server/libjvm.so 10# CompileBroker::possibly_add_compiler_threads(JavaThread*) in /opt/jdk/lib/server/libjvm.so 11# CompileBroker::compiler_thread_loop() in /opt/jdk/lib/server/libjvm.so 12# JavaThread::thread_main_inner() in /opt/jdk/lib/server/libjvm.so 13# Thread::call_run() in /opt/jdk/lib/server/libjvm.so 14# thread_native_entry(Thread*) in /opt/jdk/lib/server/libjvm.so 15# start_thread in /lib64/libpthread.so.0 16# clone in /lib64/libc.so.6 ``` <!--Describe your changes.-->
Revert apache#13660 `-l` and `dlopen` load Dynamic Link Library, will use the Allocator of main program, Doris use Jemalloc by default. but, `dlopen` load libjvm.so and use Jemalloc compiled with prefix, overwriting malloc/free will incompatible with libjvm.so. see apache#34578 for details. In addition, jemalloc not recommend `dlopen` to load Dynamic Link Library, `dlclose` will memory leak in that case. jemalloc/jemalloc#2404jemalloc/jemalloc#1321jemalloc/jemalloc#1890 `export LD_PRELOAD` to force `libjvm.so` use a separate `jemalloc.so` will not solve the problem, but may cause a new crash. ``` received by PID 2368 (TID 2391 OR 0x7f445cafb700) from PID 0; stack trace: *** 0# doris::signal::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) at /root/selectdb-core/be/src/common/signal_handler.h:421 1# PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0] in /opt/jdk/lib/server/libjvm.so 2# JVM_handle_linux_signal in /opt/jdk/lib/server/libjvm.so 3# 0x00007F448DB40400 in /lib64/libc.so.6 4# je_arena_dalloc_promoted at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/arena.c:1277 5# je_free_default at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/jemalloc.c:3014 6# __pthread_create_2_1 in /lib64/libpthread.so.0 7# os::create_thread(Thread*, os::ThreadType, unsigned long) in /opt/jdk/lib/server/libjvm.so 8# CompilerThread::CompilerThread(CompileQueue*, CompilerCounters*) in /opt/jdk/lib/server/libjvm.so 9# CompileBroker::make_thread(CompileBroker::ThreadType, _jobject*, CompileQueue*, AbstractCompiler*, JavaThread*) [clone .constprop.0] in /opt/jdk/lib/server/libjvm.so 10# CompileBroker::possibly_add_compiler_threads(JavaThread*) in /opt/jdk/lib/server/libjvm.so 11# CompileBroker::compiler_thread_loop() in /opt/jdk/lib/server/libjvm.so 12# JavaThread::thread_main_inner() in /opt/jdk/lib/server/libjvm.so 13# Thread::call_run() in /opt/jdk/lib/server/libjvm.so 14# thread_native_entry(Thread*) in /opt/jdk/lib/server/libjvm.so 15# start_thread in /lib64/libpthread.so.0 16# clone in /lib64/libc.so.6 ``` <!--Describe your changes.-->
## Proposed changes Revert apache#13660 `-l` and `dlopen` load Dynamic Link Library, will use the Allocator of main program, Doris use Jemalloc by default. but, `dlopen` load libjvm.so and use Jemalloc compiled with prefix, overwriting malloc/free will incompatible with libjvm.so. see apache#34578 for details. In addition, jemalloc not recommend `dlopen` to load Dynamic Link Library, `dlclose` will memory leak in that case. jemalloc/jemalloc#2404jemalloc/jemalloc#1321jemalloc/jemalloc#1890 `export LD_PRELOAD` to force `libjvm.so` use a separate `jemalloc.so` will not solve the problem, but may cause a new crash. ``` received by PID 2368 (TID 2391 OR 0x7f445cafb700) from PID 0; stack trace: *** 0# doris::signal::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) at /root/selectdb-core/be/src/common/signal_handler.h:421 1# PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0] in /opt/jdk/lib/server/libjvm.so 2# JVM_handle_linux_signal in /opt/jdk/lib/server/libjvm.so 3# 0x00007F448DB40400 in /lib64/libc.so.6 4# je_arena_dalloc_promoted at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/arena.c:1277 5# je_free_default at /root/selectdb-core/thirdparty/src/jemalloc-5.3.0/doris_build/../src/jemalloc.c:3014 6# __pthread_create_2_1 in /lib64/libpthread.so.0 7# os::create_thread(Thread*, os::ThreadType, unsigned long) in /opt/jdk/lib/server/libjvm.so 8# CompilerThread::CompilerThread(CompileQueue*, CompilerCounters*) in /opt/jdk/lib/server/libjvm.so 9# CompileBroker::make_thread(CompileBroker::ThreadType, _jobject*, CompileQueue*, AbstractCompiler*, JavaThread*) [clone .constprop.0] in /opt/jdk/lib/server/libjvm.so 10# CompileBroker::possibly_add_compiler_threads(JavaThread*) in /opt/jdk/lib/server/libjvm.so 11# CompileBroker::compiler_thread_loop() in /opt/jdk/lib/server/libjvm.so 12# JavaThread::thread_main_inner() in /opt/jdk/lib/server/libjvm.so 13# Thread::call_run() in /opt/jdk/lib/server/libjvm.so 14# thread_native_entry(Thread*) in /opt/jdk/lib/server/libjvm.so 15# start_thread in /lib64/libpthread.so.0 16# clone in /lib64/libc.so.6 ``` <!--Describe your changes.-->
Proposed changes
Load libjvm at runtime.
Problem summary
Currently, we build BE with Java UDF support by default. Unlike other dependencies which are linked with BE statically, we link BE and libjvm dynamically. As a result, we should set the environment variable
LD_LIBRARY_PATHbefore we start BE up, otherwise we will get an error (error while loading shared libraries). That is really inconvenient.The workaround is that we can load the libjvm at runtime.
Checklist(Required)
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...