<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jecel Assumpcao Jr. wrote:
<blockquote cite="mid:md5:FFFFFFE3FFFFFF9406FFFFFF9C0042FFFFFFC50AFFFF"
type="cite">
<pre wrap="">
Eliot Miranda wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Sep 12, 2013 at 5:27 PM, Tim Rowledge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Another possibly interesting approach would be to use the zip compander
we already have in the plugin to just zip the images. Many, many years ago,
dan Lanovaz did some experiments with VW to try out the idea and it
looked an interesting way to save space and (depending upon machine
details) time when loading. Of course, disks are so big these days maybe
it doesn't matter, though I've always had a hard time really accepting that
. I grew up with 20Mb disc as the Disk Of Your Dreams….
</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
And now we have L3 CPU cache that is 20Mb and bigger. Amazing really.<br>
<br>
<blockquote cite="mid:md5:FFFFFFE3FFFFFF9406FFFFFF9C0042FFFFFFC50AFFFF"
type="cite">
<blockquote type="cite">
<pre wrap="">I actually implemented this in VisualWorks in the mid 2000's. It is very simple
and works well. I'll put it on the list. I much prefer it to an ad-hoc scheme
such as the one Jecel suggests. Much less maintennance effort.
</pre>
</blockquote>
<pre wrap=""><!---->
This is included in the Self VM (it can accept either a .snap or a
.snap.gz file) and I thought I had also seen it in Squeak. I know that I
have tested the compression rate of images from both Squeak and Little
Smalltalk (which does use an odd encoding instead of memory dump) with
gzip and, if I remember correctly, the results were better than my own
scheme by a small factor.
The advantage of my suggestion was a single image format for both 32 and
64 bit VMs, which you don't get with compressed memory dumps. In the
project where I used that encoding I was bootstrapping a Smalltalk with
nothing more than an assembler, so that alternative was simpler than
writing my own version of gzip. That isn't an issue for Squeak, of
course.
In another email, Eliot Miranda wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Fri, Sep 13, 2013 at 1:48 AM, Bert Freudenberg wrote:
</pre>
<blockquote type="cite">
<pre wrap="">A slightly related idea is "perm space" à la VisualWorks, which makes a part
of the object memory read-only.
</pre>
</blockquote>
<pre wrap="">Actually copy-on-write, with writes minimised by avoiding garbage collecting
permSpace unless one does a truly global GC.
</pre>
</blockquote>
<pre wrap=""><!---->
If a VM can load more than one image (an interesting thing to do with
multicores) then this space can be shared among them to avoid multiple
copies filling up the machine's RAM. And you can save it to a separate
file on disk to make images smaller (just like the .sources file is only
there to make the multiple .changes you have on a disk be smaller than
they would otherwise be).
</pre>
</blockquote>
<br>
A VM running more than one image with common pages shared would be
_very_ interesting from a web host perspective, though I guess not in
scope for now.<br>
<br>
</body>
</html>