On Tue, 6 Jan 2026 09:47:21 GMT, Yasumasa Suenaga <[email protected]> wrote:
> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it > does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked > object on thread stack. > > I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap > dumps were created following options: > > > -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError > > > <img width="801" height="127" alt="heapdumponoutofmemoryerror" > src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463"; > /> > > This image shows "thread overview" from the heapdump by > `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained > heap. > > <img width="825" height="87" alt="from-core" > src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238"; > /> > > On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not > report it - leaked object is reported as unreachable objects. > > heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java > frames. SA should do that. > > Essensially, we need to apply the fix in > https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 > , however it fails with exception due to access `oop` in out of range. We > need to fix the number of objects in expression stack like HotSpot. I fixed > it in > https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df > . And also I saw error relates to `invokedynamic` because ConstantPool in SA > has not followed curre t HotSpot implementation. So I fixed it in > https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d > . > > This change works fine with both interpreter and `-Xcomp`. @YaSuenag Can you please add/update jtreg test for this fix or explain in the bug/PR why it is not added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3717371564
