2009/7/25 David T. Lewis lewis@mail.msen.com:
On Fri, Jul 24, 2009 at 05:23:51PM -0700, John M McIntosh wrote:
Really the whole issue is the memory allocation, read into memory, grow shrink can be re-done, as you noticed it started simple with a malloc() then grew into something more complicated and twisted trying not to modify code in VMMaker, so you could build with old src code yet get newer memory allocation logic.
I'm somewhat responsible for the complicated and twisted part of this, which could easily be extended to something only slightly more complicated and twisted if the only motivation is to answer the size of the allocated memory as a by-product of the allocation request.
But what is the motivation for the question? Is the concern just to be able to release memory back to the platform, or is there a more general need for a memory allocation interface to support future object memory designs?
I remember i wrote couple of words about memory allocation and its limitations in current implementation. Mainly my concerns are: - be able to reallocate the memory (shrinking/growing), not only allocate/deallocate
my idea is to use a _single_ memory allocation function:
void * sqRealloc(void * memory, uint size);
- if memory argument is nil -> then function should allocate a new block. - if memory is not nil -> then fuction should try allocate enough space to fit the requested size without moving the memory but if memory block has to be moved during reallocation - then returned pointer can be not the same as what is passed to function.
- if you pass size= 0 it should deallocate the memory block
the VM should take care if memory block were moved as a result of reallocation (like relocating object memory , what it already does when loading new image).
What could be simpler? :)
Dave