Re: [mat-dev] Stack Frames as Pseudo-Objects

[Andrew Johnson <andrew_johnson@xxxxxxxxxx>]

This mode normally works well and it is nice to see the stack frames directly in a path to GC roots etc. I think the leak suspects report works better but needs more testing.

 

One concern is the complex pseudo-types and how to explain them:

Superclass / Class        | Objects | Shallow Heap | Retained Heap

-------------------------------------------------------------------

<native memory>           |      82 |          824 |             

|- <method>               |      40 |          520 |             

'- <native memory type>   |      42 |          304 |              

   |- <method type>       |      39 |          304 |        >= 304

   '- <native memory type>|       3 |            0 |             

-------------------------------------------------------------------

 

Another thing that didn’t work was parsing a dump as one of the Stack frames as pseudo-objects options, then running ExportHPROF and exporting everything. This would export the stack frames as real HPROF objects, and the native memory types as real classes, losing some of the pseudo-types’ hierarchy. This would sort of work if reparsed without Stack frames as pseudo-objects, but wouldn’t be quite the same as the original snapshot. It fails if reparsed as one of the Stack frames as pseudo-objects as there are duplicate definitions of stack frames. Perhaps ExportHPROF should not export these pseudo-objects and classes by default. Redaction also caused some problems. There are a few tests in GeneralSnapshotTests.java which are ignored because of these problems.

 

The size of a stack frames is a guess with HPROF – but the sizes are small enough not to disturb most memory usage calculations.

 

Andrew Johnson

 

 

From: mat-dev <mat-dev-bounces@xxxxxxxxxxx> On Behalf Of Kevin Grigorenko
Sent: 09 May 2023 19:36
To: Memory Analyzer Dev list <mat-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [mat-dev] Stack Frames as Pseudo-Objects

Hey Andrew, This is really nice, thanks. Have you considered making the default, "Stack frames as pseudo-objects and running methods as pseudo-classes" ? Is there any downside?

 

-- 

Kevin Grigorenko

IBM App Runtimes SWAT, Software Engineer

 

From: mat-dev <mat-dev-bounces@xxxxxxxxxxx> on behalf of Andrew Johnson
Date: Wednesday, March 22, 2023 at 4:21 AM
To: mat-dev@xxxxxxxxxxx <mat-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [mat-dev] Stack Frames as Pseudo-Objects

I have delivered the first part of an enhancement for https://bugs.eclipse.org/bugs/show_bug.cgi?id=581644 - Allow stack frames as pseudo-objects for HPROF snapshots

The HPROF parser now has an option to create pseudo-objects for the stack frames. The stack frames can then appear in paths to GC roots etc. as the thread has references to the stack frames and the stack frame has references to its local variables.
The type of the pseudo-object can be '<stack frame>' and a few extra types are created to avoid disturbing the normal object hierarchy. In another mode, we group the stack frames by type based on the method that is being executed for that frame. From the histogram you can then quickly see which methods are being executed across the whole snapshot. These options have existed for DTFJ since 2011, and this bug gives the HPROF equivalent.

There are more details in the bug - please comment there or here if you want more visibility.

Andrew Johnson

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU