[Vm-dev] Re: [Pharo-dev] blog post

[Eliot Miranda]

Hi Florin,


On Sat, Sep 7, 2013 at 10:38 AM, Florin Mateoc <florin.mateoc at gmail.com>wrote:

>
>
> Hi Eliot,
>
>
> > Eliot Miranda <eliot.miranda at gmail.com <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev>> wrote:
> >
> > Hi Stéph,
> >
> > On Fri, Sep 6, 2013 at 9:35 AM, Stéphane Ducasse
> > <stephane.ducasse at inria.fr <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev>>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.
>
>
> Wouldn't a fixed, dedicated, class space facilitate though sharing between multiple images?
> This was a nice feature in VW, and I think it may become even more important with the trend towards multi-core.
>
>
Well, VW's permSpace is a bit less than  a dedicated class space.  It is
merely a 3rd generation of the oldest objects which just happens to contain
classes and methods (and method dictionaries and Smalltalk and globals et
al.  Yes this could be a good idea and yes this is potentially doable in
Spur.  *But* it doesn't have to be done now.  The most important thing is
to get a version of Spur that is much faster than the current system asap.
 Don't let the perfect be the enemy of the good etc.

I also assume that a dedicated space for pinned memory might also
simplify the garbage collector and even help performance a bit.
>
>
Indeed.  But... what do you think of this idea (again from the
SpurMemoryManager class comment):
"A segmented oldSpace is useful.  It allows growing oldSpace incrementally,
adding a segment at a time, and freeing empty segments.  But such a scheme
is likely to introduces complexity in object enumeration, and compaction
(enumeration would apear to require visiting each segment, compaction must
be wthin a segment, etc). One idea that might fly to allow a segmented old
space that appears to be a single contiguous spece is to use fake pinned
objects to bridge the gaps between segments.  The last two words of each
segment can be used to hold the header of a pinned object whose size is the
distance to the next segment.  The pinned object's classIndex can be one of
the puns so that it doesn't show up in allInstances; this can perhaps also
indicate to the incremental collector that it is not to reclaim the object,
etc.  However, free objects would need a large enough size field to stretch
across large gaps in the address space.  The current design limits the
overflow size field to a 32-bit slot count, which wouldn't be large enough
in a 64-bit implementation.  The overflow size field is at most 7 bytes
since the overflow size word also contains a maxed-out 8-bit slot count
(for object parsing).  A byte can be stolen from e.g. the identityHash
field to beef up the size to a full 64-bits."

So while the system might  indeed keep a segment that it puts pinned
objects in preferentially, this wouldn't be visible to the image level.  It
would only be an optimization in the VM.  Does that make sense?

> To me it appears that this kind of specialization of memory (splitting it into dedicated spaces) would almost always be a win.
> While it increases the complexity by increasing the number of components to manage, it also simplifies the components, since they need to handle fewer special cases.
> But I have never implemented a vm :)
>
>
Yes it makes sense.  But supporting it at the image level is work.  VW's
ObjectMemory/MemoryPolicy is quite sophisticated and I don't want to make
implementing something similar for Squeak/Pharo a gating issue for the
release of Cog+Spur.  Again, don't let the perfect be the enemy of the
good.  The first cut of the design,. the first release of the design, is
not the final release.  Evolution is a constant.

> I am also curious if you are including immediate floats in your 64-bit object format.
> I am sure you know about it, but I saw this nice article about tagging in the current JavaScript implementations:http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations
>
>
Thanks, I've not read this yet.


> You only mentioned in your blog tagging for the 32-bit world (I think).
> Can you please add some comments about 64-bit tagging?
>
>
Sure, I'll add stuff to the design sketch soon.  But the idea is to provide
immediate 60-bit, or 61-bit floats to the 64-bit system that implement a
subset of 64-bit IEEE double precision in the centre of the range (actually
with the same range as single-precision 32-bit floats), the same as in
64-bit VW.

Regards,
> Florin
>
> --
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130908/82626736/attachment.htm