On 19.09.2014, at 21:45, Eliot Miranda <eliot.mira...@gmail.com> wrote:
> > > On Fri, Sep 19, 2014 at 2:35 AM, Max Leske <maxle...@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). 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
