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

[Mikael Gerdin]

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
>