PerfData counter: sun.gc.policy.generations in JDK 8
Srinivas Ramakrishna
ysr1729 at gmail.com
Mon Jun 1 18:39:51 UTC 2015
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:-
http://cr.openjdk.java.net/~ysr/JDK-8080345/webrev.00/
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.
thanks!
-- ramki
On Mon, May 18, 2015 at 1:22 AM, Staffan Larsen <staffan.larsen at oracle.com>
wrote:
> Looks like a good patch to me.
>
> /Staffan
>
> On 14 maj 2015, at 18:12, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8080345
>
>
>
> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna <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 sun.gc.compressedclassspace.
>>
>> The fix is simple, and I can submit a patch. Is there an existing bug for
>> this?
>>
>> thanks!
>> -- ramki
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150601/c286efa9/attachment.html>
More information about the serviceability-dev
mailing list