Output Explanations

[JakobEdding]

As a user, I want to be shown hints with explanations and interpretation guidelines for the corresponding item when hovering over the result items "GCs" and "Memory" with my mouse. This way, my first time user experience will be enhanced because I can understand and interpret the results right away without asking somebody for an explanation or digging through documentation.

[JakobEdding]

Ask @timfel for explanations.

[JakobEdding]

Was ist inkrementelle Garbage Collection?

• Unterteilung in Old, Young Space
• die meisten Objekte sterben jung
• Full GC ist teuer (Old und Young Space beatrachten), deswegen stattdessen nur Young Space scannen (bzw. wenn noch weiter optimiert sogar nur Teile vom Young Space)
• Wenn bei einem Incr. GC-Vorgang Objekte aus dem Young Space nicht obsolet geworden sind, kommen sie in den Old Space

Memory old/young/used --> Anzahl Bytes, die während des Scanns an Young Space Objekten hinzugekommen sind free --> Veränderung des freien Speichers (abhängig von old, young, used)

GCs full --> Anzahl Full GCs, die während des Profilings durchgelaufen sind, deren totaler Zeitaufwand incr bzw. scavenges --> Anzahl Incremental GCs, die während des Profilings durchgelaufen sind, deren totaler Zeitaufwand, durchschnittler Zeitaufwand eines Incr. GC tenures --> älter als Old Space root table overflow --> Wie oft musste eine Datenstruktur, die Referenzen auf Klassen hält, während des Profilings neu angelegt werden? (Kann eigentlich nur passieren, wenn man dynamisch im Programm Klassen erstellt und ist damit für uns etwas aus dem Scope...)

Wenn während des Profilings einer eigenen Methode ein Full GC durchgelaufen ist, sollte man sich sorgen machen...

• auch Visual VM für Java angucken zum Vergleich
• Squeak Symbol im Menü -> About Squeak -> VM Parameters: Machine Code Zone Size, Survivor Objects könnten eventuell sinnvolle weiter Metriken für den Time Profile Browser sein!

[JakobEdding]

Revised notes

Sample Structure

Memory consumption during profiling Old space: +0 bytes Young space: +123 bytes Overall: +123 bytes Free space: -123 bytes Gargabge collection activity during profiling Incremental GCs: 1, totaling 0 ms (0% uptime), on avg 1 ms Full GCs: 0, totaling 0 ms (0% uptime), on avg 1 ms per GC Tenures: 0 Root table overflows: 0

Explanations

• Memory consumption during profiling
  • Subnodes show the change of used memory in different categories because of added/deleted objects
  • Memory space is divided into young space and old space.
  • When an object is first created, it's put into young space.
  • If an object has been in young space for quite a long time and during an incremental GC it's found that the object is still currently relevant to the executed process, it will be moved to old space.
  • However most of the time, all references to an object will be gone fairly quickly so that that object "dies" in young space and never gets to reside in old space.
• Garbage collection activity during profiling
  • Garbage collection looks for objects that are no longer used and frees up the space that they take up in memory so that the space can be used later to store new objects.
  • Incremental
  • Under the assumption that objects that have been in memory for a while are still relevant now, an incremental GC only scans the young space for objects that can be deleted. If during an incremental GC an object is found to still be referenced, it's not deleted but instead moved into old space.
  • Full
  • During a full GC, both young and old space will be scanned for objects that are without reference and can be deleted. This process is a lot more expensive than an incremental GC.
  • If a full GC repeatedly runs during execution of your program, this indicates that your code might be too heavy on memory resources.
  • Tenures
  • Scanning older-than-old-space objects.
  • Root table overflows
  • Number of times that the root table (responsible for holding references to classes) had to be recreated during profiling. This should only occur if you create classes dynamically.