[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??
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
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
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
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
(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:
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev