RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

[Kirk Pepperdine]

> On Jan 29, 2018, at 5:27 PM, Hohensee, Paul <hohensee at amazon.com> wrote:
> 
> A name change would affect Amazon’s heap monitoring, and thus I expect it would affect other users as well.

I can name a number of tools that would be disrupted by this type of change. Additionally tooling would be complicated by the need to support both the old and new versions. The current names have been with us for years and they are well known, well documented and well understood. Given the level of disruption this change is likely to cause IMHO you’d need a very very good reason to want to make it.
>  
> As long as there are gc-specific memory pools, we’re going to need to be able to identify them, and right now that’s done via name. All the mxbeans are identified by name, so that’s a general design principle. The only way I can think of to get rid of name dependency would be to figure out what abstract metrics users want to monitor and implement them for all collectors. HeapUsage (instantaneous occupancy) is one, CollectionUsage (long-lived occupancy) is another, both of these for the entire heap, not just particular memory pools. That said, imo there will always be a demand for the ability to get collector and memory pool specific details, so I don’t see a way to get around providing named entities.

Agreed…tuning strategies are implementation dependent and sensitive to specific versions. One is always going to need to know this information.

Kind regards,
Kirk Pepperdine

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180129/e04107eb/attachment.htm>