<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 13, 2013 at 1:48 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 2013-09-13, at 02:03, &quot;Jecel Assumpcao Jr.&quot; &lt;<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>&gt; wrote:<br>
<br>
&gt; I wanted<br>
&gt; to be able to load the same image into a 16 bit, a 32 bit and a 36 bit<br>
&gt; processor. The encoding was based on a compact representation for<br>
&gt; &quot;infinite&quot; lenght integers.<br>
&gt; [...]<br>
&gt; Object pointers were encoded as the number indicating how many object<br>
&gt; back to look in the object table.<br>
&gt; [...]<br>
&gt; These details don&#39;t matter - the important thing is that if it is<br>
&gt; possible to have a single image file format for Spur that works in both<br>
&gt; 32 and 64 bit VMs it would be nice to do it.<br>
&gt;<br>
&gt; -- Jecel<br>
<br>
Very nice idea! I&#39;d love to have a single image format.<br>
<br>
There is, however, one big advantage to a straight memory dump: paging. With a few little tweaks, it&#39;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.<br>
</blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A slightly related idea is &quot;perm space&quot; ą la VisualWorks, which makes a part of the object memory read-only. </blockquote><div><br></div><div>Actually copy-on-write, with writes minimised by avoiding garbage collecting permSpace unless one does a truly global GC.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
</blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looking forward these optimizations might not be worth it, but we should still discuss them.<br>
</blockquote><div><br></div><div>Indeed.  All, please don&#39;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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Bert -</font></span></blockquote></div><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>