On Wed, 21 Oct 2026 01:11:00 GMT, Andrei Pangin <[email protected]> wrote:
>> hi, @apangin >> >> I understand we want to pursuit more states. One lesson I learned from ASGCT >> is that it is unsafe if we build things based on the status-quo code rather >> than a program invariant. Code changes over time. >> >> I have two arguments why we should consider a native stackwalker using the >> following invariant: >> >> >> jt->has_last_Java_frame() && jt->frame_anchor()->walkable() >> >> >> 1. be conservative. Drop those corner cases like JvmtiAgentThread, a java >> thread has zero java call yet, in_Java (I don't think check in_Native before >> is enough, we need to deploy a Dekker test). >> >> 2. Cooperate with the existing stack-walker. Sometimes we also want to >> stitch the native part with the second part at safepoint. LFJ is a >> reasonable joint point. >> >> If we use LJF invariant, it will work for a mature Java thread that just >> steps out of _in_Java and be in a stable _in_Native or _in_VM or >> _in_blocked. I think will meet most of demand and it's significant safer. >> >> If we support a java thread just in transitional state, eg. it's >> constructing an anchor. We may see some weird interim frame like >> `JavaFrameAnchor::copy` or `UpcallLinker::on_entry`, there will be mismatch >> when we generate stacktrace at the next safepoint. Even you manage to >> generate native stacktrace for a java thread without LJF, it's not easy >> stitch them. > > This does not sound convincing to me, sorry. How will we benefit from > discarding 100% valid cases of threads with no Java frames and blocking > future enhancements? Or do you know specific correctness issues with the > current approach? No, I don't have correctness issue in particular. It's just suggestion, not blocking. I am trying to stitch what you captured in this PR with the stack-trace in post-processing. One scenario is that 'JfrCPUSamplerThread::stackwalk_threads_in_native' steals requests from JavaThread. In line 414, JFR only generates the 2nd part if jt->has_last_Java_frame(). Maybe your scenarios are broader than mine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4340481000
