[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More heap corruption / allocator lock problems
- Date: Thu, 16 Oct 2003 13:25:16 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: More heap corruption / allocator lock problems
Paul Neelands wrote:
> Regarding solution b)
> If the special "gc" thread approach is used, how does one insure that it is
> run at an appropriate time? i.e. It may not free memory more quickly unless
> the "gc" thread is highest priority, which ends up being effectively the
> same as the list approach but done via a thread and it's overhead.
> Presumably the malloc/free list approach solves this problem and eliminates
> the additional interface complexity of solution a)
Personally I don't like adding a special thread because it increases
bulk and complexity. Even adding it to the IDLE thread forces
requirements on BSP and CPU specific ones.
Till and I have emailed privately with a modified solution.
+ Heap blocks actually ALWAYS have enough memory to be a
SuperCore Chain_Node. This is required because free
blocks are managed as a SuperCore Chain.
+ When free() is called at inappropriate times, it could
do a Chain_Append to a special GC Chain
+ When malloc() is called at appropriate times, it could
free() all blocks on the GC chain.
My one odd thought is that perhaps adding this logic to the
Region manager would be more appropriate so all regions would
have this behavior.
> Paul Neelands
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
>>b) free could be enhanced:
>> if 'free' is called while _Thread_Dispatch_disable_level > 0,
>> it sends its pointer argument to a special "gc" thread which
>> will eventually execute the real 'free'. The synchronization
>> mechanism *must* be nonblocking, of course, to avoid the
>> same kind of problem...
>>While I feel that b) is 'hackish', it could certainly provide
> Another simpler approach to this might be to have a list like you suggest
> but check that it is non-empty on each malloc or free when
> is == 0. It doesn't free memory as quickly as a gc thread would but it
> would get it into
> the heap when it matters.
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985