<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Updated webrev: Print out values in
lock assertion failure messages (see EOM for details)<br>
<br>
This is a small fix for a (malloc) memory leak that is causing a
variety of crashes.<br>
<br>
This also improves memory tracking slightly, and adds asserts that
clarify the expected locking usage of g1CodeCacheRemSet.<br>
<br>
<span class="issue-link"><b>BUG</b>: JDK-8141421</span> Various
test fail with OOME on win x86<br>
<b>Webrev</b>: <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edrwhite/8141421/webrev.01/">http://cr.openjdk.java.net/~drwhite/8141421/webrev.01/</a><br>
<b>Testing</b> jprt, aurora.<br>
<br>
On 1/20/16 11:34 AM, Derek White wrote:<br>
</div>
<blockquote cite="mid:569FB71A.6020603@oracle.com" type="cite">On
1/20/16 5:54 AM, Thomas Schatzl wrote:
<br>
<blockquote type="cite">Hi Derek,
<br>
<br>
On Tue, 2016-01-19 at 12:38 -0500, Derek White wrote:
<br>
<blockquote type="cite">This is a small fix for a (malloc)
memory leak that is causing a
<br>
variety of crashes.
<br>
<br>
This also improves memory tracking slightly, and adds asserts
that
<br>
clarify the expected locking usage of g1CodeCacheRemSet.
<br>
<br>
BUG: JDK-8141421 Various test fail with OOME on win x86
<br>
Webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~drwhite/8141421/webrev.00/">http://cr.openjdk.java.net/~drwhite/8141421/webrev.00/</a>
<br>
Testing jprt, aurora.
<br>
</blockquote>
nice catch :)
<br>
</blockquote>
<br>
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 :-)
<br>
<blockquote type="cite">
<br>
Could you improve the failing asserts to contain the compared
values?
<br>
That would make eventual debugging easier.
<br>
</blockquote>
<br>
OK, I'll get a new rev out soon...
<br>
</blockquote>
Thomas,<br>
<br>
I added values to the lock assertion messages. They check
constraints between the caller and callee that are hard to reason
about.<br>
<br>
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.<br>
<br>
Is this reasonable?<br>
<br>
- Derek<br>
<br>
</body>
</html>