[Vm-dev] image format suggestion

[Eliot Miranda]

Hi John,

(BTW your message ended up in my spam folder on gmail, again :-( )

On Fri, Sep 13, 2013 at 1:30 PM, Johnmci <johnmci at smalltalkconsulting.com>wrote:

>
> There is some OS aspects in here. It is true that a mmap won't fetch the
> page until touched on IOS. However this is not the case on OSX where the
> memory manager pages the entire set into memory on one go.
>
> Also in the mid part of the last decade it was determined that the NFS
> file system driver was flawed if you attempted to mmap to a NFS file server
> which is why the old vm had a plist flag to enable mmap behavior or not
>
> Ps also explore the concept of sorting objects based on use profile to
> cluster usages across pages versus the kind of random layout now. Also
> could make CPU hw cache logic happier
>

Would this be done off-line as an image-file reoganizer, or on-line by the
GC?  If so, got any pointers to issues, approaches, what to optimize etc?
 Cheers!


> Sent from my iPhone
>
> On 2013-09-13, at 4:20 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
>
> On Fri, Sep 13, 2013 at 1:48 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>
>>
>> On 2013-09-13, at 02:03, "Jecel Assumpcao Jr." <jecel at merlintec.com>
>> wrote:
>>
>> > I wanted
>> > to be able to load the same image into a 16 bit, a 32 bit and a 36 bit
>> > processor. The encoding was based on a compact representation for
>> > "infinite" lenght integers.
>> > [...]
>> > Object pointers were encoded as the number indicating how many object
>> > back to look in the object table.
>> > [...]
>> > These details don't matter - the important thing is that if it is
>> > possible to have a single image file format for Spur that works in both
>> > 32 and 64 bit VMs it would be nice to do it.
>> >
>> > -- Jecel
>>
>> Very nice idea! I'd love to have a single image format.
>>
>> There is, however, one big advantage to a straight memory dump: paging.
>> With a few little tweaks, it's possible to avoid reading the full image on
>> startup. It can just be memory-mapped, which tells the OS to load a page
>> into memory only when it is accessed the first time. I experimented with
>> this back in the days of the first OLPC machine which had a very slow CPU
>> and a rather slow flash drive, but we did not deploy that. John made it
>> work for his iOS stuff though and he reported quite a bit of startup time
>> improvement.
>>
>
> +1
>
>
>>
>> A slightly related idea is "perm space" à la VisualWorks, which makes a
>> part of the object memory read-only.
>
>
> Actually copy-on-write, with writes minimised by avoiding garbage
> collecting permSpace unless one does a truly global GC.
>
>
>> With that even a full GC might avoid having to page in everything. This
>> might also help with multi-threading, because after forking with
>> copy-on-write semantics the majority of pages would still be shared between
>> threads.
>>
>
> Right.
>
>
>> Looking forward these optimizations might not be worth it, but we should
>> still discuss them.
>>
>
> Indeed.  All, please don't take any lack of interest on my part as
> criticism or rejection.   One of the things I must do in pursuing Spur is
> focus on making progress.  So I will not tackle radical ideas that are not
> core to the design immediately.  Cool ideas immediately go on my
> back-burner unless extremely compelling, because the most importnt thing is
> to realise the first release.  Improvements can always follow.
>
>
>> - Bert -
>
>
> --
> best,
> Eliot
>
>
>


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