HATARI MEMORY USAGE

Here are some stats on Hatari 0.81 memory usage (on Linux) and what
could be done to decrease it for embedded devices.


First the binary size from "size ./hatari":
   text    data      bss       dec
1382406   10712 18255264  19648382

I.e. the binary size is 1.3MB, it has 10KB of pre-defined arrays and
18MB of non-initialized fixed size arrays.  The names of the arrays
are listed at the bottom, but STRam is the one taking 16MB.

Happily Hatari doesn't dirty (zero) all of STRam, just first 4MB
(accessible as ST ram) and 2MB at the top (used as IO-memory,
TOS and cartridge memory).  In next Hatari version Hatari will
zero only part of the ST ram that user has configured
(e.g. 0.5MB instead of 4MB -> 3.5MB private memory save).


When I profiled Hatari with Valgrind (valgrind.kde.org) Massif plugin,
it tells that Hatari malloc()s about 3MB of memory. The allocations
and how to make them smaller for embedded devices (no generic way
unfortunately) are:

* In includes/vdi.h set MAX_VDI_WIDTH and MAX_VDI_HEIGHT from 1024 and
  768 to 640 and 400 respectively. This decrease memory usage from 1.5MB
  to 0.5MB (btw. for page flipping Allocation 2*2 framebuffers).
  - Change list of VDI modes in Hatari dialog accordingly

* Do not load bigfont in gui-sdl/sdlgui.c, especially if the device
  screen is smaller than VGA.  Both fonts together take about 1/3 MB.

* Change uncompressed file read to use mmap() instead, currently
  memory is allocated for the whole disk image before reading it.
  - With normal DD floppy image Hatari would use that amount which
    might be acceptable, but with e.g. 2MB disk needed for running
    Wolf3D v0.8, mmap() sounds much better
  - For compressed disk images memory needs to be allocated for
    uncompressed image data, i.e. there we cannot save memory.

* Check whether the m86k instruction table could be made smaller:
        #include "uae-cpu/readcpu.h"
        printf("%d -> %d\n", sizeof(struct instr), sizeof(struct instr) * 65536);
  On x86 it's slightly over 1MB.

You can also Massif Hatari yourself, its allocation calltrees
are very short, so it's easy to find these from the produced
PostScript graph and txt/html calltree listing.


From /proc/sysvipc/shm one can see how much shared memory Hatari/libSDL
has allocated and that it shares it with the X server:
- >100KB in lowrez
- ~200KB in lowrez with borders
- ~500KB in monochrome or zoomed lowrez
- >800KB in zoomed lowrez with borders
I don't think these could be made smaller from the code. Besides
user can just use a the smaller Hatari screen mode.

According to Xrestop, Hatari doesn't keep any Pixmap resources
at the X server side.


Finally when looking at the Hatari process with "pmap", you can
see that the binaries Hatari links don't use so much private
(writable) memory:
    map <Hatari PID>|grep /|grep w

Rest of the 30MB Hatari VMSIZE you see in "top" (about 10MB), goes to
shared library code (their .text sections with "r-x" rights) Hatari
links.  That is memory mapped read-only / read in on-demand / pagable
back to disk so it's not so much of a problem.


Unmodified Hatari runs on (Linux) systems having about 20MB of free
memory (e.g. according to /proc/meminfo free+buffers+cached fields).
Using low-rez without borders nor zooming, setting emulated ST memory
amount to <=1MB, limiting the VDI screen size and removing bigfont
(discussed with Massif findings above) should enable running Hatari
well on a system with only 10MB free memory, if it's otherwise fast
enough.


	- Eero Tamminen

To see the objects in the binary BSS section, get the datadump script
from here:
     http://live.gnome.org/MemoryReduction_2fTools

Compile Hatari without stripping, and use:
     datadump.py -n -s .bss ./hatari

As a result you see these array variables (larger ones):
16777216 STRam hatari
  321536 CyclePalettes hatari
  262144 mem_banks hatari
  262144 cpufunctbl hatari
  131072 pInterceptWriteTable hatari
  131072 pInterceptReadTable hatari
   69632 InternalDTAs hatari
   65536 EnvelopeShapeValues hatari
   53588 DialogParams hatari
   53588 ConfigureParams hatari
   19976 FrameBuffers hatari
   16384 ST2RGB hatari