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

[Derek White]

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.

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