This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Two Space Memory
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
In my continuing quest to find different ways to do the same thing, I started thinking about memory management, object allocation and deallocation. In Smalltalk, various schemes are used to get rid of objects that are short lived and keep objects that are long lived. This is generally a copy algorithm in the 'new space', juggling objects back and forth to keep it unsegmented.
Either way, you end up with lots of garbage collection happening constantly. Can this ever be a problem? Yes: If you make objects faster than it can collect and destroy them, then you will have a problem.
What's the typical way to solve this problem? Stack allocation. When you leave a method, anything you knew about gets dropped by the switch and simple movement of a register. Can we use this for Smalltalk? Lets investigate.
Say we don't have new spaces and old space. Let us instead have process space and old space. Process space is where all the objects for a process go. To allocate, pointer at the top of the process space ahead the length of a pointer to an object plus the size of the object we're allocating. When we leave our method, we move the pointer of the process space back to where it was when we entered the method.
Whenever we create something, we do so at a "likely" location point. There are a couple of places we may allocate in to: The slot for an argument for the next method call, A slot in our method, the Receiver slot for the next method call and the Return slot for when we exit the method.
In Smalltalk we don't have a clue what the #new method does, it may or may not make something, so we cannot assume that any call to #new will create us an object. In fact, any call at all may make an object.
Therefore, we need to use a "probably goes here" pointer. When we call a method, we set the "probably goes here" pointer to where we think it will go. In the case of code like: foo := Blah new we set the pgh pointer to the foo variable. So on and so forth. This allows foreign code to fill out our next method call for us, or fill in our slots for us, etc. But only if they're making objects the way we want them to. It therefore also allows foreign code to manage its memory the way it wants to.
There will still be some copying going on. For example, in the code aPointer x: MagicNumber new, we first allocate our object in to the next method call. The next method call, x:, will then copy that value from its arguments to aPointers allocated memory. This is also unlike Smalltalk, where every object is independent, in my imagined system setting and getting objects from memory go through a mapping layer so that C structures are created instead of generic memory structures.
At this point, our method leaves and the argument to x: is forgotten, but if x: wanted to do more with it, it would have updated the pointer to x:'s argument with its new location. By doing this, objects can move arbitrarily about still - even out to old space.
So, where does old space come in to all this? If you set an object in to a space outside of process space, then you cannot know when it will be released. At this point, you must copy it to old space, update your pointer and let a garbage collector (old space gcing as opposed to new space gcing) watch over it to see if it needs to be collected up.
How often will this occur? It completely depends on how you structure your code. Often, you create an object in a new process and start doing things with it, eventually getting rid of it. In that scenario, you could end up with 0 objects in old space - ideal. In the case of an environment like VisualWorks, if you're modifying classes, classes are long lived and undoubtedly in old space (to be shared around. I forgot to mention that process space is private to that process).
In this case, all sets will be copying to old space not to some past location in process space. So the act of setting costs the -same-, but it places more objects in to the long running gc. In this, this system would act the same as a normal Smalltalk. But for the scenario I described above, where the majority of objects are allocated within the context of a process, this system wins over a regular Smalltalk implementation.
Previous Topic
