strangely empty

gonna try unique_ptr

not sure it's actually freeing, but at least it doesn't crash

adapted from Tim's PR

next up: load actual type

kind of annoying, but it doesn't seem we can reliably load them from
the addresses without segfaulting

but I think the problem is that the strings are being GC'd

cuz they're not rooted

this works, but all the strings leak
ugh C is hard

like the Profile does, and the C++ side did before

wonder if we can move this into stacktraces.jl or something to
dedup with Profile

also change Julia representation of raw backtrace elements,
thogh I'm not sure it was breaking anything

thanks to GC.@preserve <3

TODO: is this correct!?

d'oh

This _drastically_ speeds up the tests, for reasons I don't exactly
understand.. I wonder if it was messing up some heuristics and deciding
to interpret the code instead of compiling it, and had some weird
corneer cases in the interpreted code or something? I dunno!

But anyway, this drastically speeds it up, so 🤷 sounds like not our
problem 😊

Instead of allocating a maximum-sized buffer for each backtrace, we keep
a single max-sized buffer as a scratch space, write the backtrace to it,
and then once we know the size, we allocate a right-sized buffer for the
backtrace and copy it over.

Benchmark results (measured time for profiling allocations on internal
Arroyo benchmark, with `skip_every=0`):

This only slightly improves the time to record an alloctions profile:
- Before: 275.082525 seconds
- After: 245.891006 seconds

But it drastically improves the memory usage once the profiling is
completed, according to System Activity Monitor:
- Before: 17.35 GB
- After: 6.92 GB
- (Compared to 350 MB for the same task without profiling)

We could probably slightly improve the time overhead still furthur by
using a single big vector instead of a bunch of individual allocated
buffers, but this is probably about the best we could do in terms of
space usage. This would allow us to eliminate the redundant copying, and
would also amortize away the allocations of the buffers, both of which
should reduce the performance impact. But I'm guessing the time is
mostly dominated by just how long the stack traces are, and there's no
getting around that. At best, we could expect maybe like a 2x-3x
improvement from those changes, I think.

I think these were added to find why it was slow, which was fixed by the
__precompile__, so we don't need them anymore?

the macro is preferred

instead of recording any N allocs

Co-authored-by: Nathan Daly <NHDaly@gmail.com>

profiler

the big dict is not worth the overhead for now

Capitalization.

Fixup some small typos and formatting changes

alloc profiler: add docs and news

alloc profiler: rename structs to match Julia C style

Co-Authored-By: NHDaly@gmail.com

alloc profile: print percentage of allocs missed

alloc profile: record string allocs