concurrent-mark-sweep | 易学教程

Could increase gc time short lived object that has references to old lived object?

阅读更多关于 Could increase gc time short lived object that has references to old lived object?

问题 I need some clarification about how minor gc collections behave. calling a() or calling b() in a long-lived application, if they could behave worstly when old space gets bigger //an example instance lives all application life cycle 24x7 public class Example { private Object longLived = new Object(); public void a(){ var shortLived = new ShortLivedObject(longLived); // longLived now is attribute shortLived.doSomething(); } public void b(){ new ShortLivedObject().doSomething(new Object()); //

CMS garbage collector - when does it run?

阅读更多关于 CMS garbage collector - when does it run?

问题 I am confused about two parameters that may control when the CMS collector kicks in: MaxHeapFreeRatio (70% by default) CMSInitiatingOccupancyFraction (over 90% by default) What does each of those parameters mean, exactly? When does the collector start (the marking phase), and collect (the sweeping phase)? 回答1: CMSInitiatingOccupancyFraction decides when the CMS kicks in (in order for this option to be effective you must also set -XX:+UseCMSInitiatingOccupancyOnly ). MaxHeapFreeRatio is an

CMS garbage collector - when does it run?

阅读更多关于 CMS garbage collector - when does it run?

Avoiding promotion failed in Java CMS GC

阅读更多关于 Avoiding promotion failed in Java CMS GC

问题 I have a Java application using CMS garbage collection that suffers from a "ParNew (promotion failed)" full GC a few times every day (see below for an example). I understand that a promotion failure occurs when garbage collection cannot find enough (contiguous) space in the old generation into which to promote an object from the new generation. At this point it is forced to do an expensive stop-the-world full GC. I want to avoid such events. I have read several articles that suggest possible

High Number of CMS mark remark pauses even though Old gen is not half full

阅读更多关于 High Number of CMS mark remark pauses even though Old gen is not half full

问题 I am trying to understand the cause for high number of CMS marks and remarks(other phases as well) averaging around 700ms even though the old gen is not even half full.Following are the GC configurations and stats from GCViewer. -Xms3g -Xmx3g -XX:NewSize=1800m -XX:MaxNewSize=1800m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled Summary using GC Viewer: http://i.imgur.com/0IIbNUr.png GC Log 152433.761: [GC [1 CMS-initial-mark: 284761K(1302528K)]

Avoiding promotion failed in Java CMS GC

阅读更多关于 Avoiding promotion failed in Java CMS GC

I have a Java application using CMS garbage collection that suffers from a "ParNew (promotion failed)" full GC a few times every day (see below for an example). I understand that a promotion failure occurs when garbage collection cannot find enough (contiguous) space in the old generation into which to promote an object from the new generation. At this point it is forced to do an expensive stop-the-world full GC. I want to avoid such events. I have read several articles that suggest possible solutions but I wanted to clarify/consolidate them here: -Xmx: Increase heap size, eg. from 2G to 4G --

UseConcMarkSweepGC vs UseParallelGC

阅读更多关于 UseConcMarkSweepGC vs UseParallelGC

问题 I'm currently having problems with very long garbage collection times. please see the followig. My current setup is that I'm using a -Xms1g and -Xmx3g. my application is using java 1.4.2. I don't have any garbage collection flags set. by the looks of it, 3gb is not enough and I really have a lot of objects to garbage collect. question: should I change my garbage collection algorithm? what should i use? is it better to use -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC or should i use this

UseConcMarkSweepGC vs UseParallelGC

阅读更多关于 UseConcMarkSweepGC vs UseParallelGC

I'm currently having problems with very long garbage collection times. please see the followig. My current setup is that I'm using a -Xms1g and -Xmx3g. my application is using java 1.4.2. I don't have any garbage collection flags set. by the looks of it, 3gb is not enough and I really have a lot of objects to garbage collect. question: should I change my garbage collection algorithm? what should i use? is it better to use -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC or should i use this combination -XX:+UseParNewGC -XX:+UseConcMarkSweepGC the ones occupying the memory are largely reports data

Java ConcurrentMarkSweep garbage collector not removing all garbage

阅读更多关于 Java ConcurrentMarkSweep garbage collector not removing all garbage

Short form: The CMS garbage collector appears to be failing to collect an ever-increasing amount of garbage; eventually, our JVM fills up, and the application becomes unresponsive. Forcing a GC via an external tool (JConsole or jmap -histo:live ) cleans it up once. UPDATE: The problem appears to be related to the JTop plugin for JConsole; if we don't run JConsole, or run it without the JTop plugin, the behavior goes away. (Technical notes: we're running Sun JDK 1.6.0_07, 32-bit, on a Linux 2.6.9 box. Upgrading the JDK version is not really an option, unless there's an unavoidable, major reason

Java ConcurrentMarkSweep garbage collector not removing all garbage

阅读更多关于 Java ConcurrentMarkSweep garbage collector not removing all garbage

问题 Short form: The CMS garbage collector appears to be failing to collect an ever-increasing amount of garbage; eventually, our JVM fills up, and the application becomes unresponsive. Forcing a GC via an external tool (JConsole or jmap -histo:live ) cleans it up once. UPDATE: The problem appears to be related to the JTop plugin for JConsole; if we don't run JConsole, or run it without the JTop plugin, the behavior goes away. (Technical notes: we're running Sun JDK 1.6.0_07, 32-bit, on a Linux 2