CRR (S): 7099849: G1: include heap region information in hs_err files
poonam.bajaj at oracle.com
poonam.bajaj at oracle.com
Fri Nov 4 00:38:01 UTC 2011
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/68148771/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/68148771/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/68148771/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/68148771/oracle_sig_logo.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green-for-email-sig_0.gif
Type: image/gif
Size: 356 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111104/68148771/green-for-email-sig_0.gif>
More information about the hotspot-gc-dev
mailing list