joel.sherrill at OARcorp.com
Fri Jun 4 14:04:22 UTC 2004
If someone could provide some postive feedback on this,
it would be time to merge it into the development tree.
Honestly, this got ignored in trying to finalize the
4.6 release series and just hasn't been remembered
since the development tree reopened. Sorry.
Sergei Organov wrote:
> "Thomas Rauscher" <trauscher at loytec.com> writes:
>>I've a question regarding _Heap_Size_of_user_area() ...
>>I've figured out that it basically returns the front flag of a given
>>In my understanding the size encoded in the front flag also includes
>>front flag and back flag.
>>Is this right? If so, the function returns the "user area" + 8.
>>"user area" is the size given to malloc() plus some alignment bytes to
>>a heap page boundary.
>>While this is not an error itself, I'm wondering whether only the
>>function is unluckily named, I have the wrong understanding of what
>>the "user area" is, or the implementation does not match the function
>>intention by accident.
> I believe the implementation is buggy. There are other issues with the
> RTEMS heap management as well, see, e.g., PR rtems/536.
> bout half a year ago I've redesigned RTEMS heap manager and sent
> corresponding patch to this mailing-list. The patch does fix rtems/536
> and it does fix the problem you are asking about. Still I have neither
> positive nor negative response regarding the patch.
> Here is patch description, the whole patch is available from me by
> The patch is against rtems-ss-20030703 to fix PR rtems/536.
> Tested on custom PowerPC-based BSP (32 bit target).
> The improvements are:
> 1. Only one word per used block overhead compared to 2 words + page_size for
> previous implementation while user pointers returned are still aligned on
> page_size boundary.
> 2. New _Heap_Allocate_aligned() routine is provided to request arbitrary
> aligned memory (could be used to implement memalign() call.)
> 3. Heap statistics is gathered at run time providing more information about
> the heap than those available from _Heap_Get_information() while imposing
> little overhead.
> 4. Designed for 16/32/64 bit targets (tested on 32 bit target only).
> 2003-12-24 Sergei Organov <osv at topconrd.ru>
> PR rtems/536
> Heap manager re-implemented to consume less memory and still satisfy
> alignment requirements.
> * src/heap.c, src/heapallocate.c, src/heapextend.c,
> src/heapfree.c, src/heapgetinfo.c, src/heapsizeofuserarea.c,
> src/heapwalk.c, macros/rtems/score/heap.inl,
> inline/rtems/score/heap.inl, include/rtems/score/heap.h:
> re-implemented, refer to heap.h/heap.c for description.
> * src/heapallocatealigned.c: new file.
> * Makefile.am: (HEAP_C_FILES): added src/heapallocatealigned.c
More information about the users