Allocator Propagation Issues with std::pmr in nlohmann::json: Limitations

[ankitghevariya]

Description

I was trying to use the library with std::pmr support by replacing the internal containers with std::pmr::map and std::pmr::vector. Initially, I faced compilation errors because std::map and std::pmr::map have different template parameters (due to different allocators). To work around this, I created template aliases matching the expected signature, which allowed the code to compile.

However, when I tried adding values to the JSON object, I encountered a static assertion failure. After investigating, I found that basic_json does not provide a constructor that accepts an allocator, unlike other standard containers. As a result, the internal PMR containers are default-constructed without a proper allocator, which causes allocator mismatch errors during compile operations like insertions.

This is a high-priority issue

Reproduction steps

Just compile the attached minimal code example.

g++ -std=c++17 -o pmr_json pmr_json.cpp

Expected vs. actual results

Expected:
After configuring basic_json with std::pmr-compatible containers and strings, I expected to be able to construct and use JSON objects with custom memory resources (e.g., std::pmr::monotonic_buffer_resource) without errors. Specifically, I expected that:

• Allocator-aware containers inside basic_json would receive the supplied std::pmr::polymorphic_allocator.
• Operations like assignment (obj["key"] = value) would work as with the default basic_json, but using the custom allocator.

Actual:

• While compilation succeeded with compatible template aliases, runtime operations on the JSON object failed with a static assertion or allocator mismatch errors.
• The root cause is that basic_json does not propagate the allocator to internal containers. It default-constructs internal members (e.g., map, vector, string) without using the provided polymorphic_allocator, leading to static assertion.

Note:
PMR support would be very helpful for controlling memory usage more precisely, especially in performance-critical or embedded applications. Having a clear path or official support for std::pmr with basic_json would make integration much smoother.

Minimal code example

#include <iostream>
#include <memory_resource>
#include <nlohmann/json.hpp>

// Template alias to pass polymorphic allocators to nlohmann::json
#if 1
template<typename Key, typename T, typename Ignored, typename Allocator>
using pmr_compatible_map = std::map<Key, T, std::less<Key>, Allocator>;

template<typename T, typename Allocator>
using pmr_compatible_vector = std::vector<T, Allocator>;

using pmr_string = std::basic_string<char, std::char_traits<char>, std::pmr::polymorphic_allocator<char>>;
#endif

using json_pmr = nlohmann::basic_json<
    pmr_compatible_map,
    pmr_compatible_vector,
    pmr_string,
    bool,
    int64_t,
    uint64_t,
    double,
    std::pmr::polymorphic_allocator>;

int main()
{
    std::pmr::monotonic_buffer_resource arena(10240);
    std::pmr::polymorphic_allocator<char> alloc(&arena);

    // Create a polymorphic string using the allocator
    pmr_string str(alloc);
    str = "Hello, PMR world!";
    std::cout << str << std::endl;

    json_pmr obj;
    obj["name"] = "Ankit Ghevariya";  // ❌ Static assertion failure here: no allocator was passed to the object

    return 0;
}

Error messages

Note: The full error message is quite large, so I'm not pasting it here. I've attached a screenshot showing the last lines of the error output for reference.

Compiler and operating system

• OS: Ubuntu 24.04.2 LTS
• Compiler: GCC 13.3.0 (g++ (Ubuntu 13.3.0-6ubuntu2~24.04))
• C++ Standard: C++17 (-std=c++17)

Library version

• nlohmann/json version: 3.12.0

Validation

• The bug also occurs if the latest version from the develop branch is used.
• I can successfully compile and run the unit tests.

[ankitghevariya]

@nlohmann We are trying to address some of the memory-related issues mentioned in #1924 by exploring the use of std::pmr.

Adding std::pmr support to basic_json could help in projects where memory control is important, such as embedded systems or performance-sensitive applications. In our case, we're working in an embedded environment and using a custom memory resource could help reduce fragmentation and improve memory usage.

This kind of support could also help avoid allocator-related problems and make integration smoother for projects that already use polymorphic memory resources.

[github-actions]

This issue has been marked as stale because it has been open for 90 days without activity. If this issue is still relevant, please add a comment or remove the "stale" label. Otherwise, it will be closed in 10 days. Thank you for helping us prioritize our work!

[ankitghevariya]

Yes, this issue is still relevant and important.

Context

• nlohmann::json currently does not allow selecting a custom allocator.
• Because of this, we cannot integrate with C++17’s std::pmr facilities (e.g., monotonic_buffer_resource, unsynchronized_pool_resource).
• This prevents allocating JSON objects into a bounded arena and reclaiming the entire arena once JSON operations are complete.

Why this matters

• In workloads with large or frequent JSON operations, heap fragmentation accumulates and memory is retained longer than necessary.
• Without pmr, memory cannot be efficiently released in bulk, which is crucial in long-running processes or memory-constrained environments (e.g., embedded systems, servers handling many requests).

Workaround status

• The suggested workaround using malloc_trim(0) is not advisable for production:
  • It forces a global trim of the heap, affecting the entire process and all libraries, not just nlohmann::json.
  • It introduces performance overhead and unpredictable side effects.
• A library-level solution via allocator configurability would be far cleaner and safer.

Impact

• Developers are forced to either accept increased memory overhead. This makes nlohmann::json less suitable for performance-sensitive or memory-constrained environments where pmr would be a natural fit.

Request

Please keep this issue open. Adding support for custom allocators (e.g., via an Allocator template parameter or a predefined json_pmr specialization) would make nlohmann::json significantly more robust for modern C++ applications.