RFR (S): 8141421: Various test fail with OOME on win x86

[Derek White]

Thanks Mikael!

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 
>>>> 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.
>
> Ah, then I understood it correctly.
> Consider the fix Reviewed.
> /Mikael
>
>>
>> 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:
>> 11430272
>>      static purge list - current size: 0,  removed: 4892, max purge list
>> size: 4825
>>
>>   - Derek
>>