[Vm-dev] the initial memory allocation interface...

[Igor Stasenko]

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



-- 
Best regards,
Igor Stasenko AKA sig.