[Vm-dev] image format suggestion

Eliot Miranda eliot.miranda at gmail.com
Fri Sep 13 20:20:37 UTC 2013

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.


> 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.


> 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 -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130913/06e102db/attachment.htm

More information about the Vm-dev mailing list