[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