_Heap_Size_of_user_area question

[Sergei Organov]

Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> If someone could provide some postive feedback on this,
> it would be time to merge it into the development tree.

Well, I'm using it myself all the time since then and haven't
encountered any problems, so my feedback is positive. It obviously
doesn't mean everything is OK with the patch, but I doubt more feedback
could appear until it's merged into the development tree.

If somebody is willing to review the patch before merge, I'd be
thankful and willing to answer questions should they appear.

> 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.

No problems, I've expected something like that. If the patch is somehow
missed please let me know, -- I'll send it again.

Sergei.

> 
> --joel
> 
> 
> Sergei Organov wrote:
> > "Thomas Rauscher" <trauscher at loytec.com> writes:
> >
> 
> >>Hi,
> >>
> >>I've a question regarding _Heap_Size_of_user_area() ...
> >>
> >>I've figured out that it basically returns the front flag of a given
> >>heap block.
> >>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
> >> get 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
> 
> > request.
> > 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
> >