Re: PerfData counter: sun.gc.policy.generations in JDK 8

2016-04-29 Thread Srinivas Ramakrishna
Sorry this fell off my plate. I'll dig up the test Jon pointed me to and
see how i can write one for this, then update the old webrev. I'll try and
get that done in the next few days.

thanks for the reminder! \
-- ramki


On Fri, Apr 15, 2016 at 6:43 AM, Stefan Karlsson  wrote:

> Hi Ramki and Jon,
>
> What's the status of this review thread? The bug is still open and
> targeted for JDK 9.
>
> Thanks,
> StefanK
>
>
> On 2015-06-03 08:15, Srinivas Ramakrishna wrote:
>
> Thanks Jon for the review and the pointer to the test. I'll get back to
> you later this week with a suitable test.
>
> -- Ramki
>
> ysr1729
>
> On Jun 2, 2015, at 14:16, Jon Masamitsu < 
> jon.masami...@oracle.com> wrote:
>
> Ramki,
>
> 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
>
> test/gc/metaspace/TestMetaspacePerfCounters.java
>
> in your repository I think that is an example that
> can be followed.
>
> It's a jtreg test.
>
> http://openjdk.java.net/jtreg/
>
> Jon
>
> 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:-
>
> 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.lar...@oracle.com> wrote:
>
>> Looks like a good patch to me.
>>
>> /Staffan
>>
>> On 14 maj 2015, at 18:12, Srinivas Ramakrishna < 
>> ysr1...@gmail.com> wrote:
>>
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8080345
>>
>>
>>
>> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna <
>> ysr1...@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
>>>
>>
>>
>>
>
>
>


Re: PerfData counter: sun.gc.policy.generations in JDK 8

2016-04-15 Thread Stefan Karlsson

Hi Ramki and Jon,

What's the status of this review thread? The bug is still open and 
targeted for JDK 9.


Thanks,
StefanK

On 2015-06-03 08:15, Srinivas Ramakrishna wrote:
Thanks Jon for the review and the pointer to the test. I'll get back 
to you later this week with a suitable test.


-- Ramki

ysr1729

On Jun 2, 2015, at 14:16, Jon Masamitsu > wrote:



Ramki,

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

test/gc/metaspace/TestMetaspacePerfCounters.java

in your repository I think that is an example that
can be followed.

It's a jtreg test.

http://openjdk.java.net/jtreg/

Jon

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:-

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 
mailto:staffan.lar...@oracle.com>> wrote:


Looks like a good patch to me.

/Staffan


On 14 maj 2015, at 18:12, Srinivas Ramakrishna
mailto:ysr1...@gmail.com>> wrote:

https://bugs.openjdk.java.net/browse/JDK-8080345



On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna
mailto:ysr1...@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











Re: PerfData counter: sun.gc.policy.generations in JDK 8

2015-06-02 Thread Srinivas Ramakrishna
Thanks Jon for the review and the pointer to the test. I'll get back to you 
later this week with a suitable test.

-- Ramki

ysr1729

> On Jun 2, 2015, at 14:16, Jon Masamitsu  wrote:
> 
> Ramki,
> 
> 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
> 
> test/gc/metaspace/TestMetaspacePerfCounters.java
> 
> in your repository I think that is an example that 
> can be followed.
> 
> It's a jtreg test.
> 
> http://openjdk.java.net/jtreg/
> 
> Jon
> 
>> 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:-
>> 
>> 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  
>> wrote:
>>> Looks like a good patch to me.
>>> 
>>> /Staffan
>>> 
 On 14 maj 2015, at 18:12, Srinivas Ramakrishna  wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080345
 
 
 
> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna  
> 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
> 


Re: PerfData counter: sun.gc.policy.generations in JDK 8

2015-06-02 Thread Jon Masamitsu

Ramki,

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

test/gc/metaspace/TestMetaspacePerfCounters.java

in your repository I think that is an example that
can be followed.

It's a jtreg test.

http://openjdk.java.net/jtreg/

Jon

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:-

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 
mailto:staffan.lar...@oracle.com>> wrote:


Looks like a good patch to me.

/Staffan


On 14 maj 2015, at 18:12, Srinivas Ramakrishna mailto:ysr1...@gmail.com>> wrote:

https://bugs.openjdk.java.net/browse/JDK-8080345



On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna
mailto:ysr1...@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









Re: PerfData counter: sun.gc.policy.generations in JDK 8

2015-06-01 Thread Srinivas Ramakrishna
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 
wrote:

> Looks like a good patch to me.
>
> /Staffan
>
> On 14 maj 2015, at 18:12, Srinivas Ramakrishna  wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8080345
>
>
>
> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna 
> 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
>>
>
>
>


Internal - RE: PerfData counter: sun.gc.policy.generations in JDK 8

2015-05-20 Thread Mattis Castegren
Hi

 

How do we usually handle these bugs where we have an external patch to take in, 
should someone from Dev take ownership of the bug? And should we fix this in 
8u60?

 

Kind Regards

/Mattis

 

From: Staffan Larsen 
Sent: den 18 maj 2015 10:23
To: Srinivas Ramakrishna
Cc: serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net; 
hotspot-gc-...@openjdk.java.net
Subject: Re: PerfData counter: sun.gc.policy.generations in JDK 8

 

Looks like a good patch to me.

 

/Staffan

 

On 14 maj 2015, at 18:12, Srinivas Ramakrishna mailto:ysr1...@gmail.com"ysr1...@gmail.com> wrote:

 

https://bugs.openjdk.java.net/browse/JDK-8080345

 

 

 

On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna mailto:ysr1...@gmail.com"; \nysr1...@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

 

 


Re: PerfData counter: sun.gc.policy.generations in JDK 8

2015-05-18 Thread Staffan Larsen
Looks like a good patch to me.

/Staffan

> On 14 maj 2015, at 18:12, Srinivas Ramakrishna  wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8080345 
> 
> 
> 
> 
> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna  > 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
> 



Re: PerfData counter: sun.gc.policy.generations in JDK 8

2015-05-14 Thread Srinivas Ramakrishna
https://bugs.openjdk.java.net/browse/JDK-8080345



On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna 
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
>


PerfData counter: sun.gc.policy.generations in JDK 8

2015-05-13 Thread Srinivas Ramakrishna
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