Universidad de Oriente

Núcleo Monagas
Escuela de Ingeniería y Ciencias Aplicadas
Sistemas Operativos

Gestión de Memoria
(Symbian OS.)
Profesor: Estudiantes:
Rommel Guevara Jesús Medina - 26085550
Adrián Rojas - 23538051
Oscar Medina – 23897535
Natalya Souquett - 25576958

20/05/2019
Gestión de memoria en Symbian

El gestor de memoria se encarga de gestionar la memoria principal y virtual para

que esta sea compartida por todos y cada uno de los procesos que se van a
ejecutar o están en ejecución, entre otras múltiples tareas este debe de asegurase
que cada proceso cuente con un espacio de memoria independiente. La gestión
de memoria está ligada íntimamente a la gestión de procesos, ambas tienen el fin
de permitir que los distintos dispositivos que los utilizan puedan ejecutar los
procesos en modo multitarea.

En nuestro sistema operático (Symbian OS), Este no contiene o no posee las

herramientas para proveer memoria virtual, por lo que se dificulta emplear la
paginación bajo demanda, principalmente porque el único almacenamiento
disponible es la memoria, no emplea disco duro, en su lugar se tiene un
almacenamiento muy limitado, que debe ser gestionado de una forma muy
excepcional, para lograr un buen desempeño en el sistema operativo. Pero si se
utiliza la abstracción de las páginas de memoria.

Este sistema es uno más de los muchos sistemas operativos pequeños, lleva
consigo muchas de las características (la paginación, la traducción de direcciones
y la abstracción de direcciones virtuales/físicas) de administración de los sistemas
operativos más grandes, por lo que, aunque no se tenga memoria virtual y no se
implemente la paginación bajo demanda, no quiere decir que no se gestiona la
memoria, de hecho, la falta de memoria virtual es indicativo de que las paginas no
pueden ser intercambiadas de la memoria y guardarse en el almacenamiento
externo, es decir, las paginas son reemplazadas, pero las páginas que se van a
reemplazar, solo se descartan.
La administración de memoria tiene muchas tareas específicas e importantes, el
tamaño de la aplicación es una de ellas y como lo hemos dicho es de vital
importancia, esta tiene un impacto decisivo en cuanto a la manera que se usa la
memoria. Pero para todo esto se requiere de gran habilidad y disciplina para crear
un software lo suficientemente pequeño y que cumpla correctamente con todas y
cada una de sus funciones. La administración de memoria cumple con las
siguientes tareas:

La administración del montículo es otro aspecto importante cuando de

administración de memoria se trata. El montículo no es más que el espacio para la
asignación dinámica de memoria, que se debe administrar en forma muy estricta
en una plataforma más pequeña, esto se hace de forma estricta para obligar a los
programadores a reclamar y reutilizar el espacio del montículo lo más posible que
pueda.

Ejecución en el lugar, Lo que esto significa o lo que nos quiere decir es que, la
memoria flash se asigna al espacio de direcciones virtuales y los programas se
pueden ejecutar directamente de la memoria flash, sin necesidad de copiarlos
primero en la RAM. Al hacer esto se reduce a cero el tiempo de carga, esto nos da
como beneficio que las aplicaciones puedan iniciarse de forma instantánea y
además no hay que ocupar la RAM, que es escasa.

Carga de DLLs La decisión de cuándo se deben cargar las DLLs puede afectar en
la percepción del rendimiento del sistema. Por ejemplo, es más aceptable cargar
todas las DLLs cuando se carga una aplicación por primera vez en la memoria,
que cargarlas en tiempos esporádicos durante la ejecución. Los usuarios
aceptarán con más disposición el tiempo de retraso en la carga de una aplicación
que los retrasos en la ejecución. Tenga en cuenta que las DLLs tal vez no se
necesiten cargar.
Este podría ser el caso si (x) ya se encuentran en la memoria, o (z) están
contenidas en almacenamiento flash externo (en cuyo caso, se pueden ejecutar en
el lugar).Transferencia de la administración de la memoria al hardware Si hay una
MMU disponible, se utiliza en toda su extensión. De hecho, entre más
funcionalidad se pueda poner en la MMU, mejor será el rendimiento del sistema.

Aun con el uso de la regla de ejecución en el lugar, las plataformas pequeñas

(como es el caso de Symbian OS), de todas formas, necesitan memoria que está
reservada para la operación del sistema operativo. Esta memoria es compartida
con el almacenamiento permanente, y en general, se administra en una de dos
formas. En primer lugar, algunos sistemas operativos optan por una metodología
muy simple y no paginan la memoria. En estos tipos de sistemas, el cambio de
contexto significa asignar espacio de operación, espacio del montón, por ejemplo,
y compartir este espacio de operación entre todos los procesos. Este método
utiliza poca o ninguna protección entre las áreas de memoria de los procesos, y
confía en que éstos trabajarán bien en conjunto.

Symbian puede realizar abstracciones iguales a la de programas más grandes que

él, a las direcciones físicas se le asignan direcciones virtuales que son las que los
programas usan. Symbian al igual que varios sistemas operativos realiza división
de la memoria a páginas virtuales e marcos físicos, generalmente el tamaño de
esos marcos es de 4KB, sin embargo todo esto puede llegar a variar.

Symbian OS es un SO (Sistema operativo) de 32 bits, y sus direcciones pueden

abarcar hasta 4GB de memoria, con un marco de tamaño de 4kb está para un
tabla de páginas que posee más de 1 millón de entradas en ella, pero teniendo
espacios con limitaciones de memoria. Este sistema operativo no puede ceder
1MB a las tablas de páginas, debido a que el tiempo de búsqueda y resultado de
la tabla tardaría representando ser una carga para este.
Para evitar toda esta problemática el sistema operativo Symbian divide las tablas
en dos niveles para reducir el tiempo de acceso a las tablas y el almacenamiento,
definiendo el primero como el directorio de páginas el cual estaba vinculado con el
segundo nivel planteado y representa los primeros 12 bits, este directorio de
páginas se queda en la memoria, se mantiene en él.

Una de las entradas del directorio de páginas va directamente al segundo nivel, el

cual contiene una colección de tablas de páginas, estas dichas tablas poseen un
vínculo a una página en específico en la memoria y se registran y ordenan
mediante una pequeña porción de dirección virtual que son los 8 bits del medio. La
palabra que se encuentra en la página en la cual se hace referencia se registra y
ordena por los 12 bits de menor orden en la dirección virtual. El hardware apoya
en el cálculo de asignar de dirección virtual a física, pero Symbian no reconoce
ningún tipo de asistencia de hardware.

En el caso de que una página no se encuentra en la memoria, se enviará un error

porque todas las páginas contenidas en la memoria deben ser cargadas al iniciar
la aplicación, las bibliotecas se cargan dinámicamente. Existen 4 versiones del
modelo de memoria que utiliza Symbian OS: modelo de movimiento, modelo
múltiple, modelo directo y el modelo de emulador.

Symbian OS tiene una forma única de utilizar el hardware de paginación que se

encuentra en las CPU modernas. Estas páginas se mantienen en una lista que
está administrada por el sistema operativo y son asignadas de acuerdo a como les
vayan necesitando tanto el sistema operativo como los procesos del usuario.
Como no hay memoria virtual, cuando ya no hay lista de páginas libres, el sistema
se queda sin memoria y no hay lugar a más asignación.
El sistema operativo usa una estrategia de tabla de páginas de dos niveles. El
primer nivel es el directorio de páginas, el cual proporciona un vínculo al segundo
nivel y se indexa mediante una proporción de la dirección virtual (los 8 bits de en
medio). Este directorio se mantiene en la memoria y el TTBR (registro base de
tabla de traducción) apunta a él. Una entrada en el directorio de páginas apunta al
segundo nivel, que es una recopilación de tablas de páginas. Tablas las cuales
proporcionan un vínculo a una página específica en la memoria y se indexan
mediante un pedazo de dirección virtual.

Para obtener la asignación de dirección virtual a física el hardware cumple un

papel muy importante. Aunque este sistema operativo no puede fiarse de contar
siempre con la asistencia o apoyo del hardware, en la mayoría de las arquitecturas
en la que se utilizan tienen unidades de manejo de memorias. Al no encontrarse
una página en la memoria, se genera un error ya que todas las páginas de
memoria de una aplicación se deben cargar al momento de iniciar tal aplicación.
La memoria es muy dinámica en Symbian OS.

En el contexto de las aplicaciones se cambia a través de la memoria, todos y cada

uno de los requerimientos en la memoria se cargan cuando empiezan a
ejecutarse. Las páginas de memoria que necesita cada aplicación se le pueden
pedir de manera estática al sistema operativo, al momento de cargar la aplicación
en memoria. El espacio dinámico tiene cierto límite, por lo que de igual forma se
pueden realizar peticiones estáticas para este espacio. Los marcos de memoria se
asignan a las páginas desde una lista de marcos libres, cuando no hay marcos
libres disponibles, si no hay marcos disponibles se genera un error.
Symbian maneja cuatro versiones distintas para el modelo de implementación de
memoria. Cada modelo se ha diseñado para diferentes tipos de configuración de
hardware. El modelo de movimiento. Se diseñó para las primeras arquitecturas del
ARM. El directorio de páginas en el modelo de movimiento es de 4 KB de largo, y
cada entrada contiene 4 bytes, para un tamaño del directorio de 16 KB. Las
páginas de memoria se protegen mediante bits de acceso asociados con los
marcos de memoria y mediante el etiquetado del acceso a la memoria con un
dominio.

La unidad de manejo de memoria ejecuta los permisos de acceso para cada

dominio y los dominios son registrados en el directorio de páginas. Aunque no se
utiliza la segmentación como tal, hay un orden para la distribución de la memoria:
hay una sección que está destinada para los datos asignados por el usuario y una
sección de kernel para los datos asignados por el kernel. El modelo múltiple. La
unidad de manejo de memoria (MMU) en el modelo múltiple es distinta de la
utilizada en versiones anteriores. La nueva versión de la arquitectura ARM reviso y
mejoro los bits de acceso en cada, marco de página, y abandono el concepto
principal.

Y por último El modelo directo. En este modelo se asume que no hay MMU, y no
se permite su uso en teléfonos de alta gama, ya que obviamente debido a la falta
de unidad de manejo de memoria el rendimiento en el equipo es fatal. La
utilización de este modelo es más que todo para los entornos de desarrollo en lo
que la MMU es deshabilitar por alguna razón. El modelo del emulador. Fue
desarrollado para darle un emulador de Symbian OS a Windows. Posee varias
restricciones en comparación con una verdadera CPU de destino. El emulador se
ejecuta como un solo proceso de Windows, y por eso el espacio de direcciones
está restringido a 2GB.
El Sistema operativo Symbian Os, fue creado para dispositivos móviles.

En estos dipositivos móviles tienen una cantidad limitada de la memoria, esto nos
quiere decir que tiene que ser tomado en cuenta por los desarrolladores de
aplicaciones de dicho. Esto significa que todas y cada una de las aplicaciones no
deben crecer mucho (las funciones no deben tener muchos parámetros) y hay que
evitar solicitar mucha memoria del montículo (zona de memoria utilizada para
datos dinámicos). No obstante, Symbian no impone ningún lımite en el tamaño del
montículo de una aplicación, sino que este impone la cantidad de memoria del
teléfono (en realidad existe un lımite de 2GB), pero es poco probable que se
alcance en un teléfono móvil en un futuro cercano.

En los teléfonos en los que se ejecuta Symbian el almacenamiento permanente se

implementa mediante memoria flash y tarjetas de expansión, mientras que la RAM
se usa como memoria principal. En general, la memoria disponible suele ser de
varios megabytes, y es compartida entre el sistema operativo y las aplicaciones en
ejecución. Para utilizar de forma eficiente la memoria disponible, Symbian utiliza,
una técnica denominada execute-in-place.

En un ordenador convencional los programas, incluyendo al sistema operativo,

deben ser cargados en memoria principal para poder ser ejecutados. Esto implica
que siempre existen dos copias de un programa, la que está en memoria y la que
está en disco. La técnica de execute-in- place implica, tal como su nombre indica,
que el código de un programa se ejecuta sin ser copiado a la memoria principal,
con el consiguiente ahorro de memoria.
Mecanismos de gestión de memoria en Symbian OS.

I. Pila

El espacio de pila disponible en el emulador para PC y el disponible en el terminal

poseen algunas divergencias. El tamaño de la pila en el emulador para PC es
ilimitado, no como ocurre en el terminal ya que se usa la propia pila de Windows.
Para evitar el desbordamiento de la pila, es aconsejable ubicar los descriptores en
el heap, usar solo los objetos automáticos para cadenas y datos de tamaño
pequeño y así evitar programar de forma recursiva (si esto último no fuera
evitable, deberían ser minimizados los tamaños de los parámetros pasados y de
las variables automáticas usadas en la parte recursiva).

II. CleanUp Stack

En un sistema limitado en memoria como es un teléfono móvil se debe prestar

especial atención a la gestión de la memoria, para este fin Symbian implementa un
mecanismo propio denominado Cleanup Stack. El Cleanup Stack es una pila
especial que guarda o almacena los punteros a los objetos que se ven en la
necesidad de ser liberados cuando una excepción sucede. Todas las aplicaciones
tienen consigo su propio Cleanup Stack que se crea por defecto. Cualquier
puntero localmente definido que apunte a un objeto que esté ubicado en el heap
debe añadirse al Cleanup Stack, de existir algún riesgo de que una excepción
tenga lugar y no hay ninguna otra referencia al objeto. Si no tiene lugar ninguna
excepción, los punteros deberán ser eliminados de la pila, por el programador. Los
datos pertenecientes a las instancias de una clase no pueden añadirse al Cleanup
Stack ya que estos son eliminados por el destructor de la clase.
III. Construcción en dos fases

De igual manera, los destructores y los constructores de los objetos no pueden

generar excepciones, ya que, si esto ocurre, podrían producirse fugas de
memoria. Para solucionar este problema, la construcción de objetos se ejecuta en
dos fases. En una primera fase lleva a cabo la inicialización del objeto y en la
segunda fase, usando el CleanUp Stack, se efectúa la asignación de memoria, de
tal manera que, si en esta fase se produjera alguna excepción, la memoria
asignada hasta ese punto, sería correctamente liberada.

IV. Manejo de excepciones

Symbian proporciona sus propios mecanismos para el manejo de excepciones.

El sistema de excepciones de Symbian está adaptado a las normas de
programación usadas en Symbian (clases C, clases T, códigos de error de 32 bit.)
con esto se evita la sobrecarga introducida por el mecanismo de manejo de
excepciones de C++(try, catch y throw).El manejo de excepciones empleado en
Symbian se basa fundamentalmente en la macroTRAP y sus variantes (p.e.
TRAPD permite que el código se ejecute en un ambiente protegido (trapharness))
y en la llamada User::Leave() la cual, en caso de mal funcionamiento, termina la
ejecución de la función actual y devuelve el código del error.

V. Procesador

Los procesadores de los dispositivos más recientes son procesadores RISC con
frecuencias de reloj que rondan los 200MHz, frecuencia que resulta adecuada
para la mayoría de las aplicaciones. Sin embargo el desarrollador debería tener en
mente que los procesadores no disponen de unidad de punto flotante (UPF). Por
este motivo se recomienda evitar en la medida de
lo posible el uso de notación en punto flotante, ya que la velocidad de ejecución de
la aplicación podría experimentar una disminución considerable