Difference between revisions of "Gc info"
(→main-table=xx/yyyy: fixed a typo) |
(Headings hierarchy changed; esthetic improvements) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Book]] |
||
| − | == Column "Number created" == |
||
| + | Description of the information provided by the <tt>-gc_info</tt> option of the C |
||
| − | This is the number of objects (of the specified type) created since program start, (i.e. this figure is accumulative). This is <b>not</b> the number of actually existing objects. |
||
| + | [[Glossary#BackEnd|back-end]] compiler. |
||
| + | The information is printed to ''std_output'' after each GC cycle. |
||
| − | == |
+ | == Table columns == |
| + | The main part lists for each reference type and each NATIVE_ARRAY type |
||
| − | This is the same as "Number created", except the unit is bytes. |
||
| + | the following information. |
||
| + | === Number created === |
||
| + | The number of objects created since program start. |
||
| + | This is <b>not</b> the number of actually existing objects. |
||
| − | == |
+ | === Total size === |
| + | The same as '''Number created''' but the unit is bytes. |
||
| − | This is the number of free objects left in the "store chunk" of the specified type. This number is mainly interesting because it is zero for the type that triggered the collection cycle. Here's why: the gc will firstly allocate new objects in the store chunk. Only when there is no store left will the gc start looking for space elsewhere, which will result in one of the following outcomes: |
||
| − | * Previously reclaimed garbage is recycled as a new object. |
||
| − | * A new store chunk is allocated. |
||
| − | * A garbage collection cycle is started. If garbage of the correct type was reclaimed, garbage is recycled. Else, a new store chunk is allocated. |
||
| + | === Store left === |
||
| − | == Where is the information about the freed memory, i.e. about the effect of the last GC cycle? == |
||
| + | The number of free objects left in the "store chunk" of the specified type. |
||
| − | I am sad to report that this information is currently missing. |
||
| + | This number is mainly interesting because it is zero for the type that triggered the collection cycle. Here's why: the GC will firstly allocate new objects in the store chunk. Only when there is no store left will the GC starts looking for space elsewhere, which will result in one of the following outcomes: |
||
| − | == What does the cryptic final lines mean? == |
||
| + | <ul> |
||
| + | <li> Previously reclaimed garbage is recycled as a new object. |
||
| + | <li> A new store chunk is allocated. |
||
| + | <li> A garbage collection cycle is started. If garbage of the correct type was reclaimed, garbage is recycled. Else, a new store chunk is allocated. |
||
| + | </ul> |
||
| + | |||
| + | == Final line == |
||
| + | The final line shows synoptic information across all types. |
||
=== C-stack=xx === |
=== C-stack=xx === |
||
| − | xx is the number of pointers in the stack, i.e. the number of conservative roots. |
+ | ''xx'' is the number of pointers in the stack, i.e. the number of conservative roots. |
=== main-table=xx/yyyy === |
=== main-table=xx/yyyy === |
||
| − | xx is the number of memory chunks currently allocated. |
+ | ''xx'' is the number of memory chunks currently allocated. |
| + | ''yyyy'' is the number of chunks that the main table can hold. |
||
| + | When ''xx'' grows larger than ''yyyy'' the GC needs to reallocate a larger main table |
||
| + | (not a very costly operation unless ''yyyy'' is huge). |
||
=== fsoc:xx(free=yy ceil=zz) === |
=== fsoc:xx(free=yy ceil=zz) === |
||
| − | xx is the number of memory chunks currently allocated to fixed-size objects |
+ | ''xx'' is the number of memory chunks currently allocated to fixed-size objects |
| + | (all reference objects except NATIVE_ARRAYs). |
||
| + | ''yy'' is the number of free memory chunks, that is chunks that are devoted to fixed-size objects, but that do not hold any objects. |
||
| + | ''zz'' is the number of chunks that can be allocated to fixed-size objects |
||
| + | before a GC cycle is triggered. |
||
| − | When the |
+ | When the GC needs to allocate a new object and it has exhausted that type's store chunk |
| + | and reclaimed garbage, it tries to find a new store chunk for that type. |
||
| + | If ''yy'' is non-null, a free memory chunk is converted to a store chunk. |
||
| + | Else, if ''xx'' is smaller than ''zz'' then a chunk is allocated from the system. |
||
| + | Else, a GC cycle is started. |
||
=== rsoc:xx(ceil=yy) === |
=== rsoc:xx(ceil=yy) === |
||
| − | xx is the number of memory chunks currently allocated to resizable objects (NATIVE_ARRAYs). |
+ | ''xx'' is the number of memory chunks currently allocated to resizable objects (NATIVE_ARRAYs). |
| + | ''yy'' is the number of chunks that can be allocated to resizable objects |
||
| + | before a GC cycle is triggered. |
||
| + | |||
| + | == Remarks == |
||
| + | Currently, there is no information about the memory freed during the last GC cycle, |
||
| + | i.e. no information about the effect of the GC cycle described in the table. |
||
Revision as of 11:56, 12 September 2005
Description of the information provided by the -gc_info option of the C back-end compiler. The information is printed to std_output after each GC cycle.
Table columns
The main part lists for each reference type and each NATIVE_ARRAY type the following information.
Number created
The number of objects created since program start. This is not the number of actually existing objects.
Total size
The same as Number created but the unit is bytes.
Store left
The number of free objects left in the "store chunk" of the specified type.
This number is mainly interesting because it is zero for the type that triggered the collection cycle. Here's why: the GC will firstly allocate new objects in the store chunk. Only when there is no store left will the GC starts looking for space elsewhere, which will result in one of the following outcomes:
- Previously reclaimed garbage is recycled as a new object.
- A new store chunk is allocated.
- A garbage collection cycle is started. If garbage of the correct type was reclaimed, garbage is recycled. Else, a new store chunk is allocated.
Final line
The final line shows synoptic information across all types.
C-stack=xx
xx is the number of pointers in the stack, i.e. the number of conservative roots.
main-table=xx/yyyy
xx is the number of memory chunks currently allocated. yyyy is the number of chunks that the main table can hold. When xx grows larger than yyyy the GC needs to reallocate a larger main table (not a very costly operation unless yyyy is huge).
fsoc:xx(free=yy ceil=zz)
xx is the number of memory chunks currently allocated to fixed-size objects (all reference objects except NATIVE_ARRAYs). yy is the number of free memory chunks, that is chunks that are devoted to fixed-size objects, but that do not hold any objects. zz is the number of chunks that can be allocated to fixed-size objects before a GC cycle is triggered.
When the GC needs to allocate a new object and it has exhausted that type's store chunk and reclaimed garbage, it tries to find a new store chunk for that type. If yy is non-null, a free memory chunk is converted to a store chunk. Else, if xx is smaller than zz then a chunk is allocated from the system. Else, a GC cycle is started.
rsoc:xx(ceil=yy)
xx is the number of memory chunks currently allocated to resizable objects (NATIVE_ARRAYs). yy is the number of chunks that can be allocated to resizable objects before a GC cycle is triggered.
Remarks
Currently, there is no information about the memory freed during the last GC cycle, i.e. no information about the effect of the GC cycle described in the table.