Here there is a patch with both changes: https://github.com/apache/cassandra/compare/trunk...netudima:cassandra:sep_thread_name-trunk?expand=1
>> but thread names in logs + JFR are very helpful and I wouldn’t want to lose those. I have not had a time to validate it but I suspect that profilers do not capture thread names for every trace/sample to avoid performance overheads and only use thread ids, names are captured only on creation or periodically and then linked (I would do it in this way). If it is true then having a changing name for a thread can be not helpful but even misleading during a profile analysis... Regarding logs, do we have an example when a SEP thread name gave some new information? (we have an id in the thread name even without this renaming feature to be able to differentiate them, a phase such as Read/Write/Response/NativeTransport usually is clear from the log message itself..) On Thu, 18 Dec 2025 at 19:32, C. Scott Andreas <[email protected]> wrote: > 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. >>> >> > -- Dmitry Konstantinov
