Hmm I spent a bit of time and can't get the symbols for libc to match. I think for the version of the JVM we are using (17), the JVM calls pthread_setname_np [1], which then calls glibc's prctl() [2], which then makes the system call, so I *think* those are the stacks we are seeing. Newer JVMs just call prctl() directly which might be slightly more efficient.
For what it is worth: I got some of Datadog's JVM experts interested in this, and we have a tentative JVM patch that makes setName slightly faster (about ~25% in a microbenchmark) [3]. I am also going to investigate your idea of renaming on change. I suspect that will make it substantially better, but I need to find some time to put together a somewhat controlled test to try to "measure" the improvement. Thanks everyone for the responses! Evan Jones [1] https://github.com/openjdk/jdk17u-dev/blob/master/src/hotspot/os/linux/os_linux.cpp#L4892 [2] https://github.com/bminor/glibc/blob/f56382e67e73c0b309c7e39c6b122b04b29b6808/nptl/pthread_setname.c#L43C12-L43C19 [3] https://github.com/openjdk/jdk/pull/28773 On Wed, Dec 10, 2025 at 6:45 PM Abe Ratnofsky <[email protected]> wrote: > I’ve seen slightly different issues with Thread.setNativeName in profiles, > but thread names in logs + JFR are very helpful and I wouldn’t want to lose > those. AFAIK, the JDK doesn't currently offer a way to set a > java.lang.Thread name without updating the platform thread name. > > Evan - are you able to use a version of libc with debug symbols, so the > “Unknown Function” calls in your profile can be resolved? I’m assuming > they’re the copying + re-encoding steps here[1]. > > [1]: > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L4823-L4827 > > We could potentially improve this by interning the current thread name in > SEPWorker, and only renaming when we need to change. Then we’d have a > reference comparison instead of a syscall, at least some of the time. >
