[Vm-dev] oops to zero

David T. Lewis lewis at mail.msen.com
Sat Oct 6 13:08:27 UTC 2007


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.

Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqUnixMemory.c.diff
Type: text/x-diff
Size: 1604 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20071006/da94a219/sqUnixMemory.c.bin


More information about the Vm-dev mailing list