[Vm-dev] the initial memory allocation interface...
siguctua at gmail.com
Sat Jul 25 14:48:04 UTC 2009
2009/7/25 David T. Lewis <lewis at 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
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
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? :)
Igor Stasenko AKA sig.
More information about the Vm-dev