-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
GC page profiler #52567
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
GC page profiler #52567
Conversation
7b153c0 to
01465a9
Compare
5214188 to
4c78f4f
Compare
|
In particular, we've been using this profile to compute page utilization per object type, as done in https://github.com/d-netto/page-profile-parser: |
195f86b to
6393ca1
Compare
|
Instrumentation above doesn't seem to introduce significant regressions in GC time:
|
417ee2b to
81bdfa5
Compare
deab1fa to
2deb6cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine generally, but I do wonder if we really need to run GC to gather these.
In some sense we could just scan the pages without running GC first.
2deb6cf to
81917c9
Compare
Examining the pages while the mutators are running is likely not thread-safe. In principle we could use an alternative stop-the-world mechanism to make sure all threads are in a safe state while we're examining their pages, but piggybacking on the GC stop-the-world phase to do so is more convenient from an implementation perspective. |
81917c9 to
aca69a7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me and the benchmarks suggest there's no problem, but I'd still prefer to have all this under a build-time setting.
|
I already added a stop-a-thread mechanism recently (piggy backing on the safepoint code as you guessed), so you can do that part in a simple round-robin style if you wanted |
aca69a7 to
dd2ebef
Compare
|
Would have been great to also add docs |
|
@d-netto can you please come back and add documentation for this? I agree w/ Valentin: A feature is not done until it is well tested and well documented. (IMO The best approach is to merge in smaller changes at a time, with documentation and tests coming along with each part, so that even if you run out of time and have to set it down, at least what you've merged is high-quality.) |
|
Will add some docs once #53256 gets merged. |
Piggybacks in the sweeping phase of the GC to pretty-print a JSON representation of every page in the pool allocator.
Usage:
Output (truncated to one page & after pretty printing):
{ "address": "0x109dd0000", "object_size": 400, "objects": [ "Task", "Task", "Task", "garbage", "GenericMemory", "garbage", "GenericMemory", "GenericMemory", "garbage", "GenericMemory", "GenericMemory", "Task", "Task", "Task", "garbage", "garbage", "garbage", "String", "garbage", "garbage", "String", "GenericMemory", "GenericMemory", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", "garbage", ] }This proved particularly useful for us when studying fragmentation in some of our workloads, though this profiler may possibly have some repeated functionality compared to the other profilers we already have in
stdlib.