You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Sonar integration keeps breaking because they automatically remove projects after a period of inactivity. It adds too little value for the effort required to keep it running, so I am removing it. Newer versions of Clang-Tidy approach Sonar in utility so we will be using only that for now. If the project sees active development in the future again, we may or may not reconsider this.
This PR incorporates the changes from #20.
---------
Co-authored-by: Scott Dixon <[email protected]>
The above-defined theoretical worst-case upper bound H may be prohibitively high for some
106
104
memory-constrained applications.
107
-
It has been shown [Robson 1975] that under a typical workload,
105
+
It has been shown \[Robson 1975] that under a typical workload,
108
106
for a sufficiently high amount of memory available to the allocator which is less than $H$,
109
107
the probability of a (de-)allocation sequence that results in catastrophic fragmentation is low.
110
108
When combined with an acceptable failure probability and a set of adequate assumptions about the behaviors of
@@ -113,7 +111,7 @@ the heap while ensuring a sufficient degree of predictability and reliability.
113
111
The methods of such optimization are outside the scope of this document;
114
112
interested readers are advised to consult with the referred publications.
115
113
116
-
Following some of the ideas from [Herter 2014], this implementation takes caching-related issues into consideration
114
+
Following some of the ideas from \[Herter 2014], this implementation takes caching-related issues into consideration
117
115
by choosing the most recently used memory fragments to minimize cache misses in the application.
118
116
119
117
### Implementation
@@ -238,6 +236,12 @@ If not overridden by the user, for some compilers `O1HEAP_CLZ(x)` will expand to
238
236
For other compilers it will default to a slow software implementation,
239
237
which is likely to significantly degrade the performance of the library.
240
238
239
+
#### O1HEAP_TRACE
240
+
241
+
This option is intended for advanced diagnostics and may be not useful in most applications.
242
+
If defined and is nonzero, makes o1heap invoke `extern` trace functions (implemented in the application)
243
+
on every allocation and deallocation. Please refer to `o1heap.h` for usage details.
244
+
241
245
## Development
242
246
243
247
### Dependencies
@@ -248,15 +252,6 @@ The following tools should be available locally to conduct library development:
248
252
- An AMD64 machine.
249
253
- (optional) Valgrind.
250
254
251
-
### Conventions
252
-
253
-
The codebase shall follow the [Zubax C/C++ Coding Conventions](https://kb.zubax.com/x/84Ah).
254
-
Compliance is enforced through the following means:
255
-
256
-
- Clang-Tidy -- invoked automatically while building the test suite.
257
-
- Clang-Format -- invoked manually as `make format`; enforced in CI/CD automatically.
258
-
- SonarCloud -- invoked by CI/CD automatically.
259
-
260
255
### Testing
261
256
262
257
Please refer to the continuous integration configuration to see how to invoke the tests.
@@ -267,35 +262,33 @@ Update the version number macro in the header file and create a new git tag like
267
262
268
263
### MISRA compliance
269
264
270
-
MISRA compliance is enforced with the help of the following tools:
265
+
MISRA compliance is enforced with the help of:
271
266
272
267
- Clang-Tidy -- invoked automatically during the normal build process.
273
-
- SonarCloud -- invoked as part of the continuous integration build.
274
268
275
269
Every intentional deviation shall be documented and justified in-place using the following notation,
276
270
followed by the appropriate static analyser warning suppression statement:
277
271
278
272
```c
279
273
// Intentional violation of MISRA: <valid reason here>
280
-
// NOSONAR
281
-
// NOLINT
274
+
// NOLINT(*-specific-rule)
282
275
```
283
276
284
277
The list of intentional deviations can be obtained by simply searching the codebase for the above comments.
285
278
286
-
Do not suppress compliance warnings using the means provided by static analysis tools because such deviations
287
-
are impossible to track at the source code level.
288
-
An exception applies for the case of false-positive (invalid) warnings -- those should not be mentioned in the codebase.
289
-
290
279
## Further reading
291
280
292
281
-[Timing-Predictable Memory Allocation In Hard Real-Time Systems](https://publikationen.sulb.uni-saarland.de/bitstream/20.500.11880/26614/1/diss.pdf), J. Herter, 2014.
293
282
-[Worst case fragmentation of first fit and best fit storage allocation strategies](https://academic.oup.com/comjnl/article/20/3/242/751782), J. M. Robson, 1975.
294
283
-[Dynamic Memory Allocation In SQLite](https://sqlite.org/malloc.html) -- on Robson proof and deterministic fragmentation.
295
-
-*[Russian]*[Динамическая память в системах жёсткого реального времени](https://habr.com/ru/post/486650/) -- issues with dynamic memory allocation in modern embedded RTOS and related popular misconceptions.
284
+
-[Динамическая память в системах жёсткого реального времени](https://habr.com/ru/post/486650/) -- issues with dynamic memory allocation in modern embedded RTOS and related popular misconceptions.
296
285
297
286
## Changelog
298
287
288
+
### Next version WIP
289
+
290
+
- Add optional trace events, enabled via the `O1HEAP_TRACE` build-time option.
291
+
299
292
### v2.1
300
293
301
294
- Significantly accelerate (de-)allocation by replacing the naïve log2 implementation with fast CLZ intrinsics;
0 commit comments