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

[Hohensee, Paul]

A name change would affect Amazon’s heap monitoring, and thus I expect it would affect other users as well.

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.

Paul

From: mandy chung <mandy.chung at oracle.com>
Organization: Oracle Corporation
Date: Friday, January 26, 2018 at 2:38 PM
To: "Hohensee, Paul" <hohensee at amazon.com>, Erik Helin <erik.helin at oracle.com>, David Holmes <david.holmes at oracle.com>
Cc: "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>, "hotspot-gc-dev at openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>
Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results


On 1/25/18 1:04 PM, Hohensee, Paul wrote:

> The JMX API spec doesn’t specify what the memory pool or garbage > collector names are, but the current names are de-facto part of the > API, so if we change the existing ones, imo a CSR should be filed.

The names are implementation details but I can see how an application

might be impacted if they depend on it.  CSR approval is not strictly

necessary while I think filing one to document the change would be

good.


Does the name change impact any application you know of?  I'm trying to

understand if any improvement to API is needed so that applications

don't need to depend on the names.

Mandy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180129/b7162d70/attachment.html>