oldBaseAddr
Locked
 
|
Hi all.
I do not understand the usage of oldBaseAddr. In VM source, oldBaseAddr = getLongFromFileswap(f, swapBytes); ... bytesToShift = memStart - oldBaseAddr; Thanks. Ang Beepeng |
|
|
Hi Ang,
when a snapshot is written the heap is simply written to the file, so all the object addresses in the file are those the objects had in the address space of the process that wrote the snapshot. The start address of the heap is written to the snapshot file's header in the oldBaseAddr field. So nil, which is the first object in the heap, has address oldBaseAddr. So nil's address - oldBaseAddr is zero. i.e. subtracting oldBaseAddr converts an absolute heap address into a releative one where the heap starts at 0.
When a snapshot is loaded, the VM asks the OS to allocate memory for the heap and assigns the start of this memory to memStart. Therefore to load a snapshot file at the new address, memStart, all pointers in the heap must be adjusted by memStart - oldBaseAddr.
HTH
On Mon, Aug 24, 2009 at 11:13 AM, Ang Beepeng <[hidden email]> wrote:
|
|
|
Thank you very much.
Do you mean that during squeak start-up, process of memory allocation somehow make memStart to have value according to the image loaded. And therefore the same as oldBaseAddr which is from the same image. (I know very little about memory allocation in every aspect, sorry about that) The difference is only when one reload a snapshot, without restarting the VM. memStart remain the same, but oldBaseAddr (memStart of another snaphot) is different. Is that correct? Thanks. Ang Beepeng
|
|
|
On Mon, Aug 24, 2009 at 12:48 PM, Ang Beepeng <[hidden email]> wrote:
No. The issue is that memStart is where the OS gives it to you. It could be anywhere. It could also change between two slightly different VMs on the same platform, because one VM might have more code and therefore memStart would end up at a higher address.
So the problem is to load the image at the address that the OS gives you memory in which to load the heap. Writing oldBaseAddr to the image avoids having to update the pointers when writing the image.
The other way around. oldBaseAddr is the base of the heap at the time the snapshot was written. memStart is the start of the heap in the current system that is trying to load the snapshot.
|
|
|
On 24-Aug-09, at 1:09 PM, Eliot Miranda wrote: > > > On Mon, Aug 24, 2009 at 12:48 PM, Ang Beepeng <[hidden email]> > wrote: > > Thank you very much. > > Do you mean that during squeak start-up, process of memory allocation > somehow make memStart to have value according to the image loaded. And > therefore the same as oldBaseAddr which is from the same image. > (I know very little about memory allocation in every aspect, sorry > about > that) > > No. The issue is that memStart is where the OS gives it to you. It > could be anywhere. It could also change between two slightly > different VMs on the same platform, because one VM might have more > code and therefore memStart would end up at a higher address. Which is why the macintosh carbon and iPhone VM's cheat and ask the virtual memory mapping system to map memory at the 500MB boundary. Usually the Virtual Memory subsystem grants the wish and memStart is 500MB. This then is compared to the old base address which usually would be 500MB and the result is zero, so no address adding has to occur. Even if the VMs are different versions this doesn't matter since the boundary is high enough to account for minor VM size changes. This is very important on the iPhone VM, since if we don't need to visit every object in the oops heap we avoid actually paging the page from flash into ram. For WikiServer we end up paging oh say 5.5MB from flash into ram, the other 5MB is left in flash. If we had to remap all the oops then we would end up dragging all 11.5MB from flash into ram. This is less important on os-x since the mmap logic drags all the pages from file to ram memory, used or not. Still we avoid the computational overhead if nothing is moved. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |