Review Request: 8011872: Include Bit Map addresses in the hs_err files

[Stefan Karlsson]

(readding hotspot-gc-dev)

On 04/10/2013 09:02 PM, Jon Masamitsu wrote:
> Changes look good.

Thanks.

>
> Did you see a case where _collector was NULL?  Or is this
> clean coding?
>
>> *+ CMSCollector::print_on_error(outputStream* st) {*
>> *+   CMSCollector* collector = ConcurrentMarkSweepGeneration::_collector;*
>> *+   if (collector != NULL) {*
>

This is just defensive programming.

The _collector will always be setup when we try to print the heap in the 
hs_err files. The logging is guarded by this:
      if (_verbose && Universe::is_fully_initialized()) {
        Universe::heap()->print_on_error(st);

The Universe is fully initialized in universe_post_init() and _collector 
is setup before that, deep down in universe_init().

thanks,
StefanK

> Jon
>
> On 4/10/2013 7:58 AM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8011872/webrev.00/
>>
>> I propose that we start logging the placement of the bitmaps hs_err 
>> crash files.
>>
>> 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.
>>
>> Example outputs:
>>
>> -XX:+UseParallelOldGC:
>> Marking Bits: (ParMarkBitMap*) 0x00007ffff73a85e0
>>  Begin Bits: [0x00007fffe4200000, 0x00007fffe60b8000)
>>  End Bits:   [0x00007fffe60b8000, 0x00007fffe7f70000)
>>
>> -XX:+UseG1GC:
>> Marking Bits (Prev, Next): (CMBitMap*) 0x00007ffff0059628, 
>> (CMBitMap*) 0x00007ffff00596c0
>>  Prev Bits: [0x00007fffc5290000, 0x00007fffc7148000)
>>  Next Bits: [0x00007fffa2147000, 0x00007fffa3fff000)
>>
>> -XX:+UseConcMarkSweepGC:
>> Marking Bits: (CMSBitMap*) 0x00007ffff00b0ee8
>>  Bits: [0x00007fffce7f1000, 0x00007fffcfc6e800)
>>
>> Mod Union Table: (CMSBitMap*) 0x00007ffff00b0f88
>>  Bits: [0x00007ffff405c000, 0x00007ffff40adf60)
>>
>> 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.
>>
>> thanks,
>> StefanK
>

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