<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">(readding hotspot-gc-dev)<br>
<br>
On 04/10/2013 09:02 PM, Jon Masamitsu wrote:<br>
</div>
<blockquote cite="mid:5165B747.1010501@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Changes look good.<br>
</blockquote>
<br>
Thanks.<br>
<br>
<blockquote cite="mid:5165B747.1010501@oracle.com" type="cite"> <br>
Did you see a case where _collector was NULL? Or is this<br>
clean coding?<br>
<br>
<blockquote type="cite">
<pre><font color="blue"><b>+ CMSCollector::print_on_error(outputStream* st) {</b></font>
<font color="blue"><b>+ CMSCollector* collector = ConcurrentMarkSweepGeneration::_collector;</b></font>
<font color="blue"><b>+ if (collector != NULL) {</b></font></pre>
</blockquote>
<br>
</blockquote>
<br>
This is just defensive programming.<br>
<br>
The _collector will always be setup when we try to print the heap in
the hs_err files. The logging is guarded by this:<br>
if (_verbose && Universe::is_fully_initialized()) {<br>
Universe::heap()->print_on_error(st);<br>
<br>
The Universe is fully initialized in universe_post_init() and
_collector is setup before that, deep down in universe_init().<br>
<br>
thanks,<br>
StefanK<br>
<br>
<blockquote cite="mid:5165B747.1010501@oracle.com" type="cite"> Jon<br>
<br>
<div class="moz-cite-prefix">On 4/10/2013 7:58 AM, Stefan Karlsson
wrote:<br>
</div>
<blockquote cite="mid:51657E24.8060907@oracle.com" type="cite"><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Estefank/8011872/webrev.00/">http://cr.openjdk.java.net/~stefank/8011872/webrev.00/</a>
<br>
<br>
I propose that we start logging the placement of the bitmaps
hs_err crash files. <br>
<br>
This will help identifies bugs where we have memory trashing in
the bitmaps. Today, we have this kind of information for the
card table but it's lacking for the bitmaps. <br>
<br>
Example outputs: <br>
<br>
-XX:+UseParallelOldGC: <br>
Marking Bits: (ParMarkBitMap*) 0x00007ffff73a85e0 <br>
Begin Bits: [0x00007fffe4200000, 0x00007fffe60b8000) <br>
End Bits: [0x00007fffe60b8000, 0x00007fffe7f70000) <br>
<br>
-XX:+UseG1GC: <br>
Marking Bits (Prev, Next): (CMBitMap*) 0x00007ffff0059628,
(CMBitMap*) 0x00007ffff00596c0 <br>
Prev Bits: [0x00007fffc5290000, 0x00007fffc7148000) <br>
Next Bits: [0x00007fffa2147000, 0x00007fffa3fff000) <br>
<br>
-XX:+UseConcMarkSweepGC: <br>
Marking Bits: (CMSBitMap*) 0x00007ffff00b0ee8 <br>
Bits: [0x00007fffce7f1000, 0x00007fffcfc6e800) <br>
<br>
Mod Union Table: (CMSBitMap*) 0x00007ffff00b0f88 <br>
Bits: [0x00007ffff405c000, 0x00007ffff40adf60) <br>
<br>
Note that for simplicity this logs the memory used by the low
level datastructure BitMap, and not the memory allocated in the
GC specific bitmap data structures (E.g. CMBitMap). What this
means is that we actually allocate up to about
os::vm_allocation_granularity() more memoy at the end of the
bitmap. If this information is essential we can add it later. <br>
<br>
thanks, <br>
StefanK <br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>