GC悲觀策略之Serial GC篇

仍然是這篇blog:GC悲觀策略之ParallelGC篇中的代碼，換成-Xms30m-Xmx30m-Xmn10m-XX:+UseSerialGC後執行的結果爲YGC、YGC、YGC、YGC、FGC。
緣由就在於SerialGC的悲觀策略是不一樣的，SerialGC在執行YGC時，首先進入以下代碼片斷進行檢查：

[c]
void DefNewGeneration::collect(bool full,
bool clear_all_soft_refs,
size_t size,
bool is_tlab) {
…
if (!collection_attempt_is_safe()) {
gch->set_incremental_collection_will_fail();
return;
}
…
}
bool DefNewGeneration::collection_attempt_is_safe() {
if (!to()->is_empty()) {
return false;
}
if (_next_gen == NULL) {
GenCollectedHeap* gch = GenCollectedHeap::heap();
_next_gen = gch->next_gen(this);
assert(_next_gen != NULL,
"This must be the youngest gen, and not the only gen");
}
const double evacuation_ratio = MaxLiveObjectEvacuationRatio / 100.0;
size_t worst_case_evacuation = (size_t)(used() * evacuation_ratio);

//這裏的_next_gen也就是舊生代了，下面貼出舊生代對應的代碼

return _next_gen->promotion_attempt_is_safe(worst_case_evacuation,
HandlePromotionFailure);
}
bool TenuredGeneration::promotion_attempt_is_safe(
size_t max_promotion_in_bytes,
bool younger_handles_promotion_failure) const {
bool result = max_contiguous_available() >= max_promotion_in_bytes;
if (younger_handles_promotion_failure && !result) {
result = max_contiguous_available() >=
(size_t) gc_stats()->avg_promoted()->padded_average();
if (PrintGC && Verbose && result) {
gclog_or_tty->print_cr("TenuredGeneration::promotion_attempt_is_safe"
" contiguous_available: " SIZE_FORMAT
" avg_promoted: " SIZE_FORMAT,
max_contiguous_available(),
gc_stats()->avg_promoted()->padded_average());
}
} else {
if (PrintGC && Verbose) {
gclog_or_tty->print_cr("TenuredGeneration::promotion_attempt_is_safe"
" contiguous_available: " SIZE_FORMAT
" promotion_in_bytes: " SIZE_FORMAT,
max_contiguous_available(), max_promotion_in_bytes);
}
}
return result;
}
[/c]

這個檢查首先是檢查目前新生代中使用的空間是否大於了舊生代剩餘的空間，如大於且HandlePromotionFailure爲true（默認值），那麼再檢查舊生代剩餘的空間是否大於以前平均晉升的old的大小，如大於則返回true，小於則返回false，在返回false的狀況下，就不進行YGC的剩下的操做了。
按照這樣的規則，在第九次循環的時候，應該執行的是FGC，而不是YGC，這裏的緣由是在SerialGC時，是先進行計數和時間的統計等，再調用DefNewGeneration的collect的，所以儘管此次沒有真正的執行YGC的動做，但仍是被計數和計入時間了，但此次爲何GClog中輸出的不是FullGC呢，請看下面的代碼片斷：

[c]
void GenCollectedHeap::do_collection(bool full,
bool clear_all_soft_refs,
size_t size,
bool is_tlab,
int max_level) {
…

//在當前場景下，傳入的full爲false，所以complete爲false

bool complete = full && (max_level == (n_gens()-1));
const char* gc_cause_str = "GC ";
if (complete) {
GCCause::Cause cause = gc_cause();
if (cause == GCCause::_java_lang_system_gc) {
gc_cause_str = "Full GC (System) ";
} else {
gc_cause_str = "Full GC ";
}
}
…
for (int i = starting_level; i <= max_level; i++) {
if (_gens[i]->should_collect(full, size, is_tlab)) {
…
// Determine if allocation request was met.
if (size > 0) {
if (!is_tlab || _gens[i]->supports_tlab_allocation()) {
if (size*HeapWordSize <= _gens[i]->unsafe_max_alloc_nogc()) {
size = 0;
}
}
}
…
}
}
[/c]

從上可看出，當YGC結束後，eden的空間能夠知足分配的需求的話，須要分配的對象的大小size就被置爲零了，而在第九次循環中，因爲YGC提早結束，所以eden的空間是仍然不足的，此時須要分配的size大小會不變，上面的GC動做還將進入TenuredGeneration的should_allocate來進行檢查了，該方法的代碼片斷以下：

[c]
bool TenuredGeneration::should_collect(bool full,
size_t size,
bool is_tlab) {
// This should be one big conditional or (||), but I want to be able to tell
// why it returns what it returns (without re-evaluating the conditionals
// in case they aren’t idempotent), so I’m doing it this way.
// DeMorgan says it’s okay.
bool result = false;

//由於full是false，所以進入不了這裏

if (!result && full) {
result = true;
if (PrintGC && Verbose) {
gclog_or_tty->print_cr("TenuredGeneration::should_collect: because"
" full");
}
}
if (!result && should_allocate(size, is_tlab)) {
result = true;
if (PrintGC && Verbose) {
gclog_or_tty->print_cr("TenuredGeneration::should_collect: because"
" should_allocate(" SIZE_FORMAT ")",
size);
}
}
// If we don’t have very much free space.
// XXX: 10000 should be a percentage of the capacity!!!
if (!result && free() < 10000) {
result = true;
if (PrintGC && Verbose) {
gclog_or_tty->print_cr("TenuredGeneration::should_collect: because"
" free(): " SIZE_FORMAT,
free());
}
}
// If we had to expand to accomodate promotions from younger generations
if (!result && _capacity_at_prologue < capacity()) {
result = true;
if (PrintGC && Verbose) {
gclog_or_tty->print_cr("TenuredGeneration::should_collect: because"
"_capacity_at_prologue: " SIZE_FORMAT " < capacity(): " SIZE_FORMAT,
_capacity_at_prologue, capacity());
}
}
return result;
}
virtual bool should_allocate(size_t word_size, bool is_tlab) {
bool result = false;
// 32 bit上BitsPerSize_t爲32，64 bit上爲64， LogHeapWordSize在32 bit爲2，64 bit爲3
size_t overflow_limit = (size_t)1 << (BitsPerSize_t – LogHeapWordSize);
if (!is_tlab || supports_tlab_allocation()) {
result = (word_size > 0) && (word_size < overflow_limit);
}
return result;
}
[/c]

由此可看出，should_allocate爲true，所以觸發了FGC。

這樣就能夠理解爲何在第九次循環的時候打印出來的日誌是沒有FullGC字樣的，但又計算爲執行了一次YGC和一次FGC的。

因爲ConcurrentGC是基於SerialGC實現的，所以悲觀策略是相同的。

ps:如你們想研究這些東西，一方面是下載源碼，另外一方面也能夠下載一個debug版本的jdk，這樣就能夠經過打開一些日誌，看到更多的hotspot運行的細節，另外，也能夠看出，ParallelGC的實如今代碼上就清晰多了。