[Vm-dev] image format suggestion

[Johnmci]

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 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130913/87737cf6/attachment.htm