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

Eliot Miranda eliot.miranda at gmail.com
Wed Sep 24 06:33:48 UTC 2014

On Mon, Sep 22, 2014 at 5:10 AM, Max Leske <maxleske at gmail.com> wrote:

> On 19.09.2014, at 21:45, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 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.
> When you say “fix”, do you mean a hard coded change of the number of
> fields in MethodDictionary or do you mean a change that would allow one to
> change the number of fields in the future? In the former case someone wiser
> than me will have to make a decision, in the latter I would promote that
> change (if it doesn’t affect performance of course).

The latter.  It does make accessing method dictionaries on lookup slightly
slower but lookups are rare in both the interpreter and the JIT.

> 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/20140923/7cba39c0/attachment.htm

More information about the Vm-dev mailing list