All our native libraries (Windows x64) must use our own API for all memory management. Any static lib not doing so is detected and will throw an exception. My current workaround, wrapping all direct calls to OpenUSD in a separate dll, avoids that detection. But without my dll duplicating the OpenUSD API this approach hinders authoring large-scale, multi-staged scenes. Can I instead configure OpenUSD to use our API for all its (de)allocation ops, so I can call directly into it from my feature lib?
USD doesn’t have a replaceable allocator and just uses the process allocator, which some people replace with jemalloc or the sorts.
Somewhat related, there is work to allow swapping the threading library right now. It’s a compile time swap, and perhaps something like that could be inspiration for a pattern to substitute different allocators.
I can’t speak to the appetite others might have for supporting it but I think it might be worth proposing as an issue or, if you could make a more fully featured proposal to the OpenUSD proposals project.
We are facing the same problem, and are not the only ones. For reference, it’s a summary of the discussions around this topic, mainly on the old GoogleGroups mailing list: