Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/331
The idea behind `MemoryUsageTracker. forceClearSoftReferences()` makes
sense, but feels a little scary! The code looks fine though. It will never be
enabled in production, only when profiling, so I'm happy to merge it.
The other additions to the regular output of `BrooklynGarbageCollection`
look sensible.
---
What about the removal of `MemoryUsageTracker.getBytesUsed()`? Should we
either delete that entirely, or leave it in the output of the
`BrooklynGarbageCollection`? It's useful to know how big the soft references
are (as long as we call it consistently enough).
It currently is a bit confusing having `MemoryUsageTracker.SOFT_REFERENCES`
and `MemoryUsageTracker.SoftUsageTracker` (which are unrelated to each other).
You're right to mark that as `@Beta`!
---
If investigating a memory leak, then `jmap -histo:live <pid>` and `jmap
-heap <pid>` will both include soft references. A subsequent analysis of the
output file from `jmap -dump:live,format=b,file=heap.bin <pid>` will allow you
to filter out the soft references, but that's fiddlier.
Looking at `jmap -histo:live` and manually excluding the stdout/stderr of
tasks (so streams / byte arrays) will give a good indication of all non-soft
references (but you may accidentally ignore things that are not
soft-references).
Much longer term, we should consider how best to store historic task
details (e.g. in riak) and a better deletion policy for them. But that is a
much bigger undertaking.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
