I'd support defaulting to off as well - this is a surprising find for me. On Dec 18, 2025, at 11:18 AM,
Evan Jones via dev <[email protected]> wrote: I finally got the time to set up a reproducible
test. I put a local variable cache for the thread name in SEPWorker.run, and it only has about ~50% hit
rate. It does reduce the cost, but not by as much as I would like. This still seems very expensive for
something that is looked at extremely rarely. I'm happy to submit a patch if someone thinks we should merge
it. It is a only a few lines of code, but in my opinion this doesn't really solve the problem completely.
Personally: I would advocate to defaulting this feature to off, since 1-4% of CPU across all Cassandra
clusters globally seems like a pretty big waste. I'm also happy to submit a patch for that if it would be
welcomed, but I also won't spend too much time advocating for that change. Any other ideas for how we might
be able to not call Thread.setName for every single task but still keep some of the benefit? Evan On Mon,
Dec 15, 2025 at 12:52 PM Evan Jones < [email protected] > wrote: 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.
