[Vm-dev] mmap, changes to co-ordinate mapping to particular address to avoid oops address remapping at startup time.

John M McIntosh johnmci at smalltalkconsulting.com
Tue Nov 25 21:39:30 UTC 2008


Ok, I check this out, seems ok. I check in the macintosh changes.  I  
assume here if you stick this in VMMaker the
windows and unix version will compile without changes.  If so can you  
update VMMaker then?


On 30-Oct-08, at 5:00 AM, David T. Lewis wrote:

> On Thu, Oct 23, 2008 at 06:52:25PM -0700, John M McIntosh wrote:
>> Well it's not quite a straight forward
>>
>> (a) you need to disable the image read logic I guess this could be in
>> the #define
>>
>> So in  readImageFromFile: f HeapSize: desiredHeapSize StartingAt:
>> imageOffset
>
> John,
>
> Here is another try at it. The idea is to maintain backward  
> compatibility
> with the existing support code, so the Windows, Unix, and RiskOS  
> support
> code require no changes, but you can define your new mmap() allocators
> in sqConfig.h:
>
> #define allocateMemoryMinimumImageFileHeaderSize(heapSize,  
> minimumMemory, fileStream, headerSize) \
>    myMemoryAllocator(heapSize, minimumMemory, fileStream, headerSize)
> #define sqImageFileReadEntireImage(memoryAddress, fileStream,  
> elementSize,  length) \
>    myImageFileReader(memoryAddress, fileStream, elementSize,  length)
>
>> (b) free?
>> Actually I'm not sure who if anyone ummaps memory on exit, however in
>> this case one does need to remember that memory points to the start  
>> of
>> file, not 0+headerSize
>> For testing I've just remember the mmap for the file, and mmap for  
>> the
>> anonymous section.  However I'd guess a Hydra VM would have to do a
>> bit more to remember those
>> two memory locations somewhere since I suspect the ability to startup
>> and shutdown an image is more likely without terminating the process
>> space.
>
> It would be trivial to add this later on, so I think it would be best
> to wait and see if Hydra needs it.
>
> Dave
>
> <Interpreter-readImageFromFile-jmm-dtl.2.cs>

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





More information about the Vm-dev mailing list