[Vm-dev] oops to zero

[Bert Freudenberg]

On Oct 6, 2007, at 15:08 , David T. Lewis wrote:

> On Fri, Oct 05, 2007 at 02:43:21PM +0200, Hans-Martin Mosner wrote:
>>
>> Bert Freudenberg schrieb:
>>>
>>> On Oct 5, 2007, at 5:05 , Keith Hodges wrote:
>>>>
>>>> Indeed you make a good point, if we can pick a good number that
>>>> runtimes can use without traversing the image then great. What  
>>>> number
>>>> should it be?
>>>
>>> I don't think any OS (except for DOS maybe) would guarantee you a
>>> specific start address.
>> It does not need to guarantee a start address but just pick the  
>> same one
>> most of the time (for example, as long as the VM binary stays the  
>> same).
>> I think Squeak already does this. See below for another option.
>>>
>>>> Since OLPC applications have a virtual linux box to themselves  
>>>> can we
>>>> just pick a number that suits us/them?
>>>
>>> I wouldn't think so ... but it is an interesting idea. I will ask  
>>> the
>>> OLPC guys.
>> It's not difficult for a VM to use mmap() on /dev/null (or was it
>> /dev/zero?) to allocate memory for the image to any given address  
>> under
>> linux (as long as the CPU/OS version supports memory at that  
>> address).
>> If a VM did this, it could have a fixed image start address even  
>> across
>> VM versions. Even cooler would be to mmap() the image file  
>> directly with
>> copy-on-write behavior for almost instantaneous startup.
>
> Actually the Unix VM already does use mmap() on /dev/zero to obtain  
> the
> base address, so it is easy to request a specific base address. Ian  
> pointed
> this out to me when I was doing the "32bit clean" patches, and that is
> how I was able to test those changes.
>
> The attached diff shows where to make the change in sqUnixMemory.c.
>
> Note that mmap() will assign its own address if it does not agree with
> the one that you requested. You will need to pick an address that  
> works
> on various versions of the kernel, and on both 32 bit and 64 bit  
> systems
> (or perhaps provide a list of addresses, and let the VM find one that
> works on that particular platform).  The value 0x4000000 seems  
> reasonable
> on a 64 bit AMD Linux 2.6 system, but I did not check to see if it  
> works
> on a 32 bit system, so you may need to experiment a bit.
>
> The OLPC platform has well defined hardware and OS, so it would be  
> good
> to pick a number that works on OLPC and make that the default.

Interesting - I also found that on Linux I can modify the executable  
to disable randomization using the -R flag of setarch:

http://www.linuxcommand.org/man_pages/setarch8.html

Have not tested this yet. And does the image loading logic actually  
check if a remap is necessary?

- Bert -