Heap snapshot #42286

vilterp · 2021-09-16T23:30:23Z

We expose a function GC.take_heap_snapshot(stream), which writes a heap snapshot in Chrome's .heapsnapshot JSON format to the given IO stream.

This can be loaded into Chrome Devtools' snapshot viewer to explore the heap and find memory leaks.

Usage

GC.take_heap_snapshot("snapshot.heapsnapshot")

Then open the Chrome Devtools, go to the "Memory" tab, hit the "load" button, choose the file, and you should see something like:

Implementation:

Piggybacks on the mark phase of the garbage collector, which is already traversing all the live objects in the heap. Creates (in C++) a Node object for every object in the heap, and an Edge object for every pointer from one object to another.

Mimicks Node.js/V8's heap snapshotter, which dumps into the same format: https://github.com/nodejs/node/blob/5fd7a72e1c4fbaf37d3723c4c81dce35c149dc84/deps/v8/src/profiler/heap-snapshot-generator.h#L509-L509

TODOS

testing
- perf: demonstrate that this doesn't hurt perf when disabled (what benchmarks can we use?)
- test: invoke this somewhere in the test suite, just to make sure it doesn't segfault?
- see if object sizes sum up to Core.live_bytes()
features
- make take_gc_snapshot call GC.gc within itself
- make wrapper function in Julia so we don't have to use ccall
- capture types of nodes with typeof
- field names
- array indices
- values of strings and symbols
- sizes for strings and symbols
- sizes for arrays
- record roots
  - tasks
  - stack frames
  - get sizes for tasks and stack frames
  - items in thread local storage
  - modules
- idea: Can we indicate which GC Generation an object is in? Can we track that when we walk the heap?
- docs: make sure there are examples of how to call and use it

Problems:

Co-Authored-By: @vchuravy
Co-Authored-By: @NHDaly

src/gc-heap-snapshot.cpp

vilterp · 2021-09-22T16:54:40Z

Would be interesting to think about how this relates to #31534 and its continuation, #33467

jpsamaroo · 2021-09-22T20:23:55Z

It would be great if we had a Julia-native parser and renderer for these snapshots so that we don't have to rely on a browser. Is there any intention of implementing that before this PR is merged? Or is it too complicated to be implemented directly in Julia Base/Stdlibs?

vilterp · 2021-09-22T20:53:07Z

@jpsamaroo the snapshots are written as JSON (we'll write some notes about the format; had to reverse-engineer it); so a separate Julia package could parse and render them somehow. cc @NHDaly

NHDaly · 2021-09-22T21:36:46Z

+1 yeah that's the way to go. It was too weird to try to figure out how to allocate the results in a way we could pass back to Julia, so I think just reading the file back in would be the easiest way to do it. 👍 I also wanna do that and write a conversation to a flamegraph 😁

…

On Wed, Sep 22, 2021, 4:53 PM Pete Vilter ***@***.***> wrote: @jpsamaroo <https://github.com/jpsamaroo> the snapshots are written as JSON (we'll write some notes about the format; had to reverse-engineer it); so a separate Julia package could parse and render them somehow. cc @NHDaly <https://github.com/NHDaly> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMCIELFCONAE2XZJ3GPWG3UDI637ANCNFSM5EFZZY6A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

vilterp · 2021-09-23T15:55:32Z

Looks like the Clang analyzer itself is crashing in analyzegc: https://buildkite.com/julialang/julia-master/builds/3944#30c92244-220b-4565-98eb-0f05921cd398/242-429 😦 Anyone know what's up with that?

Also: what performance benchmarks can we run on this to verify that it's not slowing down GC?

maleadt · 2021-09-23T16:37:32Z

Looks like the snapshots can't be processed by https://heapviz.com/ yet.

Somewhat related: once this works, it would be nice to look into generating dumps for massif too, which has a pretty powerful visualizer that supports analyzing the heap over time (https://apps.kde.org/massif-visualizer/).

vtjnash · 2021-09-23T16:50:04Z

I think it might be confused that _record_gc_edge is defined as JL_NOTSAFEPOINT, but not declared as JL_NOTSAFEPOINT.

static inline void _record_gc_edge(const char *node_type, const char *edge_type,
                                    jl_value_t *a, jl_value_t *b, size_t name_or_index) JL_NOTSAFEPOINT

vtjnash · 2021-09-23T17:02:19Z

base/gcutils.jl

+Devtools Heap Snapshot viewer (.heapsnapshot extension), to the given
+IO stream.
+"""
+function take_heap_snapshot(io)


Suggested change

function take_heap_snapshot(io)

function take_heap_snapshot(io::IOStream)

tried that earlier, but it seems not to be defined yet:

$ make ... LoadError(at "sysimg.jl" line 3: LoadError(at "Base.jl" line 97: LoadError(at "gcutils.jl" line 119: UndefVarError(var=:IOStream))))

looks like this made the builds fail, e.g. https://build.julialang.org/#/builders/63/builds/3778/steps/8/logs/stdio

either we need to get IOStream in scope somehow, or take the annotation back off

taking the annotation back off until we can figure out how to get it in scope in this file… I guess we have to figure out what file IOStream is defined in and make sure it gets included before this

i think this one has been resolved, yeah?

still may be good to acquire the internal lock on io here first also

vtjnash

(partial review)

src/gc-debug.c

vtjnash · 2021-09-23T17:20:56Z

src/gc.c

            else if (flags.how == 3) {
                jl_value_t *owner = jl_array_data_owner(a);
                uintptr_t nptr = (1 << 2) | (bits & GC_OLD);
+                // TODO: Keep an eye on the edge type here, we're _pretty sure_ it's right..
+                gc_heap_snapshot_record_internal_edge(new_obj, owner);


yeah, it is a reshape of a different array (the "owner"), so we can draw the graph * -> a -> owner -> data -> *

huh, so maybe this should just be a normal edge then? We probably need to figure out more precisely what all the edge types mean.

src/gc-heap-snapshot.h

src/gc-heap-snapshot.cpp

vtjnash · 2021-09-23T18:59:41Z

src/gc-heap-snapshot.cpp

+
+
+struct StringTable {
+    typedef unordered_map<string, size_t> MapType;


Suggested change

typedef unordered_map<string, size_t> MapType;

typedef llvm::StringMap<size_t> MapType;

(gives higher performance https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h)

src/gc-heap-snapshot.cpp

vtjnash · 2021-09-23T19:38:36Z

src/gc-heap-snapshot.cpp

+public:
+
+// private:


Suggested change

public:

// private:

// private:

src/gc-heap-snapshot.cpp

vtjnash · 2021-09-24T19:53:09Z

src/gc-heap-snapshot.cpp

+        } else if (type == (jl_datatype_t*)jl_malloc_tag) {
+            name = "<malloc>";


This is just a sentinel value for a. It cannot show up here.

Suggested change

} else if (type == (jl_datatype_t*)jl_malloc_tag) {

name = "<malloc>";

Is that true? We saw it's checked in objprofile_print, which is what we copied it from:

julia/src/gc-debug.c

Lines 688 to 689 in e9960d5

else if (ty == jl_malloc_tag)

jl_safe_printf("#<malloc>");

vtjnash · 2021-09-24T19:57:00Z

src/gc.c

@@ -2403,12 +2422,16 @@ module_binding: {
            }
            void *vb = jl_astaggedvalue(b);
            verify_parent1("module", binding->parent, &vb, "binding_buff");
+            // Record the size used for the box for non-const bindings
+            gc_heap_snapshot_record_internal_edge(binding->parent, b);


b isn't a jl_value_t, so this should fail to compile here

weirdly, it prints a warning here, not an error. We're not sure why. It's on our todo list to deal with this.

(hehe i think we were just gonna cast it to (jl_value_t*) though)

vtjnash · 2021-09-24T20:01:56Z

src/gc.c

@@ -2540,6 +2563,7 @@ mark: {
            if (flags.how == 1) {
                void *val_buf = jl_astaggedvalue((char*)a->data - a->offset * a->elsize);
                verify_parent1("array", new_obj, &val_buf, "buffer ('loc' addr is meaningless)");
+                gc_heap_snapshot_record_internal_edge(new_obj, jl_valueof(val_buf));


val_buf is not a jl_value_t. You can probably charge this size directly against a (e.g. with gc_heap_snapshot_record_hidden_edge, or maybe better yet, when computing the summarysize of a in record_node_to_gc_snapshot)

vtjnash · 2021-09-24T20:03:03Z

src/gc-heap-snapshot.cpp

+        } else if (type == (jl_datatype_t*)jl_buff_tag) {
+            name = "<buffer>";


These can only show up in very specific contexts (jl_binding_t and jl_array_t->data), so it might be better to just avoid passing those here and instead charge their size directly to their parent.

Yeah, we considered doing that, too, but we figured it makes more sense to report them as "internal" edges, which (we think) tells the javascript frontend that there's some object there, but it's not a normal object and it's opaque. That seems like it's the right fit for this kind of value, too? That way we can still ask questions like "what is the size of all the array buffers," in case that was something we were interested in, i guess?

src/gc-heap-snapshot.cpp

vilterp · 2021-09-30T21:35:02Z

@jpsamaroo I wrote a small pure-Julia parser here :) https://github.com/vilterp/HeapSnapshotParser.jl

src/gc.c

vilterp

added the representation of stacks discussed with @vchuravy and @NHDaly; have a couple questions

vilterp · 2021-10-07T03:28:58Z

src/gc-heap-snapshot.cpp

+        snapshot->node_types.find_or_create_string_id("synthetic"),
+        "(stack frame)", // name
+        (size_t)frame, // id
+        1, // size


@vchuravy how should I get the size of a stack frame? (ofc it's jl_gcframe_t, not the whole stack frame). frame->nroots times the size of a pointer or something? 🤔

also, want to attribute the size of the stack overall to the task… how do we get the size of the entire stack? 🤔 you said it's fixed now, but it may not always be

You can get the size of the stack from when copystack. See the gc mark part for task.

I think size of the jl_gcframe_t is (frame->nroots + 2)*sizeof()void*, but you could be double counting if you also measure size of stack.

but you could be double counting if you also measure size of stack

Yeah i was gonna say the same thing. Just doing the size of the whole stack seems reasonable, yeah

vilterp · 2021-10-07T03:31:13Z

Also, Q for @vtjnash or @vchuravy: can we invoke GC.take_heap_snapshot somewhere in the test suite, to make sure it doesn't segfault or deadlock as people make changes to the code around it? Where would be a good place to invoke it?

vchuravy · 2021-10-07T17:24:52Z

src/gc.c

                gc_setmark_buf_(ptls, stkbuf, bits, ta->bufsz);
+                // TODO: attribute size of stack


Here you can add a internal edge to count the ta->bufsz against the task.

src/gc.c

vchuravy · 2021-10-07T17:26:33Z

src/gc.c

@@ -3065,8 +3077,10 @@ static int _jl_gc_collect(jl_ptls_t ptls, jl_gc_collection_t collection)
        // 2.1. mark every object in the `last_remsets` and `rem_binding`
        jl_gc_queue_remset(gc_cache, &sp, ptls2);
        // 2.2. mark every thread local root
+        // TODO: treat these as roots


Suggested change

// TODO: treat these as roots

vchuravy · 2021-10-07T17:30:07Z

src/gc.c

@@ -3065,8 +3077,10 @@ static int _jl_gc_collect(jl_ptls_t ptls, jl_gc_collection_t collection)
        // 2.1. mark every object in the `last_remsets` and `rem_binding`


So we could add:

gc_heap_snapshot_record_root_other(&jl_all_tls_states, "jl_all_tls_states"); for (int t_i = 0; t_i < jl_n_threads; t_i++) { jl_ptls_t ptls2 = jl_all_tls_states[t_i]; gc_heap_snapshot_record_edge_other(&jl_all_tls_states, &ptls2); ....

Or something like that.

vilterp · 2021-11-18T21:43:42Z

src/gc.c

@@ -646,7 +646,7 @@ static int mark_reset_age = 0;

 static int64_t scanned_bytes; // young bytes scanned while marking
 static int64_t perm_scanned_bytes; // old bytes scanned while marking
-static int prev_sweep_full = 1;
+int prev_sweep_full = 1;


it seems that this is always set to 1? i.e. set to 1 here and never changed anywhere else? so it'd have no effect

no i think it's set, here:
https://github.com/vilterp/julia/blob/2b2c3ab4db8c35f4deb8a44330dc765e73e61647/src/gc.c#L3261

Jameson suggested this change. the idea is to make sure that we're only doing the GC Mark edge-reporting during the second GC, since our call to jl_gc_collect(JL_GC_FULL) does two mark+sweeps: 1. mark, 2. sweep FULL, 3. mark, 4. sweep INCREMENTAL. Step 3 will be a full mark, because all mark bits have been reset. :)

oh I see, this variable was already defined here (and set elsewhere, before this commit), but you added an extern declaration to heap-snapshot.h so we could check it there… gotcha. wasn't reading the diff close enough. nice change!

vilterp · 2021-12-09T04:28:45Z

Rebased onto master; appears to still work (we need more tests lol)

vilterp · 2021-12-09T05:24:44Z

@NHDaly seems like the rebase broke fieldpath_for_slot_helper… I'm seeing this on the backports to release-1.6 and release-1.7 too. Let's debug sometime; maybe I messed something up due to git conflicts.

signal (11): Segmentation fault: 11
in expression starting at REPL[2]:1
union_isinlinable at /Users/vilterp/code/julia/src/datatype.c:269
ijl_islayout_inline at /Users/vilterp/code/julia/src/datatype.c:301 [inlined]
ijl_stored_inline at /Users/vilterp/code/julia/src/datatype.c:308
_fieldpath_for_slot_helper at /Users/vilterp/code/julia/src/gc-heap-snapshot.cpp:294
_fieldpath_for_slot_helper at /Users/vilterp/code/julia/src/gc-heap-snapshot.cpp:295
_fieldpath_for_slot_helper at /Users/vilterp/code/julia/src/gc-heap-snapshot.cpp:295
_fieldpath_for_slot at /Users/vilterp/code/julia/src/gc-heap-snapshot.cpp:313
_gc_heap_snapshot_record_object_edge at /Users/vilterp/code/julia/src/gc-heap-snapshot.cpp:420
gc_heap_snapshot_record_object_edge at /Users/vilterp/code/julia/src/./gc-heap-snapshot.h:68 [inlined]
gc_mark_scan_obj8 at /Users/vilterp/code/julia/src/gc.c:1962 [inlined]
gc_mark_loop at /Users/vilterp/code/julia/src/gc.c:2265
_jl_gc_collect at /Users/vilterp/code/julia/src/gc.c:3094
ijl_gc_collect at /Users/vilterp/code/julia/src/gc.c:3320
jl_gc_take_heap_snapshot at /Users/vilterp/code/julia/src/gc-heap-snapshot.cpp:161
take_heap_snapshot at ./gcutils.jl:116 [inlined]

IanButterworth · 2022-02-02T21:40:26Z

Any chance this could sneak into 1.8?

tkf · 2022-02-03T03:32:45Z

object addresses (64 bit) may truncated when put into JS numbers

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER says

The Number.MAX_SAFE_INTEGER constant represents the maximum safe integer in JavaScript (2^53 - 1).

x86-64 uses 48 bits virtual address space and ARM uses up to 52 bits, IIUC https://developer.arm.com/documentation/101811/0101/Address-spaces-in-AArch64

So, isn't JS number enough for the memory addresses (for now)?

IanButterworth · 2022-02-03T03:45:07Z

Just a quick note. I just tried rebasing this on current master, and gave it a go, and it worked at first after boot, but failed with similar errors to #42286 (comment) after running some intensive code.

It might be helpful to note that I did have to use Chrome Canary, because the "load" button on the memory tab did nothing on latest chrome dev tools.

I guess the segfault might be due to type mismatches reported during build:

/Users/ian/Documents/GitHub/julia/src/gc.c:1962:49: warning: incompatible pointer types passing 'char *' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
            gc_heap_snapshot_record_object_edge(parent, *slot, slot);
                                                ^~~~~~
./gc-heap-snapshot.h:66:68: note: passing argument to parameter 'from' here
static inline void gc_heap_snapshot_record_object_edge(jl_value_t *from, jl_value_t *to, void* slot) JL_NOTSAFEPOINT {
                                                                   ^
/Users/ian/Documents/GitHub/julia/src/gc.c:1998:49: warning: incompatible pointer types passing 'char *' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
            gc_heap_snapshot_record_object_edge(parent, *slot, slot);
                                                ^~~~~~
./gc-heap-snapshot.h:66:68: note: passing argument to parameter 'from' here
static inline void gc_heap_snapshot_record_object_edge(jl_value_t *from, jl_value_t *to, void* slot) JL_NOTSAFEPOINT {
                                                                   ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2033:49: warning: incompatible pointer types passing 'char *' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
            gc_heap_snapshot_record_object_edge(parent, *slot, slot);
                                                ^~~~~~
./gc-heap-snapshot.h:66:68: note: passing argument to parameter 'from' here
static inline void gc_heap_snapshot_record_object_edge(jl_value_t *from, jl_value_t *to, void* slot) JL_NOTSAFEPOINT {
                                                                   ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2426:51: warning: incompatible pointer types passing 'jl_module_t *' (aka 'struct _jl_module_t *') to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
            gc_heap_snapshot_record_internal_edge(binding->parent, b);
                                                  ^~~~~~~~~~~~~~~
./gc-heap-snapshot.h:71:70: note: passing argument to parameter 'from' here
static inline void gc_heap_snapshot_record_internal_edge(jl_value_t *from, jl_value_t *to) JL_NOTSAFEPOINT {
                                                                     ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2426:68: warning: incompatible pointer types passing 'jl_binding_t *' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
            gc_heap_snapshot_record_internal_edge(binding->parent, b);
                                                                   ^
./gc-heap-snapshot.h:71:88: note: passing argument to parameter 'to' here
static inline void gc_heap_snapshot_record_internal_edge(jl_value_t *from, jl_value_t *to) JL_NOTSAFEPOINT {
                                                                                       ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2814:34: warning: incompatible pointer types passing '_Atomic(struct _jl_task_t *)' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
    gc_heap_snapshot_record_root(ptls2->current_task, "current task");
                                 ^~~~~~~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2816:34: warning: incompatible pointer types passing '_Atomic(struct _jl_task_t *)' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
    gc_heap_snapshot_record_root(ptls2->current_task, "root task");
                                 ^~~~~~~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2819:38: warning: incompatible pointer types passing '_Atomic(struct _jl_task_t *)' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
        gc_heap_snapshot_record_root(ptls2->current_task, "next task");
                                     ^~~~~~~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2823:38: warning: incompatible pointer types passing '_Atomic(struct _jl_task_t *)' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
        gc_heap_snapshot_record_root(ptls2->current_task, "previous task");
                                     ^~~~~~~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2827:38: warning: incompatible pointer types passing '_Atomic(struct _jl_task_t *)' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
        gc_heap_snapshot_record_root(ptls2->current_task, "previous exception");
                                     ^~~~~~~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2839:34: warning: incompatible pointer types passing 'jl_module_t *' (aka 'struct _jl_module_t *') to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
    gc_heap_snapshot_record_root(jl_main_module, "main_module");
                                 ^~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2861:42: warning: incompatible pointer types passing 'jl_typemap_entry_t *' (aka 'struct _jl_typemap_entry_t *') to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
            gc_heap_snapshot_record_root(v, "type_map");
                                         ^
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {
                                                            ^
/Users/ian/Documents/GitHub/julia/src/gc.c:2866:38: warning: incompatible pointer types passing 'jl_array_t *' to parameter of type 'jl_value_t *' (aka 'struct _jl_value_t *') [-Wincompatible-pointer-types]
        gc_heap_snapshot_record_root(jl_all_methods, "all_methods");
                                     ^~~~~~~~~~~~~~
./gc-heap-snapshot.h:51:61: note: passing argument to parameter 'root' here
static inline void gc_heap_snapshot_record_root(jl_value_t *root, char *name) JL_NOTSAFEPOINT {

Update: It didn't segfault with a minimal MWE while investigating the issue here #42566 (comment)

base/gcutils.jl

vtjnash · 2022-02-03T19:57:34Z

@IanButterworth there seems to be a moderate number of TODO checkboxes left, and it needs to be gotten to a non-draft state where it is ready for review. There is about a week until the branch for that to get in though.

vilterp · 2022-02-03T21:40:09Z

Hey @IanButterworth, glad you were able to get it to run, at least in a simple case!

@NHDaly and I have been focusing on finishing the allocation profiler (#43868) for 1.8, so we've put this on the back burner. There's the segfault we've been running into in the field path code (having to do with inlined structs), plus some other check boxes on the list.

IanButterworth · 2022-02-03T21:47:37Z

I'm being greedy. Both are really helpful. Thanks for taking them both on!

If I can spare free time to helping debug the segfault here I'll try.

NHDaly · 2022-02-04T19:29:03Z

Jeff told me that Christine was very interested in this too.

@chflood: if you would like to collaborate on the Heap Snapshot tool, we'd love to get some help with it! There are just so many code paths in GC and little edge cases that kept us stuck on this PR.

@IanButterworth: yay, thanks for the help! Excited to get more eyes and arms on it! 💪

vilterp · 2022-02-07T17:02:08Z

Hey @chflood, thanks for checking it out :) Your invocation looks fine — did your make -j succeed on the branch? 🤔 Also feel free to ping me on the Julia Slack for further debugging; happy to work with you on this!

NHDaly · 2022-02-11T16:42:42Z

I've added this idea to the PR description:

idea: Can we indicate which GC Generation an object is in? Can we track that when we walk the heap?

whatsthecraic · 2022-06-02T14:05:37Z

src/gc.c

        gc_mark_queue_obj(gc_cache, sp, ptls2->previous_exception);
+        gc_heap_snapshot_record_root(ptls2->current_task, "previous exception");
+    }


shouldn't this be gc_heap_snapshot_record_root(ptls2->previous_exception, "previous exception");. Similar comment for the lines above.

Yes, i think you're right! 👍 👍 👍 Thanks @whatsthecraic

Good call. Fixed in e732d48.

src/gc.c

@whatsthecraic

…_thread_local Co-Authored-By: Dean De Leo <[email protected]> Co-Authored-By: @whatsthecraic

vchuravy · 2022-09-23T09:58:40Z

Closed in favor of #46862

NHDaly force-pushed the pv-heap-snapshot branch from 8d51726 to b391f44 Compare September 17, 2021 14:11

vilterp commented Sep 17, 2021

View reviewed changes

src/gc-heap-snapshot.cpp Show resolved Hide resolved

JeffBezanson added the GC Garbage collector label Sep 17, 2021

vtjnash reviewed Sep 23, 2021

View reviewed changes

This comment has been minimized.

Sign in to view

vtjnash reviewed Sep 23, 2021

View reviewed changes

vilterp mentioned this pull request Sep 24, 2021

Build fails on macOS with Xcode 13.0 (but passes with Xcode 12.5.1) #42346

Closed

vilterp force-pushed the pv-heap-snapshot branch from b95820a to e9960d5 Compare September 24, 2021 17:06

vtjnash reviewed Sep 24, 2021

View reviewed changes

vchuravy reviewed Sep 30, 2021

View reviewed changes

src/gc.c Outdated Show resolved Hide resolved

src/gc.c Outdated Show resolved Hide resolved

src/gc.c Show resolved Hide resolved

vilterp commented Oct 7, 2021

View reviewed changes

vchuravy reviewed Oct 7, 2021

View reviewed changes

src/gc.c Show resolved Hide resolved

vchuravy reviewed Oct 7, 2021

View reviewed changes

vilterp mentioned this pull request Oct 14, 2021

Garbage Profiler vilterp/julia#2

Closed

1 task

quinnj mentioned this pull request Oct 14, 2021

glibc is optimized for memory allocations microbenchmarks #42566

Open

vilterp mentioned this pull request Oct 15, 2021

Garbage profiler #42658

Closed

4 tasks

vilterp commented Nov 18, 2021

View reviewed changes

vilterp and others added 2 commits December 8, 2021 23:00

add empty files

44a74ea

Initial dummy implementation

e207adf

vilterp added 2 commits December 8, 2021 23:15

unbreak partr.c

fb4fbd3

remove println

6ab9e15

vilterp force-pushed the pv-heap-snapshot branch from 2c39875 to 6ab9e15 Compare December 9, 2021 04:24

put things back I accidentally removed in the rebase

e8b32da

NHDaly assigned NHDaly and unassigned NHDaly Dec 20, 2021

IanButterworth reviewed Feb 3, 2022

View reviewed changes

base/gcutils.jl Outdated Show resolved Hide resolved

IanButterworth reviewed Feb 3, 2022

View reviewed changes

base/gcutils.jl Show resolved Hide resolved

vilterp and others added 3 commits February 3, 2022 01:55

add wrapper function

00f5451

Merge branch 'master' into pv-heap-snapshot

227cf9b

fix syntax error in makefile

07b3ba1

whatsthecraic reviewed Jun 2, 2022

View reviewed changes

src/gc.c Show resolved Hide resolved

Fix copy/paste typos in gc_heap_snapshot_record_roots for jl_gc_queue…

e732d48

…_thread_local Co-Authored-By: Dean De Leo <[email protected]> Co-Authored-By: @whatsthecraic

apaz-cli mentioned this pull request Sep 22, 2022

Heap Snapshot #46862

Merged

vchuravy closed this Sep 23, 2022

vilterp mentioned this pull request Oct 21, 2022

Help with Julia profiling support? DataDog/dd-trace-go#1534

Closed

nickrobinson251 mentioned this pull request Dec 8, 2022

Add heap snapshot endpoint JuliaPerf/ProfileEndpoints.jl#12

Merged

	function take_heap_snapshot(io)
	function take_heap_snapshot(io::IOStream)



		struct StringTable {
		typedef unordered_map<string, size_t> MapType;

	typedef unordered_map<string, size_t> MapType;
	typedef llvm::StringMap<size_t> MapType;

		} else if (type == (jl_datatype_t*)jl_malloc_tag) {
		name = "<malloc>";

		} else if (type == (jl_datatype_t*)jl_buff_tag) {
		name = "<buffer>";

		gc_setmark_buf_(ptls, stkbuf, bits, ta->bufsz);
		// TODO: attribute size of stack

		@@ -3065,8 +3077,10 @@ static int _jl_gc_collect(jl_ptls_t ptls, jl_gc_collection_t collection)
		// 2.1. mark every object in the `last_remsets` and `rem_binding`

Heap snapshot #42286

Heap snapshot #42286

Conversation

vilterp commented Sep 16, 2021 • edited Loading

vilterp commented Sep 22, 2021

jpsamaroo commented Sep 22, 2021 • edited Loading

vilterp commented Sep 22, 2021

NHDaly commented Sep 22, 2021 via email

vilterp commented Sep 23, 2021

maleadt commented Sep 23, 2021

vtjnash commented Sep 23, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

vtjnash left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NHDaly Sep 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vilterp commented Sep 30, 2021

vilterp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vilterp commented Oct 7, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vilterp Nov 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vilterp commented Dec 9, 2021 • edited Loading

vilterp commented Dec 9, 2021 • edited Loading

IanButterworth commented Feb 2, 2022

tkf commented Feb 3, 2022

IanButterworth commented Feb 3, 2022 • edited Loading

vtjnash commented Feb 3, 2022

vilterp commented Feb 3, 2022

IanButterworth commented Feb 3, 2022

NHDaly commented Feb 4, 2022

vilterp commented Feb 7, 2022

NHDaly commented Feb 11, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vchuravy commented Sep 23, 2022

vilterp commented Sep 16, 2021 •

edited

Loading

jpsamaroo commented Sep 22, 2021 •

edited

Loading

NHDaly Sep 27, 2021 •

edited

Loading

vilterp commented Oct 7, 2021 •

edited

Loading

vilterp Nov 18, 2021 •

edited

Loading

vilterp commented Dec 9, 2021 •

edited

Loading

vilterp commented Dec 9, 2021 •

edited

Loading

IanButterworth commented Feb 3, 2022 •

edited

Loading