Stats: add promoted, gen size, reason, and overall heap output when pressing s

[NickCraver]

Totally take it if you want, I can slice off pieces that are wanted, or close if not the right direction - no worries at all. Either way, thanks for this!

Overall I often want to see the state across heaps w.r.t. size so I tweaked this to output that if a user hits s while running. This adds promoted, gen size, and reason for the collection to the existing output but also adds the ability to hit s to get a breakdown of the current heaps (as of the last collection). Example run:

➜ dotnet run -- -p 45044
------- press s for current stats or any other key to exit -------

Monitoring process with name: Samples.AspNet5 and pid: 45044
GC#     index |            type |   gen | pause (ms) |                reason |
------------------------------------------------------------------------------
GC#         1 | NonConcurrentGC |     0 |       7.45 |            AllocSmall |
------------------------------------------------------------------------------
Heap Stats as of 2021-11-08 03:15:30Z (Run 1 for gen 0):
  Heaps: 16
  Handles: 2,015
  Pinned Obj Count: 8
  Last Run Stats:
    Total Heap: 15,846,992 Bytes
      Gen 0:               384 Bytes
      Gen 1:        10,718,432 Bytes
      Gen 2:               384 Bytes
      Gen 3:         4,358,056 Bytes
      Gen 4:           769,736 Bytes
------------------------------------------------------------------------------

Total changes:

• Minor cleanup to initial message
• Adds promoted, gen size, and reason to the existing output
• Hitting s now prints last stats (if any collected yet, a short message if not)
• Hitting a key actually exits now - it took keys + enter previously with .ReadLine()
• Locks around multi-line console writing to prevent tearing (little contention here, just in case!)

[Maoni0]

thanks @NickCraver! I like the pressing 's' for stats feature a lot :)

[MokoSan]

The press 's' for stats feature is AWESOME!! I wonder if we should also add it behind a command line arg so that it outputs the result on some cadence via a timer?

Might be worth updating the README with the respective changes as well such as in the case of the example output.

[NickCraver]

@MokoSan agreed, needs more thought on what that looks like though (convo above) - perhaps I should trim this down to just the s feature and think on the other columns more to represent collection/promotion and present some ideas there.

Thoughts @Maoni0? Happy to back out columns bit and think on it more but get the s in with narrower column count here.

[NickCraver]

@MokoSan @Maoni0 house stuff and bed here but updated PR to be just the reason column (with README update) and the s feature - trimmed it down so we can tackle other ideas separately :)

[Maoni0]

sure, we can think more about the ways how to represent the gen sizes. I think the promoted column is fine (you could use gc.PromotedMB but obviously could be done in another PR :)

[Maoni0]

thanks so much @NickCraver 😺

[Maoni0]

@MokoSan do you think it's better to config things in stdout or in a file, ie, a config file like this (feel free to suggest other options)?

[columns] gen type pause (ms) reason [stats_mode] // could be manual which means it'll only show if you press s, or timer and you can specify the interval timer: 5m [available columns] // other columns available - could be many here since TraceGC exposes lots of stuff

[MokoSan]

I think a file would definitely scale better with more options and the persistence would be make re-using configs much easier. I was thinking maybe the first time around, maybe the --config command line arg allows users to choose the configs and create the file that'll be read the next time around.

Pseudo code:

if no config file -> go to defaults.
if --config is passed as a command line arg -> open up the menu and create a config file
if config file -> pull in the configs 

Do let me know if this is making the tool too complicated; the trade off is better user experience in terms of configurability.

EDIT: Forgot to add, the YAML format looks good! I'll start working on a PR to get more opinions on the specifics.

[Maoni0]

I'll start working on a PR to get more opinions on the specifics.

sounds good to me!