Re: [mat-dev] Clear only-softly-retained objects by default?

["Kevin Grigorenko" <kevin.grigorenko@xxxxxxxxxx>]

Hey Andrew,

> A possible
idea, presumably clearing weak references etc

One potential
problem I thought of is that an only-softly-reachable object with an
associated ReferenceQueue
may still require reference queue processing before
being cleaned
up, so we may want to exclude such objects. It's unclear what the
semantics are
if the SoftReference referent has a finalize method. WeakReference
is more explicit
that an only weakly reachable object will be declared finalizable.
So we might want
to only perform this clean up for objects without a finalize
method.

> There isn't
really a concept of 
> soft reference
in the snapshot API, so changing it there is pushing down 
> implementation
specifics.

Interesting, ok,
that does complicate this.

> If you really
wanted to just operate on those 182530 objects you could 
> select those
objects and do an Export Snapshot to export it as a new HPROF 
file. That works,
even if the original is DTFJ, though when you reparse 
the dump you won't
get the DTFJ specific information.

--
Kevin Grigorenko
IBM App Platform SWAT




From:
       Andrew
Johnson <andrew_johnson@xxxxxxxxxx>
To:
       Memory
Analyzer Dev list <mat-dev@xxxxxxxxxxx>
Date:
       04/29/2021
04:08 AM
Subject:
       [EXTERNAL]
Re: [mat-dev] Clear only-softly-retained objects by default?
Sent
by:        "mat-dev"
<mat-dev-bounces@xxxxxxxxxxx>

---

> An interesting idea came up
of clearing only softly-retained objects
> by default when parsing a dump in the same way that MAT clears 
> unreachable objects by default, and having a similar preference of
> "Keep only-softly-retained objects". Thoughts? I have seen
this 
> issue cause confusion for a customer at least one time before.
> 
> --
> Kevin Grigorenko
A possible idea, presumably clearing weak references etc. also. In terms
of phases - the garbage collection is done in org.eclipse.mat.parser which
has little knowledge of soft references. There isn't really a concept of
soft reference in the snapshot API, so changing it there is pushing down
implementation specifics.

Soft references are handled by code in org.eclipse.mat.api, such as: 
References Statistics
Path to GC Roots
Merge Shortest Path to GC Root
Component Report
Customized Retained Set

I think we need to explain some of these more. To find objects which are
all strongly retained, you might think the customized retained set would
help. Actually that serves a different purpose:

"The custom retained set comprises all objects included in the normal
retained set. Additionally, it adds objects which are (a) reachable from
the root set and (b) would be garbage collected if the references defined
by the excludes would not exist.
In terms of set operations, one could put it this way: the customized 
retained set contains all objects which are unreachable if all references
to the root set and all references defined by the excludes are removed.
From the resulting set, the objects of the retained set derived only 
through the excludes are removed."

I've only just worked out how to find the set of objects which are 
retained without soft references:

merge_shortest_paths  .*  -excludes java.lang.ref.SoftReference:referent
-groupby FROM_OBJECTS_BY_CLASS

In a sample dump with 187950 objects this gives 182530 objects.
The only softly retained report gives 5420 objects, so that matches.

If you really wanted to just operate on those 182530 objects you could
select those objects and do an Export Snapshot to export it as a new HPROF
file. That works, even if the original is DTFJ, though when you reparse
the dump you won't get the DTFJ specific information.

I think we should check that the reports are giving directly useful 
information - everyone runs Leak Suspects, but who runs Top Components?
Should the empty collections report say exactly how many bytes would be
saved if the empty collections were replaced by null references, and 
created when needed. Should the low fill ratio collections say how many
bytes would be saved if they were trimmed to size? Are there more queries
that are useful, such as: length 0 arrays (replace by global singleton,
or 
allocation on need?); length 1 - if always one and not modifier, replace
by direct reference; duplicate objects by shallow comparison.

Are users finding all the capabilities they need? Are they reading the
help? Are they clicking on help links? Would having 'Tip of the Day' help?
Is Leak Suspects report understandable? Do we need help links inside the
report? If there are steps we can suggest then either automate them, or
consider longer cheat sheets with choices about where to go next.

--
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