PerfData counter: sun.gc.policy.generations in JDK 8
jon.masamitsu at oracle.com
Tue Jun 2 21:16:33 UTC 2015
Changes look good.
I'm guessing you tested by generating the
perfdata by hand and verifying the contents
of the perfdata. Do you think a test can
be written to verify the change? If you look at
in your repository I think that is an example that
can be followed.
It's a jtreg test.
On 06/01/2015 11:39 AM, Srinivas Ramakrishna wrote:
> Thanks for the review of the patch for 8-dev (from the ticket), Staffan.
> Sorry for the delay in getting the official webrev out -- it took me a
> while to first get set up with an hs9 repo (thanks Jon!) and then get
> my openjdk credentials updated (thanks Mark!).
> Here's the webrev against hs9 for official review:-
> I built and tested the change (on both 8-dev whose patch was attached
> with the original bug, as well as this with hs9) and verified that the
> counter value for generations, in the perfdata file, was now 2 instead
> of the previous 3.
> -- ramki
> On Mon, May 18, 2015 at 1:22 AM, Staffan Larsen
> <staffan.larsen at oracle.com <mailto:staffan.larsen at oracle.com>> wrote:
> Looks like a good patch to me.
>> On 14 maj 2015, at 18:12, Srinivas Ramakrishna <ysr1729 at gmail.com
>> <mailto:ysr1729 at gmail.com>> wrote:
>> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna
>> <ysr1729 at gmail.com <mailto:ysr1729 at gmail.com>> wrote:
>> With perm gen going away (and being replaced by metaspace) in
>> JDK 8, it makes sense that the counter
>> sun.gc.policy.generations should be "2", rather than "3".
>> However, in JDK 8 that counter still says 3.
>> As I understand, the intention was that this counter would
>> allow you to (for example) know the range of
>> the sun.gc.generation.$num.* counters describing each of $num
>> < sun.gc.policy.generations in the heap.
>> Recall that the erstwhile perm gen in JDK 7 used to be
>> synonymous with sun.gc.generation.2, but the
>> JDK 8 avatars are now sun.gc.metaspace and
>> The fix is simple, and I can submit a patch. Is there an
>> existing bug for this?
>> -- ramki
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the serviceability-dev