From 88097a250f32aa533c797dc499cdbd6e539c1cc1 Mon Sep 17 00:00:00 2001 From: Chen <50514813+dota17@users.noreply.github.com> Date: Mon, 10 Feb 2020 21:03:57 +0800 Subject: [PATCH 1/3] Update README.md : add a FAQ about memory release --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index c9750e513f..e4183f14f5 100644 --- a/README.md +++ b/README.md @@ -1381,6 +1381,18 @@ This library will not support comments in the future. If you wish to use comment By default, the library does not preserve the **insertion order of object elements**. This is standards-compliant, as the [JSON standard](https://tools.ietf.org/html/rfc8259.html) defines objects as "an unordered collection of zero or more name/value pairs". If you do want to preserve the insertion order, you can specialize the object type with containers like [`tsl::ordered_map`](https://github.com/Tessil/ordered-map) ([integration](https://github.com/nlohmann/json/issues/546#issuecomment-304447518)) or [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map) ([integration](https://github.com/nlohmann/json/issues/485#issuecomment-333652309)). +### Memory Release + +We checked with Valgrind and the Clang Sanitizers that there are no memory leaks. + +If you find that a prasering program with this library does not release memory, please consider these case and it maybe unrelated to this library. + +- Case 1: Your program is compiled with glibc. + + > There is a tunable threshold that glibc uses to decide whether to actually return memory to the system or whether to cache it for later reuse. If in your program you make lots of small allocations and those small allocations are not a contiguous block and are presumably below the threshold, then they will not get returned to the OS. +Here is a related issue [#1924](https://github.com/nlohmann/json/issues/1924). +Also you can check your program under windows to ensure whether there are memory leaks. + ### Further notes - The code contains numerous debug **assertions** which can be switched off by defining the preprocessor macro `NDEBUG`, see the [documentation of `assert`](https://en.cppreference.com/w/cpp/error/assert). In particular, note [`operator[]`](https://nlohmann.github.io/json/classnlohmann_1_1basic__json_a233b02b0839ef798942dd46157cc0fe6.html#a233b02b0839ef798942dd46157cc0fe6) implements **unchecked access** for const objects: If the given key is not present, the behavior is undefined (think of a dereferenced null pointer) and yields an [assertion failure](https://github.com/nlohmann/json/issues/289) if assertions are switched on. If you are not sure whether an element in an object exists, use checked access with the [`at()` function](https://nlohmann.github.io/json/classnlohmann_1_1basic__json_a73ae333487310e3302135189ce8ff5d8.html#a73ae333487310e3302135189ce8ff5d8). From 42566c6befcd65be2490f9867413f2c26fc7c30c Mon Sep 17 00:00:00 2001 From: Chen <50514813+dota17@users.noreply.github.com> Date: Mon, 17 Feb 2020 15:40:52 +0800 Subject: [PATCH 2/3] Update README.md --- README.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index e4183f14f5..bb65bc0deb 100644 --- a/README.md +++ b/README.md @@ -1383,15 +1383,12 @@ By default, the library does not preserve the **insertion order of object elemen ### Memory Release -We checked with Valgrind and the Clang Sanitizers that there are no memory leaks. +We checked with Valgrind and the Address Sanitizer (ASAN) that there are no memory leaks. -If you find that a prasering program with this library does not release memory, please consider these case and it maybe unrelated to this library. +If you find that a prasering program with this library does not release memory, please consider the following case and it maybe unrelated to this library. -- Case 1: Your program is compiled with glibc. - - > There is a tunable threshold that glibc uses to decide whether to actually return memory to the system or whether to cache it for later reuse. If in your program you make lots of small allocations and those small allocations are not a contiguous block and are presumably below the threshold, then they will not get returned to the OS. +**Your program is compiled with glibc.** There is a tunable threshold that glibc uses to decide whether to actually return memory to the system or whether to cache it for later reuse. If in your program you make lots of small allocations and those small allocations are not a contiguous block and are presumably below the threshold, then they will not get returned to the OS. Here is a related issue [#1924](https://github.com/nlohmann/json/issues/1924). -Also you can check your program under windows to ensure whether there are memory leaks. ### Further notes From 2ccdfebaa77ba6e032cd2076af9235a6b22fae45 Mon Sep 17 00:00:00 2001 From: chenguoping Date: Sat, 14 Mar 2020 18:10:55 +0800 Subject: [PATCH 3/3] fix typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index bb65bc0deb..8aa4759153 100644 --- a/README.md +++ b/README.md @@ -1385,7 +1385,7 @@ By default, the library does not preserve the **insertion order of object elemen We checked with Valgrind and the Address Sanitizer (ASAN) that there are no memory leaks. -If you find that a prasering program with this library does not release memory, please consider the following case and it maybe unrelated to this library. +If you find that a parsing program with this library does not release memory, please consider the following case and it maybe unrelated to this library. **Your program is compiled with glibc.** There is a tunable threshold that glibc uses to decide whether to actually return memory to the system or whether to cache it for later reuse. If in your program you make lots of small allocations and those small allocations are not a contiguous block and are presumably below the threshold, then they will not get returned to the OS. Here is a related issue [#1924](https://github.com/nlohmann/json/issues/1924).