Thanks for your comments, David! I'll wait for further comments, if any,
from serviceability folk.
-- ramki
On Tue, Jul 25, 2017 at 11:15 PM, David Holmes
wrote:
> On 26/07/2017 2:02 PM, Srinivas Ramakrishna wrote:
>
>> Ah, Thanks Kris! I'll assume there was no real reaso
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'l
Hi Bengt, Tony, Thomas -- [+serviceability-dev (see below)]
Thanks for your (re)reviews, and Bengt, thanks also for shepherding the
changes into the open jdk code. Much appreciated!!
(I'm hoping you can take care of the two white-space modifications Thomas
suggested and push the changes.)
Thomas
I filed https://bugs.openjdk.java.net/browse/JDK-8087107 and attached a
patch to the ticket that exposes some useful code cache stats as perf data
counters:
$ jcmd PerfCounter.print | grep -i "sun\.ci\."
sun.ci.codeCacheCapacity=6291456
sun.ci.codeCacheMaxCapacity=6291456
sun.ci.codeCacheMethodsR
;
> 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 dela
f 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
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 tha
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
Looks good.
ysr1729
> On Apr 24, 2014, at 23:20, Staffan Larsen wrote:
>
> Can I get a Review for this, please?
>
> Thanks,
> /Staffan
>
>> On 8 apr 2014, at 14:07, Staffan Larsen wrote:
>>
>> This test verifies the origins of a couple of flags. One origin type is
>> ERGONOMIC. The test us
ug 21, 2013, at 1:53, Staffan Larsen wrote:
> We haven't seen this happen with CMS.
>
> /Staffan
>
> On 20 aug 2013, at 21:07, Srinivas Ramakrishna wrote:
>
>> Hi Staffan --
>>
>> Thanks for the explanation. I see. Can you check if you can replicate
(ResetPeakMemoryUsage.java:118)
> at ResetPeakMemoryUsage.main(ResetPeakMemoryUsage.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMet
Hi Shanliang --
That's curious.
If the array is unreachable, and you do a full gc (of the stop world
variety -- either serial/parallel, or CMS/G1 with
ExplicitGCInvokesConcurrent switched off) then the array should be
reclaimed and if free space book-keeping is correct, the memory usage
after sho
Yes, with G1 and CMS there isn't a guarantee that this is collected if
ExplicitGCInvokesConcurrent is enabled.
But the test seems to be run without the option... May be it should explicitly
turn off the option. In that case the size should definitely decrease by at
least the size of the object
may be it can't parse two email addresses. Probably expecting a single
email address in contributed by line?
-- ramki
On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi wrote:
> When I add
> yunda@taobao.com
> in following comment:
>
> 8005278: Serviceability Agent: jmap -heap and jstack -m fail
> S
used; see:-
http://openjdk.java.net/contribute/
-- ramki
On 7/27/2011 9:42 AM, Y. Srinivas Ramakrishna wrote:
Cross-posting to serviceability-dev list. Please include both lists
in your responses to this thread.
-- ramki
On 7/27/2011 9:12 AM, Krystal Mok wrote:
Hi all,
I've been lookin
Cross-posting to serviceability-dev list. Please include both lists
in your responses to this thread.
-- ramki
On 7/27/2011 9:12 AM, Krystal Mok wrote:
Hi all,
I've been looking at a strange inconsistency of full GC count recorded by
jvmstat and JMM counters. I'd like to know which ones of the
Hi Keith --
This is perfect! Thanks for all the consolidation and clean-up!
PS: i believe this should fix the recently noted nightly failure in G1
(probably new since G1 started doing weak reference processing recently! --
i had seen it earlier with CMS, but have not checked for the existence of
Keith, two points:
(1) the gc_end() here is incorrectly placed for concurrent full gc calls.
That's because the end may not yet have occurred. It occurs only in the
else arm where we post the notify on the lock.
That's the case when a concurrently called full gc has stood witness
I am not a language spec expert, so this opinion is offered merely as
more grist for the on-going discussion mill...
Jeremy Manson wrote:
Not that I actually have a vote, but if Alan feels it is not worth
making, I would go back to arguing for something like a
VirtualMachineError to be thrown, b
Hi Craig -- No, they are not enabled by default (even in 6.0),
so you'll need to explicitly enable +CMSClassUnloadingEnabled
to get the perm gen to be collected by CMS (as of
6.0 CMSPermGenSweepingEnabled became a no-op with a
suitable warning issued).
If you know the name of a specific JVM option
20 matches
Mail list logo
