RFR (S): 8141421: Various test fail with OOME on win x86
derek.white at oracle.com
Thu Jan 21 15:16:38 UTC 2016
On 1/20/16 1:31 PM, Mikael Gerdin wrote:
> Hi Derek,
> On 2016-01-20 17:32, Derek White wrote:
>> Hi Mikael,
>> 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
>>>> 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
>>> 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.
> Ah, then I understood it correctly.
> Consider the fix Reviewed.
>> 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
>> heap regions.
>> 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
>> size: 4825
>> - Derek
More information about the hotspot-gc-dev