[Vm-dev] Re: [Pharo-dev] blog post
eliot.miranda at gmail.com
Fri Sep 6 17:04:10 UTC 2013
On Fri, Sep 6, 2013 at 9:35 AM, Stéphane Ducasse
<stephane.ducasse at 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
> 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?
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 =
(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
- 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 #==.
> > 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
> > --
> > best,
> > Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev