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

[Derek White]

Updated webrev: Print out values in lock assertion failure messages (see 
EOM for details)

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.01/
*Testing* jprt, aurora.

On 1/20/16 11:34 AM, Derek White wrote:
> On 1/20/16 5:54 AM, Thomas Schatzl wrote:
>> Hi Derek,
>>
>> On Tue, 2016-01-19 at 12:38 -0500, 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/
>>> Testing jprt, aurora.
>>    nice catch :)
>
> I stared at that code for a long time without seeing a problem! Only 
> when I threw in a bunch of statistics did it become clear :-)
>>
>> Could you improve the failing asserts to contain the compared values?
>> That would make eventual debugging easier.
>
> OK, I'll get a new rev out soon...
Thomas,

I added values to the lock assertion messages. They check constraints 
between the caller and callee that are hard to reason about.

Then I wasn't sure which data you wanted displayed after all. I did not 
add values to the "length" assertion checks in g1CodeCacheRemSet.cpp. 
They check internal state that can be "proven" statically. They are less 
an error check and more a declaration that, "Yes, the length is stored 
in two places, but they are equal at all times." I was tempted to remove 
the duplicated "_length" value, but I couldn't prove to myself that 
"_length" wasn't used in some performance critical way.

Is this reasonable?

  - Derek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160120/c82fac75/attachment.htm>