Memory Management (Bug 15991)

Erik Noreke 2016-08-30 00:55:29 PDT

Avoid deleting or freeing of memory.

Deleting data and returning memory to the heap results in undeterministic behavior. Heap fragmentation and reuse of memory can cause runtime variations.
If deletes are absolutely required, it must be complete a complete heap release. As an example, buffer deletes and rebuilds – it would be safe to delete all textures and re-specify new textures. However, deleting individual textures would not be allowed. Deleting all textures would clear out the entire texture heap and allow subsequent allocations to be pointer level repeatable. The API needs to contain documentation for implementers on why the deletes are required and how the risk of having the deletes is mitigated so that such information may be referenced in the implementer’s certification documentation.

Comment 1 Erik Noreke 2016-09-19 07:27:15 PDT

Accepted per call 2016-09-19

Comment 2 Erik Noreke 2016-09-20 13:07:24 PDT

Setting QA contact to non-member SCAP mailing list.

Comment 3 Erik Noreke 2016-10-03 07:26:42 PDT

Ajay to add text on fixed sized heaps. 20161003

Comment 4 Ajay Jayaraj 2016-10-31 06:43:47 PDT

Avoid deallocation to the heap

Repeated deallocation (delete/free) to the heap can result in fragmentation and lead to non-deterministic delays in both allocation and deallocation functions.

Note 1: It is acceptable to perform deallocations to fixed size heaps because such heaps do not have issues with fragmentation.

Note 2: If deallocations are absolutely required by the system, it is recommended that the entire heap be deallocated.

Note 3: MISRA-C Rule 118 states "Dynamic heap allocation shall not be used"

Comment 5 Ajay Jayaraj 2016-11-07 08:02:48 PST

Indicated that MISRA Rule 118 is a required rule (vs. what MISRA refers to as advisory)

---

Avoid deallocation to the heap

Repeated deallocation (delete/free) to the heap can result in fragmentation and lead to non-deterministic delays in both allocation and deallocation functions.

Note 1: It is acceptable to perform deallocations to fixed size heaps because such heaps do not have issues with fragmentation.

Note 2: If deallocations are absolutely required by the system, it is recommended that the entire heap be deallocated.

Note 3: MISRA-C Rule 118 (required) states "Dynamic heap allocation shall not be used".

Comment 6 illya@codeplay.com 2016-11-15 02:36:06 PST

If deallocation of any form is implemented should a time limit or time taken parameter be set or received? If received the value returned can be used monitored for profiling or determining within acceptable limits. If use a time limit system a callback stating a failure has occurred.

The same could apply for allocation of memory if house keeping is applied during a call to allocate.

Putting this forward as in my research a SC memory management one of the reasons not to use a non trivial system is because it could get delayed while doing its housekeeping. Delayed and missing a time slice is not acceptable.

Comment 7 illya@codeplay.com 2016-11-22 00:26:13 PST

Please now ignore comment 6. The same idea could be left for the implementation user to wrap the call at the API level if they wish and so simplifying the implementation and not have the overhead in the release build.

No target file or test is named; begin by locating the guideline section covering memory management and compare it with the proposed “Avoid deallocation to the heap” text. Done means documenting the fixed-size-heap exception, full-heap deallocation recommendation, and required MISRA-C Rule 118 wording, while resolving the open timing question.