Re: [mat-dev] Viewing Discarded Objects

[Andrew Johnson <andrew_johnson@xxxxxxxxxx>]

Yes, it does involve
more GC, but only for non-indexed objects as my general code pattern is
to use mapAddressToId, then only if that throws an exception then use ObjectReference.
That path will be more expensive, especially with the exception. There
is also currently no caching at the SnapshotImpl level whereas SnapshotImpl.getObject()
does have a cache. Loading the object from the HPROF parser will be more
expensive as it has to parse from the preceding indexed object, but the
file accesses are cached.

The object marker
code does use ObjectReferences, but only for the excluded fields code.
It has a source and destination object ID, then finds all the named references
from the source and sees whether the address of the reference matches the
destination. It doesn't inflate the ObjectReference into an IObject.

I'm hoping this
won't affect the normal code path where all objects are indexed. If it
is useful in the discarded objects case then we can tune the performance.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=473113#c23
https://bugs.eclipse.org/bugs/attachment.cgi?id=286443

Andrew



From:
       Kevin
Grigorenko
To:
       Memory
Analyzer Dev list <mat-dev@xxxxxxxxxxx>
Date:
       24/05/2021
15:42
Subject:
       [EXTERNAL]
Re: [mat-dev] Viewing Discarded Objects
Sent
by:        "mat-dev"
<mat-dev-bounces@xxxxxxxxxxx>

---

Hey Andrew,
My only concern is whether this will drive a lot more object creation and
garbage collection with the ObjectReference instances and whether that
will impact performance much? 

--
Kevin Grigorenko
IBM App Platform SWAT




From:        Andrew
Johnson
To:        "Memory
list" <mat-dev@xxxxxxxxxxx>
Date:        05/21/2021
12:02 PM 
Subject:        [mat-dev]
Viewing Discarded Objects 
Sent by:        "mat-dev"
<mat-dev-bounces@xxxxxxxxxxx>

---

Memory
Analyzer has the facility to copy with huge heaps (>2^31 objects) or
more than the heap can manage by discarding objects.

This can be useful, does reduce the number of objects, but the object graph
is modified, and even if the leak can be spotted it is harder to understand
because some of the strings giving names of objects might have been discarded.

I have a work-around for the latter problem. Generally MAT using an int
index to represent an object. However, once you have an IObject you can
find its address. You can read fields (and array entries using "[13]"
etc.) and call getOutboundReferences(). These return a ObjectReference
object, which could represent an unindexed (discarded) object as it holds
the object ID, the address and the snapshot.

I didn't want to change the API as this is still experimental. There isn't
a way of getting unindexed objects by address from directly from a snapshot,
or from a parser via IHeapObjectReader

Currently 
int objectId
= snapshot.mapAddressToId(address);
IObject object = snapshot.getObject(objectId);

instead I suggest the following: 

ObjectReference ref = new ObjectReference(snapshot,
address); 
IObject object = ref.getObject() 

I also wanted the inspector view to show unindexed objects and fields of
those objects and to be able to inspect those fields and go into them.
I also wanted some support for OQL.

To get this to work I need a way for the parser to construct this new object.
https://help.eclipse.org/2021-03/topic/org.eclipse.mat.ui.help/doc/org/eclipse/mat/parser/IObjectReader.html

void	close() tidy up when snapshot no longer required
<A> A	getAddon(Class<A> addon) Get additional information about the snapshot
void	open(ISnapshot snapshot) Open the dump file associated with the snapshot
IObject	read(int objectId, ISnapshot snapshot) Get detailed information about an object
long[]	readObjectArrayContent(ObjectArrayImpl array, int offset, int length) Get detailed information about a object array
Object	readPrimitiveArrayContent(PrimitiveArrayImpl array, int offset, int length) Get detailed information about a primitive array

To construct this object my idea is that the parser needs to provide a getAddon for ObjectReference, returning a parser specific version. The parser can then override getObject and retrieve an object at the address which has been inserted into the object. So the base ObjectReference tries to get the object ID and call snapshot.getObject(). If there is no object ID, then it constructs a proxy ObjectReference from the parser, inserts the required object address, and lets the parser return the object.

I have made the changes - but there is still some time to improve or revert them so give it a try with snapshots with discarded objects.

--

Andrew Johnson

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mat-dev

_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mat-dev



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU