Hi All, I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting. -- best, Eliot
On 5 September 2013 19:38, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting.
That's http://www.mirandabanda.org/cogblog/2013/09/05/a-spur-gear-for-cog/ for the lazy :) frank
eliot this is an excellent news. Now do you plan to have support for ephemerons and immutable objects? Stef On Sep 5, 2013, at 8:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting. -- best, Eliot
Hi eliot This is really good that you write this blog. I read and I saw ephemerons (excellent because we were discussing them again today with esteban and igor) I have some questions that may be are stupid. - I was wondering if you plan to have a dedicated class space. Clement told me that in Chrome (but I may be wrong) they have that and in the class space the classes are not moved. But with the table you are sure that your index do not change so may be the gain is not important. - Did I get it rid that you want to have a become: that does not require scanning the full memory? But with a body as in VW. This is what you mean with the lazyBecome: and the forwarding pointer? - For Characters since they are immediate (if I got it right) we could use Unicode directly or am'I wrong? Stef
Hi All,
I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting. -- best, Eliot
Hi Stéph, On Fri, Sep 6, 2013 at 9:35 AM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Hi eliot
This is really good that you write this blog. I read and I saw ephemerons (excellent because we were discussing them again today with esteban and igor) I have some questions that may be are stupid. - I was wondering if you plan to have a dedicated class space. Clement told me that in Chrome (but I may be wrong) they have that and in the class space the classes are not moved. But with the table you are sure that your index do not change so may be the gain is not important.
exactly.
- Did I get it rid that you want to have a become: that does not require scanning the full memory?
yes, this is very important for the FFI. I want to be able to pin objects very cheaply, and I think that the way to do that is to a) become: objects in newSpace into pinned objects in oldSpace, and b) have an incremental collector/compactor in oldSpace that doesn't move pinned objects. If objects can be pinned in newSpace I think newSpace will fill up. So...
But with a body as in VW. This is what you mean with the lazyBecome: and the forwarding pointer?
Here are the relevant paragraphs in SpurMemoryManager's class comment: - lazy become. The JIT's use of inline cacheing provides a cheap way of avoiding scanning the heap as part of a become (which is the simple approach to implementing become in a system with direct pointers). A becomeForward: on a (set of) non-zero-sized object(s) turns the object into a "corpse" or "forwarding object" whose first (non-header) word/slot is replaced by a pointer to the target of the becomeForward:. The corpse's class index is set to one that identifies corpses (let's say classIndex 1), and, because it is a special, hidden class index, will always fail an inline cache test. The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target. (In the interpreter there needs to be a similar check when probing the method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation). See below on how we deal with becomes on objects with named inst vars. We insist that objects are at least 16 bytes in size (see 8-byte alignment below) so that there will always be space for a forwarding pointer. Since none of the immediate classes can have non-immediate instances and since we allocate the immediate class indices corresponding to their tag pattern (SmallInteger = 1 & 3, Character = 2, SmallFloat = 5?) we can use all the class indices from 0 to 7 for special uses, 0 = free, and e.g. 1 = isForwarded. (and later on) As described earlier the basic idea behind lazy become is to use corpses (forwarding objects) that are followed lazily during GC and inline cache miss. However, a lazy scheme cannot be used on objects with named inst vars without adding checking to all inst var accesses, which we judge too expensive. Instead, when becomming objects with named inst vars, we scan all activations in the stack zone, eagerly becomming these references, and we check for corpses when faulting in a context into the stack zone. Essentially, the invariant is that there are no references to corpses from the receiver slots of stack activations. A detail is whether we allow or forbid pinning of closure indirection vectors, or scan the entire stack of each activation. Using a special class index pun for indirection vectors is a cheap way of preventing their becomming/pinning etc. Although "don't do that" (don't attempt to pin/become indirection vectors) is also an acceptable response. - For Characters since they are immediate (if I got it right) we
could use Unicode directly or am'I wrong?
That's right. This should speed up string access and mean that all characters are unique, so one can use #==.
Stef
Hi All,
I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting. -- best, Eliot
-- best, Eliot
Thanks for the answers. I'm back in my admin meetings tiring timesâ¦.so my brain works slower than whenI 'm fresh and concentrated.
- Did I get it rid that you want to have a become: that does not require scanning the full memory?
yes, this is very important for the FFI. I want to be able to pin objects very cheaply, and I think that the way to do that is to a) become: objects in newSpace into pinned objects in oldSpace, and b) have an incremental collector/compactor in oldSpace that doesn't move pinned objects. If objects can be pinned in newSpace I think newSpace will fill up. Soâ¦
I see. And indeed being able to pin an objects will certainly also simplify nativeboost because igor as a "kind of roots" for that reason.
But with a body as in VW. This is what you mean with the lazyBecome: and the forwarding pointer?
Here are the relevant paragraphs in SpurMemoryManager's class comment:
I love such kind of comments. I always remember good comments and I'm often sad to see how we (pharo) failed to have cool class comments that explain things to the reader. I always loved smalltalk because I could learn.
- lazy become. The JIT's use of inline cacheing provides a cheap way of avoiding scanning the heap as part of a become (which is the simple approach to implementing become in a system with direct pointers). A becomeForward: on a (set of) non-zero-sized object(s) turns the object into a "corpse" or "forwarding object" whose first (non-header) word/slot is replaced by a pointer to the target of the becomeForward:. The corpse's class index is set to one that identifies corpses (let's say classIndex 1), and, because it is a special, hidden class index, will always fail an inline cache test. The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target. (In the interpreter there needs to be a similar check when probing the method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation). See below on how we deal with becomes on objects with named inst vars. We insist that objects are at least 16 bytes in size (see 8-byte alignment below) so that there will always be space for a forwarding pointer. Since none of the immediate classes can have non-immediate instances and since we allocate the immediate class indices corresponding to their tag pattern (SmallInteger = 1 & 3, Character = 2, SmallFloat = 5?) we can use all the class indices from 0 to 7 for special uses, 0 = free, and e.g. 1 = isForwarded.
(and later on)
As described earlier the basic idea behind lazy become is to use corpses (forwarding objects) that are followed lazily during GC and inline cache miss. However, a lazy scheme cannot be used on objects with named inst vars without adding checking to all inst var accesses, which we judge too expensive. Instead, when becomming objects with named inst vars, we scan all activations in the stack zone, eagerly becomming these references, and we check for corpses when faulting in a context into the stack zone. Essentially, the invariant is that there are no references to corpses from the receiver slots of stack activations. A detail is whether we allow or forbid pinning of closure indirection vectors, or scan the entire stack of each activation. Using a special class index pun for indirection vectors is a cheap way of preventing their becomming/pinning etc. Although "don't do that" (don't attempt to pin/become indirection vectors) is also an acceptable response.
I reread it twice but I will have to do it again. Thanks anyway.
- For Characters since they are immediate (if I got it right) we could use Unicode directly or am'I wrong?
That's right. This should speed up string access and mean that all characters are unique, so one can use #==.
That also sounds exciting :) I have to refresh what I learned and forgot on unicode, encoding and the rest.
participants (3)
-
Eliot Miranda -
Frank Shearar -
Stéphane Ducasse