[Vm-dev] Re: [Pharo-dev] Implementing lazy loading for expandable collections

Eliot Miranda eliot.miranda at gmail.com
Fri Sep 19 19:45:15 UTC 2014


On Fri, Sep 19, 2014 at 2:35 AM, Max Leske <maxleske at gmail.com> wrote:

> I’ve written an implementation of lazily initialized expandable
> collections (for OrderedCollection and subclasses only for now), inspired
> by Alexandre’s talk at ESUG (
> http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw).
> The implementation is pretty much straight forward but there are a couple
> of culprits I want to point out in case anybody else wants to do this:
>
> - my implementation requires an extra instance variable in
> OrderedCollection to store the requested size. This extra instance variable
> will break Monticello (and possibly other tools) because Monticello uses
> OrderedCollections to load code and the particular way it uses them makes
> it impossible to change the number of instance variables on
> OrderedCollection. Also, all .mcz files written after the change will not
> be loadable by images without the new instance variable (same reason).
> - the above means that you have to modify the code in the image manually
> and save a new “base image"
> - read only messages should obviously not initialize the array. The
> ‘firstIndex’ and ‘lastIndex’ variables are quite handy for that. I
> initialize those variables to 1 and 0 respectively which makes most things
> work already (e.g. #size, #isEmpty etc.).
> - when trying to implement the same for HashedCollection I couldn’t. The
> image didn’t just stop working, there was no output at all on the console,
> not even when using a debug VM. The problem seems to be MethodDictionary,
> at least that’s the only subclass of Dictionary for which adding an
> instance variable doesn’t work.
>

Yes, alas the shape of MethodDIctionary is baked into the VM's method
lookup code.  It would be straight-forward to fix it, but it is still work
and one would have to wait for people to update their VMs.

I’ll share some memory monitoring as soon as I have something significant
> (only just rolled it out).
>
>
> Big thanks to Alex for his talk and the cool work he and his students did!
>
> Cheers,
> Max
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140919/c7ba0c51/attachment.htm


More information about the Vm-dev mailing list