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

Thomas Schatzl thomas.schatzl at oracle.com
Wed Jan 20 10:50:09 UTC 2016


On Wed, 2016-01-20 at 11:37 +0100, 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?

  in my recollection about some (very short) tests with that it seemed
that ultimately the memory would get purged as it has been put on the
purge list.


More information about the hotspot-gc-dev mailing list