-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[enhancement](java-udf) Support loading libjvm at runtime #13660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
TeamCity pipeline, clickbench performance test result: |
morningman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, cc @Gabriel39
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
|
TeamCity pipeline, clickbench performance test result: |
Gabriel39
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
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#2404 jemalloc/jemalloc#1321 jemalloc/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#2404 jemalloc/jemalloc#1321 jemalloc/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#2404 jemalloc/jemalloc#1321 jemalloc/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...