[Vm-dev] oops to zero
bert at freudenbergs.de
Tue Oct 9 20:26:42 UTC 2007
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
>>>> 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
>> 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
>>> 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
>> linux (as long as the CPU/OS version supports memory at that
>> If a VM did this, it could have a fixed image start address even
>> 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
> base address, so it is easy to request a specific base address. Ian
> 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
> on various versions of the kernel, and on both 32 bit and 64 bit
> (or perhaps provide a list of addresses, and let the VM find one that
> works on that particular platform). The value 0x4000000 seems
> on a 64 bit AMD Linux 2.6 system, but I did not check to see if it
> 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
> 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:
Have not tested this yet. And does the image loading logic actually
check if a remap is necessary?
- Bert -
More information about the Vm-dev