I note that on some versions of mmap you can speicify a starting address. Therefore if it works you could avoid having to swizzle the pointers when you access the image since they would never change. Otherwise you are back to updating all the object slots at load time.
The method ObjectMemory>>adjustAllOopsBy in my image was last updated by you, I believe (JMM 11/18/2000 17:50). A comment in it says, "Note: Don't bypass this method even if bytesToShift is zero until the RootBit problem has been fixed in the appropriate places", and the code to shortcut the method when bytesToShift = 0 is commented out. I don't see anything new in my .changes file, so I am assuming the comment is current.
I don't know what the RootBit problem is, but the section of code that would be bypassed if the comment were removed is the code that adjusts all of the references, and also clears the RootBit for each object. So if the comment is still correct, then even if the image reloads at the same place, don't you need to still clear each object's RootBit? Or did I misunderstand your point, above?
--- Noel
Hello,
Sorry I couldn't find mail list archive.
1) Where are the .cs files for the OSProcess?
2) what files are necessary to run?
Regards, Vasili
__________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
On Mon, May 28, 2001 at 09:46:08PM -0700, Galchin Vasili wrote:
Hello,
Sorry I couldn't find mail list archive.
Where are the .cs files for the OSProcess?
what files are necessary to run?
The postings did not get picked up by the Squeak fix archive. Maybe it was off line when I send these to the list. I will send copies to Bert, so you should see them in a day or so on http://swiki.gsug.org:8080/sqfixes.
Dave
I note that on some versions of mmap you can speicify a starting address. Therefore if it works you could avoid having to swizzle the pointers when you access the image since they would never change. Otherwise you are back to updating all the object slots at load time.
The method ObjectMemory>>adjustAllOopsBy in my image was last updated by you, I believe (JMM 11/18/2000 17:50).
Ok, I've got my initials on it by accident. The change made was "di 11/18/2000 - return number of objects found" which I happened to do for Dan at his request to solve the multiple GC events because the forwarding table was full. The forwarding table now is sized by the number of objects in the image, so that number comes from somewhere, and Dan added code to snatch it from this method.
Now I can't speak for the comment... And I wonder if it's fixed? See self longAt: oop put: (header bitAnd: AllButRootBit). clears that Root Bit everywhere. But I'd think ObjectMemory>>clearRootsTable should do that which is called from fullGC which is called from ObjectMemory>>primitiveSnapshot.
So anyone know if this is still a bug? Or is it dead.
Still need to count those objects tho...
Ok, I've got my initials on it by accident. The change made was "di 11/18/2000 - return number of objects found" which I happened to do for Dan at his request to solve the multiple GC events because the forwarding table was full. The forwarding table now is sized by the number of objects in the image, so that number comes from somewhere, and Dan added code to snatch it from this method.
Now I can't speak for the comment... And I wonder if it's fixed? See self longAt: oop put: (header bitAnd: AllButRootBit). clears that Root Bit everywhere. But I'd think ObjectMemory>>clearRootsTable should do that which is called from fullGC which is called from ObjectMemory>>primitiveSnapshot.
So anyone know if this is still a bug? Or is it dead.
Still need to count those objects tho...
FWIW, it would be easy to forego the counting, since the forwarding block allocation could be determined in a worst-case way from the size of the image instead. Plus, it's an interim solution anyway. There's a better way that's waiting for some free time.
- Dan
See self longAt: oop put: (header bitAnd: AllButRootBit). clears that Root Bit everywhere. But I'd think ObjectMemory>>clearRootsTable should do that which is called from fullGC which is called from ObjectMemory>>primitiveSnapshot.
Still need to count those objects tho...
FWIW, it would be easy to forego the counting, since the forwarding block
allocation could be > determined in a worst-case way from the size of the image instead. Plus, it's an interim
solution anyway. There's a better way that's waiting for some free time.
The better solution sounds good. In the meantime, how exactly would this alternative approach be coded? I'd really like to be able to skip adjustAllOopsBy when mapping an image into the same location in memory.
- Dan
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
David T. Lewis -
Galchin Vasili -
John M McIntosh -
Noel J. Bergman