[Vm-dev] Re: [Pharo-dev] blog post
eliot.miranda at gmail.com
Sun Sep 8 17:34:45 UTC 2013
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev