Hello Guilers, While desperately chasing and related memory leak issues, I came up with the attached rudimentary heap profiler. You can load it and invoking it in a running process: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> (profile-heap) % type self avg obj size 19.7 pair 720,864 16.0 16.3 unknown 594,832 600.8 14.7 struct 536,784 48.2 12.6 bytevector 461,824 1110.2 7.7 stringbuf 281,136 117.8 6.8 pointer 248,688 16.0 5.5 vector 202,815 35.4 4.1 symbol 148,640 32.0 3.1 program 113,824 40.0 1.6 heap-number 59,680 31.8 1.5 string 54,960 32.0 1.4 smob 52,736 38.0 1.3 variable 49,328 22.6 0.8 weak-table 30,144 30.4 0.8 atomic-box 28,528 32.1 0.8 vm-continuation 27,680 32.0 0.7 hash-table 26,736 32.1 0.2 syntax 6,144 48.0 0.1 dynamic-state 4,208 1052.0 0.1 primitive 2,880 16.0 0.1 weak-vector 1,984 18.0 0.0 keyword 752 16.7 0.0 bitvector 672 35.4 0.0 frame 624 39.0 0.0 primitive-generic 608 32.0 0.0 continuation 576 576.0 0.0 fluid 208 29.7 0.0 array 96 48.0 0.0 weak-set 96 48.0 0.0 port 64 32.0 sampled heap: 3.48865 MiB (heap size: 12.78906 MiB) $5 = #t --8<---------------cut here---------------end--------------->8--- It samples the GC-managed heap and counts the number and size of objects of each type. The “unknown” bit is anything that lacks a type tag, such as stacks allocated for delimited continuations by ‘capture_stack’ in libguile. It gives a rough idea of what’s going on but of course it’s intrusive: the profiling process itself allocates memory. The next step will be to run it from GDB so that it’s non-intrusive. I’d be curious to know if people have developed similar tools in this area. Ludo’.