This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heapless C/C++


On Sat, Oct 8, 2011 at 3:35 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 8 October 2011 10:48, Shiv Shankar Dayal wrote:
>>> It sounds like all you're proposing is using the stack for dynamic
>>> allocation instead of the heap, then adding a compacting garbage
>>> collector. ?It's easier to just use the heap and make sure you don't
>>> leak memory. It's not that hard.
>>>
>>
>> Yes. This is true that I want to use stack for dynamic memory allocation
>> but I do not want a garbage collector. Garbage collection should happen
>> though RAII.
>
> If you're using RAII consistently and correctly then the problems
> associated with heap memory go away, so you don't need to avoid the
> heap. ?If you're not using RAII correctly, your proposal won't work
> anyway and you'll leak memory. ?So what's the point?
>
> Why is it better to do dynamic allocation on the stack? ?(Answer: it's not.)
>
> You say "A record of all allocated objects by this function has to be
> kept. Also, there will be gaps or fragmentation in Stack because of
> this for which we will have to move allocated area down almost in all
> cases and sometimes up." ?You haven't got rid of heap, you've got rid
> of the stack, making using the stack as complicated as using the heap.
> ?How do you propose to move the area? ?You have to adjust all pointers
> referring to it, which is not possible in the general case (even if
> you scan the process' entire memory to look for pointer-like patterns,
> they could be obfuscated or stored in a file, or outside the process
> in other ways.) ?If the stack needs to grow to call a function, but
> the space it wants to grow into contains dynamically-allocated
> objects, what happens? ?Does the stack skip over that block,
> remembering where to skip back over it when unwinding? ?Your stack is
> no longer contiguous and must keep track of far more information. A
> stack pointer won't work anymore.
>
> There are good reasons why dynamic memory, which has unpredictable
> lifetime, is kept in a separate region from stack memory, which
> doesn't.
>
> I agree the proposal is hopeless.
>

I have not thought over it for more than three days. But here is the simple
answer. You can implement two stacks in one. Keep normal stuff which is not
allocated by our alloca() like function at one end and all other alloca() like
objects at the other end. This would simplify our problems a lot. Yes, this is
very much like existing arrangement of stack and heap where they grow
in opposite direction. By using this mechanism we can minimize the shifting
of objects at the other end only.

-- 
Best regards,
Shiv Shankar Dayal


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]