RFR (S): 8141421: Various test fail with OOME on win x86
derek.white at oracle.com
Wed Jan 20 16:32:00 UTC 2016
On 1/20/16 5:37 AM, Mikael Gerdin wrote:
> Hi Derek,
> On 2016-01-19 18:38, Derek White wrote:
>> This is a small fix for a (malloc) memory leak that is causing a variety
>> of crashes.
>> This also improves memory tracking slightly, and adds asserts that
>> clarify the expected locking usage of g1CodeCacheRemSet.
>> *BUG*: JDK-8141421 Various test fail with OOME on win x86
>> *Webrev*: http://cr.openjdk.java.net/~drwhite/8141421/webrev.00/
> The fix looks good, but I have a question with regard to the leak itself.
> Is it a leak in the sense that the memory never actually gets freed?
> It appears to me that calling move_to_large several times, while not
> optimal, would still put the previous value of _table on the purge
> list, pending deallocation by a call to purge().
> In that case, is it the sudden spike of memory usage that causes the
> OOM situations and not that the memory would never be freed?
Yes, you're right. It's not a true "leak", but a delayed release. One
common aspect of these OOM errors is that they happen during C2
compilation, so there may not be a lot of Java heap allocs and GC
occurring, but a lot of mallocs.
The one test case I was running showed the purge list running up to
4000-5000 (mostly large) hash tables, when the real max should be # of
In G1CodeRootSet::clear(), before delete
CodeRootSetTable(47E00A98, owned by 44E58254) Stats - entries: 114,
table_size: 512, occupancy: 0.22, mem size: 3448, free list len: 0
live tables: 15, redundant tables: 4844, size of redundant tables:
static purge list - current size: 0, removed: 4892, max purge list
More information about the hotspot-gc-dev