RFR: 8357829: Commented out sample limit in JfrSamplerThread::task_stacktrace

[Markus Grönlund]

On Tue, 27 May 2025 16:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Its because of the Threads_lock.
> 
> OK, I understand it is pre-[JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), but I gotta ask. Are we talking about this one?
> 
> https://github.com/openjdk/jdk/blob/c29537740efb04e061732a700582d43b1956cff4/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L231-L232
> 
> Do you actually need that lock? I would have thought `ThreadListHandle` blocks anything bad to happen with the threads in the list until you release that iterator. This is the whole thing about Thread SMR to allow this kind of safe thread handling without taking extra locks. Maybe I don't see some other code lurking somewhere that wants it, e.g. thread states?
> 
> Since TLH is supposed to guard the thread list stability by itself, maybe we can move that lock acquisition within the thread-walking loop, so that we don't hoard the lock for sampling _all_ threads, just do it one by one...

It's not needed because of TLH - it's required to not sample through safepoints, which cannot be handled gracefully by some GCs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913265687