OrderedDictionary (was: Re: [squeak-dev] Re: The Trunk: Collections-mt.593.mcz)

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 16 19:47:55 UTC 2015


Hi Paul,

On Fri, Jan 16, 2015 at 11:36 AM, Paul DeBruicker <pdebruic at gmail.com>
wrote:

> Eliot Miranda-2 wrote
> > Ugh.  I was blindsided.  I saw the numbers as times not rates.  Marcel,
> > I'm sorry.  OK indeed the difference would be the cost of the bounds
> check
> > in each array access.  Interesting to see at what point the poorer memory
> > locality of the list makes it worse.  Difficult to measure given the
> > locality is decided by history and the GC.
>
> With Spur could you use object pinning to make a dense linked list? And
> then
> use that for arrays that need to be fast?
>

It might make some difference but I doubt it'll work well.  There is code
to cluster pinned objects in the segment or segments that contain pinned
objects.  But it's not going to work well; if the object is in new space
then it is copied to old space and forwarded, plus some scanning of stack
pages.  Thats a lot of overhead.  If it's in old space anyway the GC just
sets the bit.

Pinning is really there for objects to be passed through the FFI or space
needed to be referred to from machine code, such as conditional branch
counters in Sista.  it's not there to control locality.  Hence it is
unoptimised.  But that's an interesting idea :-).

A more general solution would be to have some sort of reorganisation in the
VM.  Currently the compaction algorithm used with global GC scrambles
things.  It would be nice if the incremental global compactor could not
scramble, and its my intent to at least avoid scrambling, if not undo it in
the incremental global gc (which has yet to be started).

--
> View this message in context:
> http://forum.world.st/The-Trunk-Collections-mt-593-mcz-tp4799750p4800035.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150116/a64f57d8/attachment.htm


More information about the Squeak-dev mailing list