I have a substantial C project that has been using the Boehm GC for a while now; it was built from scratch, and it has used the Boehm GC since day one, and its type-allocation behavior is well-known.
Currently, it uses GC_MALLOC() and GC_MALLOC_ATOMIC(), and it has acceptable (tolerable) performance. But because all of its types are well-known, and the project is generally isolated from the rest of the C ecosystem (it doesn't link anything outside libc), it seems not unreasonable to me to switch the project over to primarily use GC_malloc_explicitly_typed(). Many of the project's types mix-and-match raw values and pointers, so in theory, this should provide a performance boost during a collection by allowing the collector to be precise instead of conservative on all the types allocated through it. (It may not be a lot of a performance boost, but I still want to be as nice to the garbage collector as I can.)
That said, gc_typed.h has all sorts of warning messages at the top about using GC_malloc_explicitly_typed():
/*
* Some simple primitives for allocation with explicit type information.
* Facilities for dynamic type inference may be added later.
* Should be used only for extremely performance critical applications,
* or if conservative collector leakage is otherwise a problem (unlikely).
* Note that this is implemented completely separately from the rest
* of the collector, and is not linked in unless referenced.
* This does not currently support GC_DEBUG in any interesting way.
*/
and this:
/* Returns a conservative approximation in the */
/* (unlikely) case of insufficient memory to build */
/* the descriptor. Calls to GC_make_descriptor */
/* may consume some amount of a finite resource. This */
/* is intended to be called once per type, not once */
/* per allocation. */
I'm really not convinced any of those are issues for me, and my code is performance-critical, and the collector does come up hot in some of my profiling. I don't think I need GC_DEBUG — leastaways, I've never felt the need to debug the heap. I have no problem with invoking GC_make_descriptor() for every type I need to allocate, and I have no problem with invoking that function a predictable constant number of times at program startup.
It seems like my code is a perfect candidate for using GC_malloc_explicitly_typed(), but the number and scope of those warning messages still give me pause, and they almost seem to imply that the explicitly_typed function will at some point be deleted in favor of a "better" interface. So my question is simply:
Has anyone using GC_malloc_explicitly_typed() found any unstated or non-obvious drawbacks to using it?
