Serialize stale jmethodID frames as <unloaded> instead of jvmtiError

[jbachorik]

What does this PR do?:
Remaps the dump-time JVMTI-resolution failure branch in Lookup::fillJavaMethodInfo (flightRecorder.cpp) to serialize the frame as <unloaded> instead of the synthetic jvmtiError method name. Removes the now-dead jvmtiError assertions from SmokeCpuTest, SmokeWallTest, CTimerSamplerTest, and RemoteSymbolicationTest.

Motivation:
Profiles in hotdog (non-remotesym) showed all leaf frames serialized as jvmtiError during the early class-churn window (~first 10-15 min), a regression vs v1.49.0.

Root cause is JDK-8268406 "Deallocate jmethodID native memory" (integrated in JDK 26, build b05): jmethodID memory is now freed on class unload (pre-26 it was kept alive — the leak this change fixed). The profiler's stale-jmethodID detection relies on dereferencing the jmethodID to verify it still points to the right Method*:

• VMMethod::check_jmethodID_hotspot (vmStructs.cpp): if (hotspot_version() > 25) return true; — unconditional, no validation.
• _can_dereference_jmethod_id = _has_method_structs && hotspot_version() <= 25 (vmStructs.cpp): validatedId() skips the deref.

Both are disabled for JDK > 25 because the deref no longer aliases a kept-alive JNIMethodBlock — it would fault on freed memory. So a stale jmethodID from an unloaded/purged class passes all capture-time gates, reaches fillJavaMethodInfo at dump time, GetMethodDeclaringClass returns JVMTI_ERROR_INVALID_METHODID, and the frame was serialized as jvmtiError.

Per the JVMTI spec, retransform does not invalidate jmethodIDs (the original ID is repurposed to the new method version). What invalidates them is class unload — and JDK-8268406 changed what "invalidated" means at the memory level. The early-run correlation is class churn (generated accessors, lambda forms, Mockito-generated classes, retransform obsolete-method purge via the JDK-8313816 path) which settles after warmup.

<unloaded> is the correct, safe label: the method was present at sample time, its metadata was reclaimed before the JFR dump. It matches the existing angle-bracket synthetic-frame convention (<remote>, <vtable_receiver>, <unresolved_vtable_receiver>). The capture-time unknown path (JMETHODID_NOT_WALKABLE / null jmethodID) stays distinct, so the two failure modes remain distinguishable in profiles:

• unknown — capture-time validation failure (walker couldn't trust the ID).
• <unloaded> — dump-time resolution failure (ID was valid at capture, metadata reclaimed by dump).

Additional Notes:

• The deref-based stale check is unrevivable on JDK ≥ 26 (the jmethodID memory is freed), so this remap is the right fix, not a stopgap. Retaining the raw Method* (the alternative) is crash-prone on class unload and reverts Avoid retaining invalid VM method pointers #699's safety work; on JDK 26 the Method* is freed too.
• The jvmtiError label is no longer emitted by any code path, so the per-test assertions against it were dead checks that could never fail — removed rather than kept as sentinels.

How to test the change?:
SmokeCpuTest + 391 gtests pass (0 failures) on Corretto 26. A reproducing test that forces a class unload during profiling to lock in the <unloaded> behavior can be added as a follow-up.

For Datadog employees:

• This PR doesn't touch any of that.
• JIRA: (none)

[dd-octo-sts]

Scan-Build Report

User:	runner@runnervmzvulz
Working Directory:	/home/runner/work/java-profiler/java-profiler/ddprof-lib/src/test/make
Command Line:	make -j4 all
Clang Version:	Ubuntu clang version 18.1.3 (1ubuntu1)
Date:	Thu Aug 20 09:14:41 2026

Bug Summary

Bug Type	Quantity	Display?
All Bugs	1
Logic error
Dereference of null pointer	1

Reports

Bug Group	Bug Type ▾	File	Function/Method	Line	Path Length
Logic error	Dereference of null pointer	profiler.h	findLibraryByAddress	523	28

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a3bacdea1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dd-octo-sts]

✅ All 40 integration tests passed

📊 Dashboard · 👷 Pipeline · 📦 54a8d9de

[dd-octo-sts]

CI Test Results

Run: #32352690944 | Commit: db51a29 | Duration: 14m 44s (longest job)

✅ All 32 test jobs passed

Status Overview

JDK	glibc-aarch64/debug	glibc-amd64/debug	musl-aarch64/debug	musl-amd64/debug
8	-	✅	-	-
8-ibm	-	✅	-	-
8-j9	✅	✅	-	-
8-librca	-	-	✅	✅
8-orcl	-	✅	-	-
11	-	✅	-	-
11-j9	✅	✅	-	-
11-librca	-	-	✅	✅
17	✅	✅	-	-
17-graal	✅	✅	-	-
17-j9	✅	✅	-	-
17-librca	-	-	✅	✅
21	✅	✅	-	-
21-graal	✅	✅	-	-
21-librca	-	-	✅	✅
25	✅	✅	-	-
25-graal	✅	✅	-	-
25-librca	-	-	✅	✅

Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled

Summary: Total: 32 | Passed: 32 | Failed: 0

---

Updated: 2026-08-20 09:29:51 UTC

[zhengyu123]

LGTM