CRR (S): 7099849: G1: include heap region information in hs_err files

Fri Nov 4 15:17:39 UTC 2011

Poonam, I removed the notion of "GC alloc region" with 7039627. Are you 
looking at a recent workspace?

Tony

On 11/3/2011 8:38 PM, poonam.bajaj at oracle.com wrote:
> Hi Tony,
>
> The changes and the output looks good!
>
> I noticed in heapRegion.cpp (in HeapRegion::print() ) that 'A' for GC 
> Alloc region can also appear in the HeapRegion output, so would be 
> good to add the meaning of A too in the header.
>
> Thanks,
> Poonam
>
>
> On 11/3/2011 9:57 PM, Tony Printezis wrote:
>> Poonam,
>>
>> Latest webrev is here:
>>
>> http://cr.openjdk.java.net/~tonyp/7099849/webrev.1/webrev.all/
>>
>> This is what I changed compared to the previous one:
>>
>> http://cr.openjdk.java.net/~tonyp/7099849/webrev.1/webrev.1.G1HSErrExtra/
>>
>> I decided to also add "TS" before the GC time stamp on every line so 
>> that I can describe what that that value is. (universe.hpp has the 
>> white space changes Bengt asked for)
>>
>> This is some example output:
>>
>> Heap
>>  garbage-first heap   total 32768K, used 21540K [0xace00000, 
>> 0xaee00000, 0xaee00
>> 000)
>>   region size 1024K, 4 young (4096K), 2 survivors (2048K)
>>  compacting perm gen  total 16384K, used 2663K [0xaee00000, 
>> 0xafe00000, 0xb2e000
>> 00)
>>    the space 16384K,  16% used [0xaee00000, 0xaf099fe8, 0xaf09a000, 
>> 0xafe00000)
>> No shared spaces configured.
>>
>> Heap Regions: (Y=young(eden), SU=young(survivor), 
>> HS=humongous(starts), HC=humongous(continues), CS=collection set, 
>> F=free, TS=gc time stamp, PTAMS=previous top-at-mark-start, 
>> NTAMS=next top-at-mark-start)
>>           F TS    17 PTAMS 0xace00000 NTAMS 0xace00000 space 1024K,   
>> 0% used [0xace00000, 0xace00000, 0xacf00000)
>>             TS    11 PTAMS 0xacf00000 NTAMS 0xad000000 space 1024K, 
>> 100% used [0
>> ...
>>
>> and I also attached the full hs_err file.
>>
>> Better?
>>
>> Tony
>>
>> On 11/01/2011 10:08 AM, poonam.bajaj at oracle.com wrote:
>>> Hi Tony,
>>>
>>> I hope I am not too late in providing feedback on this change. Here 
>>> are couple of suggestions for the heap regions information in hs_err 
>>> file:
>>>
>>> - I think it would be useful to print a header before the heap 
>>> regions details. e.g.
>>>
>>> Heap
>>>  garbage-first heap   total 20480K, used 11630K [0x6e600000, 
>>> 0x6fa00000, 0xae600000)
>>>   region size 1024K, 1 young (1024K), 1 survivors (1024K)
>>>  compacting perm gen  total 16384K, used 2604K [0xae600000, 
>>> 0xaf600000, 0xb2600000)
>>>    the space 16384K,  15% used [0xae600000, 0xae88b3c0, 0xae88b400, 
>>> 0xaf600000)
>>> No shared spaces configured.
>>>
>>> *Heap Regions:*
>>>                   0 PTAMS 0x6e600000 NTAMS 0x6e639700 space 1024K,  
>>> 22% used [0x6e600000, 0x6e639700, 0x6e700000)
>>>           F    17 PTAMS 0x6e700000 NTAMS 0x6e700000 space 1024K,   
>>> 0% used [0x6e700000, 0x6e700000, 0x6e800000)
>>>           F    17 PTAMS 0x6e800000 NTAMS 0x6e800000 space 1024K,   
>>> 0% used [0x6e800000, 0x6e800000, 0x6e900000)
>>>
>>>
>>> - Also, I think it would be helpful for the hs_err file reader to 
>>> have the meanings of the acronyms also printed (as we show in the 
>>> stack trace in hs_err file)
>>>
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
>>> C=native code)
>>> V  [libjvm.so+0xc494db]  VMError::report_and_die()+0x19b
>>>
>>> Heap Regions: (CS=collection set, PTAMS=previous top at mark start, 
>>> NTAMS=next top at mark start, etc...)
>>>                17 PTAMS 0x6f200000 NTAMS 0x6f300000 space 1024K, 
>>> 100% used [0x6f200000, 0x6f300000, 0x6f300000)
>>>     CS SU      17 PTAMS 0x6f300000 NTAMS 0x6f38e650 space 1024K,  
>>> 55% used [0x6f300000, 0x6f38e650, 0x6f400000)
>>>                17 PTAMS 0x6f400000 NTAMS 0x6f493c60 space 1024K,  
>>> 57% used [0x6f400000, 0x6f493c60, 0x6f500000)
>>>
>>>
>>>
>>> Thanks,
>>> Poonam
>>>
>>>
>>> On 10/12/2011 10:19 PM, Tony Printezis wrote:
>>>> Hi all,
>>>>
>>>> (I'm also copying the runtime alias, as this change will concern 
>>>> them too)
>>>>
>>>> I'd like to get a couple of reviews for this change:
>>>>
>>>> http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/
>>>>
>>>> Some background: when trying to track down issues in G1 it is often 
>>>> very helpful to know what type of regions the heap has and/or get 
>>>> information on a particular region (whether it's humongous, whether 
>>>> it's young, how full it is, etc.). We thought it'd be a good idea 
>>>> to include the per-region information in the hs_err file to always 
>>>> have it available after a crash.
>>>>
>>>> I don't think the changes in the webrev are too controversial. The 
>>>> reason I wanted to give a heads up to both groups was to point out 
>>>> that this change will increase the size of the hs_err files when G1 
>>>> is used. It's common to have 1,000 to 2,000 regions in the heap, if 
>>>> larger heaps are used (much fewer if smaller heaps are used), which 
>>>> means that the hs_err file will have this many extra lines. Does 
>>>> anyone have any concerns about this?
>>>>
>>>> I attached an example hs_err file obtained from a workspace with 
>>>> this change applied.
>>>>
>>>> BTW, I also cleaned up a bit the way the print() methods on the 
>>>> heap are defined (I pushed the default behavior to the superclass, 
>>>> where possible).
>>>>
>>>> Tony
>>>>
>>>
>>> -- 
>>> Best regards, Poonam
>>>
>>> Oracle <http://www.oracle.com>
>>> Poonam Bajaj | Principal Member of Technical Staff
>>> Phone: +91 80 66937451 <tel:+91%2080%2066937451> | Mobile: +91 
>>> 9844511366 <tel:+91%209844511366>
>>> Oracle JVM Sustaining Engineering
>>>
>>> ORACLE India Bangalore
>>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed 
>>> to developing practices and products that help protect the environment
>>>
>
> -- 
> Best regards, Poonam
>
> Oracle <http://www.oracle.com>
> Poonam Bajaj | Principal Member of Technical Staff
> Phone: +91 80 66937451 <tel:+91%2080%2066937451> | Mobile: +91 
> 9844511366 <tel:+91%209844511366>
> Oracle JVM Sustaining Engineering
>
> ORACLE India Bangalore
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
> developing practices and products that help protect the environment
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/eb9743d7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/eb9743d7/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 356 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/eb9743d7/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/eb9743d7/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 356 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/eb9743d7/attachment-0003.gif>