Fix unresolved sticky class GC roots

[wilx]

Fixes #6357.

ROOT_STICKY_CLASS records contain the HPROF object ID of the class object they keep alive. NetBeans already indexes CLASS_DUMP IDs in the heap object map and represents them as ClassDumpInstances, so resolvable sticky-class roots can participate in nearest-GC-root and retained-size traversal, including references held in static fields.

The remaining problem was in HprofGCRoots.getGCRoot(Long). When building its object-ID-to-root lookup, it unnecessarily resolved every root through GCRoot.getInstance() and then recovered the ID from the returned Instance. Some valid root records in the issue dump refer to loaded-class IDs for which the dump contains no corresponding resolvable heap object. getInstance() therefore returns null, and dereferencing it caused the reported NullPointerException.

This change builds the lookup directly from the target object ID stored in each HPROF GC-root record. Resolvable class-object roots continue to be seeded into reachability through the existing idToOffsetMap, so objects reachable only through their static fields remain reachable. Unresolved root records remain available from getGCRoots(), but no synthetic object or references are invented when the dump has no matching heap record.

The internal root collection is now typed as HprofGCRoot, making the raw target-ID invariant compile-time checked rather than relying on a runtime cast. No public API signatures change.

The synthetic HPROF test support now writes static object fields and either resolved or unresolved sticky-class root IDs. Regression coverage verifies both that:

• a sticky class resolves to a ClassDumpInstance, is found by GC-root lookup, and retains an object referenced only by a static field;
• an unresolved sticky-class root remains recorded and retained-size computation completes without an exception.

Validation performed:

• Reproduced the original failure path with the dump from issue NPE when parsing STICKY_CLASS tags in hprof heap dump #6357.
• Verified the issue dump contains 3,166 sticky-class roots: 2,882 resolve to heap class objects and 284 have no corresponding heap object.
• Verified getBiggestObjectsByRetainedSize(15) completes successfully on the issue dump.
• Ran HeapSegmentTest: 4 tests passed.
• Ran the complete profiler/lib.profiler unit suite with the module access required by its legacy CPU tests: 70 tests ran, 68 passed, and 2 failed.
• The two remaining failures are the existing testHeapDumpLog golden-file comparisons in HeapTest and HeapFromBufferTest; they contain the same JVM system properties in a different iteration order on this JDK and are unrelated to the GC-root change.

Assisted-by: OpenAI GPT-5 Codex

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

LLMs, Commit messages and PR description:

• Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.
• LLM assisted commits should be attributed with an Assisted-by: MODEL_NAME MODEL_VERSION line appended to the commit message.
  • Please mention coding assistance in the PR description too (eg. by adding the same Assisted-by line from above)
  • Please describe the changes in your own words - we'd like to know you understand the changes being made!

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[matthiasblaesing]

In general this makes sense to me. Thank you @wilx.

Is there a reason for two commits (other than to see the evolution of the patch?)? I'm not seeing it right now, so I'd suggest to squash the two commits.

[wilx]

In general this makes sense to me. Thank you @wilx.

Is there a reason for two commits (other than to see the evolution of the patch?)? I'm not seeing it right now, so I'd suggest to squash the two commits.

No. I started with just mitigating the NPE and then tried an actual fix.

[wilx]

Squashed.

[mbien]

not a showstopper but I noticed that the module isn't hooked into CI atm. We should consider to do that first (can be separate PR). We might have to check which tests run reliably and/or are worth running and setup the test config for the module - given that those didn't run in ages.