JEP 173: Remove Rarely-Used Combinations of Garbage Collectors
ysr1729 at gmail.com
Wed Dec 5 23:05:28 UTC 2012
I am thinking that if we have a "test case" or publicly available
application that can serve as a "witness" to this, it would
allow us to learn a few useful things on how regular CMS might do better
for such apps, and understand the basis of
this difference. (Unless you have already analysed it and can share your
summary of it.)
On Wed, Dec 5, 2012 at 3:01 PM, Srinivas Ramakrishna <ysr1729 at gmail.com>wrote:
> Hi Kirk --
> On Wed, Dec 5, 2012 at 2:48 PM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
>> Hi all,
>> The JEP's are coming in fast and furious. There is a customer use case
>> for iCMS.. it's used by low latency applications... and quite successfully
>> in fact. iCMS manages large heaps much better than CMS does which
>> translates into more manageable pause times... I've got logs from a number
>> of customers that rely on iCMS.
> This is very interesting indeed (and something i had vaguely heard a few
> years ago from the general grapevine, although never actually understood
> why it must be so). Could you go a bit deeper on why this is so? What
> exactly is it about doing a "slow, spread-out, incremental CMS collection"
> that makes it work better than bang-bang vanilla CMS in large multi-core,
> server environments? Perhaps the insights from that might translate into
> something useful for vanilla CMS?
> Your experience does indicate that we must proceed with some caution here
> before we deprecate iCMS, given it might still have some useful life
> (notwithstanding my own instincts to the contrary -- in server
> environments -- expressed in an earlier email before I had seen yours).
> -- ramki
>> On 2012-12-05, at 11:10 PM, mark.reinhold at oracle.com wrote:
>> > Posted: http://openjdk.java.net/jeps/173
>> > - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev