[ATARI] RE: Atari digest, Vol 1 #391 - 9 msgs

[Jesus Cea Avion]

> Si te dedicas a tareas que se necesiten precisión como el CAD/CAM/CAE,
> procesado de señal, etc, entonces dichas API deberían estar ya
> presentes en memoria, ya que por su tamaño tratarla como librería
> dinámica puede ser una carga muy pesada para el sistema...

Una librería dinámica METE MENOS carga en el sistema, no más:

BerkeleyDB 4.1.25:

Tamaño de la librería estática: 1.15 MB

Tamaño de la librería dinámica: 892 KB

Si 7 programas usan BerkeleyDB de forma estática, tienes ese código
presente 7 veces en memoria. Si usan librerías dinámicas, la misma
librería FÍSICA se comparte entre todos los procesos, en memoria.

Un "enlazador" "inteligente" podría tomar la librería estática y sólo
insertar en el programa final las rutinas que realmente se estén usando
en el mismo. Digamos que pasamos de 1.15 MB a 300 Kbytes "reales". Son
300 Kbytes de más en el disco duro, 300 Kbytes que deben cargarse al
lanzar la aplicación y 300KBytes que no se comparten con ninguna de las
170 aplicaciones en tu sistema que usan la BerkeleyDB.

Recordemos que el que una librería dinámica ocupe 80 megas no significa
que se carguen los 80 megas en memoria, sino que se "mapean" 80 megas.
Se irán cargando los bloques de memoria que sean necesarios, igual que
se hace con la memoria virtual.

Tomemos como ejemplo mi Apache (servidor web) compilado con soporte SSL,
aunque en mi servidor (UNIX - Solaris) poco uso de eso hago:

La librería SSL ocupa, en disco duro, 2.16 Megabytes. Pero si hago un
"pmem" sobre ese proceso, me sale:

EE580000   776K   760k   688k    72k read/exec         
/usr/local/ssl/lib/libcrypto.so.0.9.6

El primer número dice la dirección en la que se carga la librería.

El segundo número dice su tamaño. Son 776Kbytes, no 2.16MBytes, porque
la librería dinámica contiene cantidad de información de depuración y
documentación que, obviamente, sólo se mapean en memoria cuando se usan.

El siguiente número, 760Kbytes, nos dice exactamente cuánto espacio
ocupa realmente la librería. No coincide con 776 por cosas como el
ajuste de tamaño de página o segmentos BSS (segmentos a cero no
existentes en disco).

El siguiente número, 688Kbytes indica cuánto de esa librería estamos
compartiendo con OTROS procesos. Nos dice que de los 760 Kbytes que
ocupa "realmente" la librería, hay 688Kbytes que están siendo usados por
otros procesos y que, entonces, no ocupan memoria (una copia compartida
por todo dios).

El último número, 72Kbytes, es tamaño de las páginas "privadas" a este
proceso, para esa librería. A efectos prácticos, es el tamaño que
realmente nos "ocupa" esa librería. En realidad es mucho menos, pero mi
sistema tiene un tamaño de página de 8Kbytes, así que todos los tamaños
de código, datos, "heap", pila, etc., se redondean a 8Kbytes, cada uno
por separado. Osea, que en realidad, de esos 72Kbytes, la mayoría es
"redondeo". En un sistema con páginas de 256 bytes (posible en un 68030,
por ejemplo) igual el tamaño final serían 15 Kbytes.

Lo siguiente son los permisos: "read/exec" significa que es código, y
que no puede ser modificado. Este hecho es el que permite que la misma
librería sea compartida, en memoria, por varios procesos.

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz