hotspot-gc-dev Digest, Vol 34, Issue 13

[Ciciora, Paul]

For what its worth there is a -XX to initiate only on Occupancy fraction. I want to say its CMSInitiatingOccupancyOnly. 

----- Original Message -----
From: hotspot-gc-dev-bounces at openjdk.java.net <hotspot-gc-dev-bounces at openjdk.java.net>
To: hotspot-gc-dev at openjdk.java.net <hotspot-gc-dev at openjdk.java.net>
Sent: Thu Apr 15 14:00:04 2010
Subject: hotspot-gc-dev Digest, Vol 34, Issue 13

Send hotspot-gc-dev mailing list submissions to
	hotspot-gc-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev
or, via email, send a message with subject or body 'help' to
	hotspot-gc-dev-request at openjdk.java.net

You can reach the person managing the list at
	hotspot-gc-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hotspot-gc-dev digest..."


Today's Topics:

   1. Re: Avoiding 1 long CMS with a big heap (Jon Masamitsu)
   2. Re: Avoiding 1 long CMS with a big heap (Matt Khan)


----------------------------------------------------------------------

Message: 1
Date: Wed, 14 Apr 2010 14:58:18 -0700
From: Jon Masamitsu <jon.masamitsu at oracle.com>
Subject: Re: Avoiding 1 long CMS with a big heap
To: Matt Khan <matt.khan at db.com>
Cc: hotspot-gc-use at openjdk.java.net
Message-ID: <4BC63A7A.8010908 at oracle.com>
Content-Type: text/plain; charset="iso-8859-1"

On 04/14/10 14:15, Matt Khan wrote:
> .
...

>
>
> I still don't understand *why* the 2nd initial mark happened. I 
> thought CMS was only triggered once the occupation passed the 
> threshold (IIRC this is 50% by default), since occupation was actually 
> more like 10% or so then why did it even feel the need to do anything 
> at all?
>

CMS tries to project how early to start a cycle based on past
behavior.  When there hasn't been much data gathered about
collections, the projection can just be wrong.

> >> If you add -XX:+CMSScavengeBeforeRemark it will schedule a ParNew 
> collection before the remark.
> slightly naive Q.... why isn't this default behaviour? is it because a 
> "normal" heap has a bigger tenured than eden hence the cost isn't 
> skewed in the way I have it configured?

That would put a young gen collection and a remark back-to-back and users
see it as a single longer pause.  We work to keep space between those two
pauses.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/dd4d0116/attachment-0001.html 
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

------------------------------

Message: 2
Date: Wed, 14 Apr 2010 23:31:29 +0100
From: Matt Khan <matt.khan at db.com>
Subject: Re: Avoiding 1 long CMS with a big heap
To: jon.masamitsu at oracle.com
Cc: hotspot-gc-use at openjdk.java.net
Message-ID:
	<OFC6DFCA4B.8B1DCF24-ON80257705.007B2DF6-80257705.007BBBC2 at db.com>
Content-Type: text/plain; charset="us-ascii"

>> CMS tries to project how early to start a cycle based on past behavior. 
 When there hasn't been much data gathered about collections, the 
projection can just be wrong.
OK so it seems to be Q of how can I mitigate this risk, i.e. is there 
anything I can do to influence this behaviour such that the probability of 
such an incorrect call, by the collector, is reduced? 

Obviously ideally it would be possible to eliminate the risk full stop but 
based on your reply it sounds like I'd need to be able to guarantee that 
"this object really is not reachable by anything that's in tenured" which 
really appears to equate to explicit memory management.

Cheers
Matt

Matt Khan
--------------------------------------------------
GFFX Auto Trading
Deutsche Bank, London



---

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/bbd3601f/attachment-0001.html 
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

End of hotspot-gc-dev Digest, Vol 34, Issue 13
**********************************************