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

John M McIntosh johnmci at smalltalkconsulting.com
Sat Jul 25 00:23:51 UTC 2009


> so much for that.  gmail seems hopelessly inconsistent form day to  
> day as to whether Reply does reply to all or reply to sender.  Or is  
> it my advancing years??

Eyesight.

Well I did phone Eliot, and said.

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.

In the refactor consider

(a) we allocate a certain amount of memory, this is the file size plus  
some ?unknown? small amount? Upto some maximum.
The maximum in the past can be a fixed amount, or even a value in  
additional to the file size, or percent of file size etc.   Lately it  
seems to be a fixed upper limit.
This is also then altered by the ability of the operating system to  
give you the memory, then we take some min-heap size as a drop dead  
value, which
in my opinion is a wild ass guess. So the value becomes something  
between the min heap size and the requested value, again I don't think  
the developer
has a clue here if it was acceptable.

(b) Allocating the memory may or may not require the use of the file  
since it could be needed for a mmap

(c) Memory can grow or shrink, few platforms offer fail safe shrink  
logic.

(d) After the memory is allocated the file has to be read into it, or  
paged into it, or nothing happens if the file was mmapped in via (a)


--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:   
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================






More information about the Vm-dev mailing list