Mercurial > hg > truffle
comparison src/share/vm/gc_implementation/g1/sparsePRT.hpp @ 1886:72a161e62cc4
6991377: G1: race between concurrent refinement and humongous object allocation
Summary: There is a race between the concurrent refinement threads and the humongous object allocation that can cause the concurrent refinement threads to corrupt the part of the BOT that it is being initialized by the humongous object allocation operation. The solution is to do the humongous object allocation in careful steps to ensure that the concurrent refinement threads always have a consistent view over the BOT, region contents, and top. The fix includes some very minor tidying up in sparsePRT.
Reviewed-by: jcoomes, johnc, ysr
author | tonyp |
---|---|
date | Sat, 16 Oct 2010 17:12:19 -0400 |
parents | 9f4848ebbabd |
children | f95d63e2154a |
comparison
equal
deleted
inserted
replaced
1885:a5c514e74487 | 1886:72a161e62cc4 |
---|---|
280 }; | 280 }; |
281 | 281 |
282 | 282 |
283 class SparsePRTIter: public RSHashTableIter { | 283 class SparsePRTIter: public RSHashTableIter { |
284 public: | 284 public: |
285 SparsePRTIter() : RSHashTableIter() { } | |
286 | |
287 void init(const SparsePRT* sprt) { | 285 void init(const SparsePRT* sprt) { |
288 RSHashTableIter::init(sprt->cur()); | 286 RSHashTableIter::init(sprt->cur()); |
289 } | 287 } |
290 bool has_next(size_t& card_index) { | 288 bool has_next(size_t& card_index) { |
291 return RSHashTableIter::has_next(card_index); | 289 return RSHashTableIter::has_next(card_index); |