Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better measurement and reporting of GC statistics #106

Open
shwestrick opened this issue Jan 13, 2020 · 0 comments
Open

Better measurement and reporting of GC statistics #106

shwestrick opened this issue Jan 13, 2020 · 0 comments

Comments

@shwestrick
Copy link
Collaborator

We need to implement better memory management statistics. Much of the MLton GC library is MLton-specific and no longer relevant to MPL.

At the moment to measure GC, I've been relying on the functions GC_getLocalGCMillisecondsOfProc and GC_getPromoMillisecondsOfProc which are respectively imported into MLton.GC.Statistics as localGCTimeOfProc and promoTimeOfProc. These are implemented in terms of clock_gettime, measuring wall-clock time. If we want to distinguish user and system time (such as in the style of MLton.Rusage) then we will have to do something more careful, e.g. as discussed in #67.

Some desirable other things:

  • Bytes allocated.
    • Is this a per-processor measurement?
    • If not, then what is the best way to accurately measure it on-the-fly?
  • Bytes collected and promoted.
    • Is this a per-processor measurement?
  • Current total heap size.
    • Similar to bytes allocated, we want a reasonably accurate way of measuring it on-the-fly even while other processors are allocating, collecting, etc.
  • Current bytes live.
    • This is difficult to measure accurately without some sort of global synchronization?
    • Also measure maximum bytes live, so far.
  • Number of (local) GCs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant