Add support for tracing GC (-profile=gc)

[kinke]

Which requires calling different druntime hooks in the glue layer.

[rainers]

I'm not sure it's worthwhile to support this half-working approach (using different hooks in compiled code, that are missing in pre-compiled libraries, e.g. phobos).

I prefer to just add a proxy around the GC as in https://github.com/dlang/visuald/blob/master/tools/tracegc.d#L238. That needs to be able to capture the stack efficiently, though.

[kinke]

Thx for the input Rainer - yeah a GC wrapper sounds much simpler and more worthwhile, and would also avoid having to adjust the GC2Stack pass (as people would probably be interested in the remaining GC allocations after that pass). - It's just come up at work, where it's apparently a very important tool for performance analysis/tuning.

That needs to be able to capture the stack efficiently, though.

I take it you mean stack trace, as the LoC is obviously not passed directly as for the current tracing hooks after a quick glance.

Edit: Ah I see your implementation already contains backtrace stuff (and much more I would have naively expected). I take it it's working just fine, but currently restricted to Windows and would need to be ported to Posix?

[rainers]

I take it it's working just fine, but currently restricted to Windows and would need to be ported to Posix?

Yes. IIRC it is even limited to Win64 ATM. In my use case (finding leaks in dmd running as a semantic engine) it needs a lot of memory anyway to keep track of every allocation.

BTW: speaking of GC leaks: would it be difficult to implement a code generation pass for --DRT-scanDataSeg=precise that emits pointer locations in the DATA/TLS segments? I suspect I'll have to switch back to compiling with dmd for Visual D's semantic engine because data in the data segment seems to be causing GC leaks, even on Win64.

[kinke]

I'd have to look more deeply into what's required - AFAIK, emitting everything that could contain a pointer to GC-allocated memory into an extra section, for both regular and TLS data segments. OTOH, I don't think it can be implemented as a simple extra LLVM pass - e.g., vtables, TypeInfos and init symbols are probably to be excluded, and also statically allocated class instances if they contain no interesting pointers (vptr being a 'false' pointer that's guaranteed to be there). Does the precise GC in druntime work on Posix too or is it Windows only?

[rainers]

I'd have to look more deeply into what's required - [...]

Your description is pretty much what's required.

Does the precise GC in druntime work on Posix too or is it Windows only?

The precise GC works on all platforms for the heap, but scanning the DATA segment precisely is currently only supported on Windows. Here is my attempt to port it to Linux: https://github.com/dlang/dmd/pull/6630. IIRC dealing with shared libraries didn't work out yet.