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

[Eliot Miranda]

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.

Max
>
> 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
>
> --
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140923/7cba39c0/attachment.htm