[Openmcl-devel] Sudden increment in executable image size.

[Gary Byers]

On Wed, 17 Nov 2010, Kaz Kylheku wrote:

>
> Hey all,
>
> on Windows, 32 bit CCL saves an image that is about 40 megabytes (which is 
> quite a bit larger than on Linux).

I see and expect to see images whose size is around 20 MB (which is generally
very close to the total of what ROOM reports as being "Used"):

[src/ccl-dev] gb at boddhi> ccl
Welcome to Clozure Common Lisp Version 1.7-dev-r14406M-trunk  (WindowsX8632)!
? (room)
Approximately 16,646,144 bytes of memory can be allocated 
before the next full GC is triggered.

                    Total Size             Free                 Used
Lisp Heap:       19464192 (19008K)   16646144 (16256K)    2818048 (2752K)
Stacks:           8265440 (8072K)     8263160 (8069K)        2280 (2K)
Static:          21059864 (20566K)          0 (0K)       21059864 (20566K)
845.437 MB reserved for heap expansion.
NIL
? (save-application "new.image")
[src/ccl-dev] gb at boddhi> ls -l *.image
-rwxr-xr-x 1 gb None 23793680 Nov 17 18:54 new.image
-rwxr-xr-x 1 gb None 23789584 Nov  6 02:52 wx86cl.image

The images that I save (and some of the ones checked into the trunk) are
actually a few MB larger than those that we distribute for formal releases;
my init file causes more source-location information to be saved.

Calling

? (heap-utilization)

should report a total "physical size" that's very close to the .image file's
size on disk.

For you, do ROOM and HEAP-UTILIZATION totals correspond to the file size ?

The fact that the file size that you see and what I think that you should
see differ by about 2X seems a little suspicious, as does the fact that
minor tweaks seem to cause it to double again.  (As if the image file
is getting written twice.)  Before worrying about that, the first thing
to do is to check to see whether ROOM and HEAP-UTILIZATION return figures
that're approximately equal to the size of the .image file.  If they are,
then you're saving 40/78 MB of live lisp data and the next step would be
to figure out what that extra stuff is; if the figures differ significantly,
then it seems likely that something else is going on in the process of 
writing heap contents to disk.


>
> I've been making some tweaks to a program, and suddenly, the executable size 
> nearly doubled, jumping to 78 megs!  It compresses to the same size as 
> before, though, under LZMA. (Sorry, I haven't done the detailed investigation 
> to isolate what change might have triggered this).
>
> Are there any tips on managing the executable size?
>
> Is this just a dump of virtual memory that potentially includes lots of 
> sparse regions?

It's a fairly small number (4 or 5) of contiguous regions, each of which
is aligned on a 4KB boundary in the file, + a few hundred bytes of signature
information and descriptions of where those regions are within the file
and where they should be mapped into memory.  (On Unix systems, those
sections are just file-mapped into memory when the image is opened; it'd
be nice to do that on Windows, but - among other things - that'd make it
harder to overwrite the running image.)



>
> Maybe during build time (loading the fasl's), I tripped some memory 
> management threshold, causing some new virtual memory area to be added to the 
> image?
>
> Cheers ...
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>