On Mon, 19 Oct 2026 22:51:18 GMT, Xin Liu <[email protected]> wrote: >> Andrei Pangin has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains two additional >> commits since the last revision: >> >> - Re-implemented native frames support using variable-size requests >> - 8392187: JFR: Use-after-free bug in CPU-time profiler can crash JVM > > src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 614: > >> 612: while (count < JfrCPUTimeSampleRequest::MAX_NATIVE_FRAMES) { >> 613: const address pc = f.pc(); >> 614: if (pc == nullptr || CodeCache::contains(pc)) { > > I think the cheap check should be LJF(last java frame). Until we encounter > the LJF, everything are native frames. jt->_anchor is the invariant provided > by hotspot. > > for pc check about here: > 2. if pc is from interpreter but JVM is not using template interpreter(a > corner case), pc is NOT in code cache! However, ucontext points to a java > frame, not native frame. > 3. Isn't CodeCache.contains() expensive? if we have multiple heaps in > CodeCache.
As I pointed in my previous comment, we can't rely on presence of last_java_frame. `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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4320834702
