On Wed, 26 Aug 2026 05:55:38 GMT, Shiv Shah <[email protected]> wrote:
> The SA sizes a stack chunk like any fixed size instance, the layout helper > only covers the header part, so the region walk steps into the copied stack > data, fails to parse it as an object and gives up on the rest of the region. > whatever lives after the chunk never makes it into the dump, that is what the > hprof verification failures were. the fix reads the chunk’s own size field > and computes the footprint the same way the vm does, header plus stack plus > the gc bitmap words. the heap dump test comes off the virtual problem list > since it passes now. > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). These changes look good. Thanks for the fix! It looks like when hotspot dumps the heap, it also does not dump the stack array part of the StackChunk. It instead walks the heap looking for all VirtualThreads, and for each one found generates the appropriate hprof thread, stack, frame records. So this is the part that actually looks into the stack array of the StackChunk. This is missing from SA. We should file a CR for it. I just reread [JDK-8261848](https://bugs.openjdk.org/browse/JDK-8261848). It won't solve this problem, and fixing the heap dumping won't solve it either. It's separate issue from heap dumping, and it deals with "follow references" to discover all references to an object. The suggested fix would be a bit strange since the references will show up as rooted in the StackChunk, when really they should show up as rooted in a local variable of a virtual thread stack frame (like they would if analyzing a heap dump). I think it would take a lot to make that happen, and in general I don't think this is an important enough feature to merit putting that much work into. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/32525#pullrequestreview-5035043232 PR Comment: https://git.openjdk.org/jdk/pull/32525#issuecomment-5431061603
