<div dir="ltr">Hi Stéph,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 9:35 AM, Stéphane Ducasse <span dir="ltr"><<a href="mailto:stephane.ducasse@inria.fr" target="_blank">stephane.ducasse@inria.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi eliot<br>
<br>
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)<br>
I have some questions that may be are stupid.<br>
- 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.<br>
</blockquote><div><br></div><div>exactly.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Did I get it rid that you want to have a become: that does not require scanning the full memory?<br>
</blockquote><div><br></div><div>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...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But with a body as in VW. This is what you mean with the lazyBecome: and the forwarding pointer?<br></blockquote><div><br></div><div>Here are the relevant paragraphs in SpurMemoryManager's class comment:</div>
<div><br></div><div><div>- 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.</div>
</div><div><br></div><div>(and later on)</div><div><br></div><div>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.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - For Characters since they are immediate (if I got it right) we could use Unicode directly or am'I wrong?<br>
</blockquote><div><br></div><div>That's right. This should speed up string access and mean that all characters are unique, so one can use #==.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Stef<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Hi All,<br>
><br>
> 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.<br>
> --<br>
> best,<br>
> Eliot<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>