On Tue, 20 Oct 2026 23:52:47 GMT, Xin Liu <[email protected]> wrote: >> I can't rely on presence of last_java_frame, especially since I want to >> expand native frames support to other thread states in follow-up PRs. >> `CodeCache.contains` is the exact boundary; it's at most 3-4 range checks, >> negligible comparing to other stack walking costs. And Zero Interpreter is >> covered by an existing `last_java_sp` check. > > 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4332009433
