SimiOO: Un Ambiente de Simulación basado en Plug-ins

SimiOO: Un Ambiente de Simulación basado en Plug-ins Augusto J. Vega, Miembro IEEE José LuisHamkalo,Miembro IEEE, ACM Bruno Cernuschi-Frías, Miembro IEEE, ACM {ajvega,jhamkal,bcf}@fi.uba.ar Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 C1063ACV - Capital Federal (ARGENTINA) Te.: +54 11 4343-0891 int. 278 Resumen En este trabajo presentamos un ambiente para el estudio de organizaciones de memoria caché mediante la técnica de simulación manejada por traza (trace-driven simulation). Esta herramienta, llamada SimiOO, está construida sobre la Plataforma de Cliente Rico (Rich Client Platform), de reciente aparición en el Proyecto Eclipse. SimiOO es una herramienta pública y de código abierto, que permite procesar trazas de referencias a memoria. En este sentido, la simulación manejada por traza es un caso particular. Sin embargo, es posible implementar diferentes funcionalidades mediante la construcción de nuevos plug-ins. Como consecuencia, este trabajo muestra una posibilidad de integración de herramientas de desarrollo de software (como ser Eclipse y el lenguaje Java) en el ámbito de la computación científica. Palabras clave: plug-ins, programación orientada a objetos, software reusable, simulación de memorias caché. 1

1. Introducción En el estudio y diseño de organizaciones de memoria caché, una de las técnicas más empleada es la simulación manejada por traza (trace-driven simulation). Una traza de direcciones (o traza, para abreviar) consiste en una secuencia de referencias a memoria [8] realizadas por uno o más programas (benchmarks) durante su ejecución. De esta forma, se dispone de un historial que representa el comportamiento (lecturas y escrituras) del sistema de memoria, que podría utilizarse para simular otras organizaciones de interés. Por otra parte, la recolección de trazas (tema que excede el alcance de este artículo), fue tratado por Vega et al. [9], y Uhlig et al. [8]. Una vez recolectadas las trazas de referencias a memoria, resta procesarlas para obtener resultados de valor. Por ejemplo, se la podría convertir de su formato original a uno nuevo, o tomarla desde un archivo de texto plano y almacenarla en un archivo comprimido, aplicarle algún tipo de filtrado o muestreo, etc. Si bien en este trabajo se trata la simulación de memorias caché manejada por traza, se desarrolló unentorno(framework) lo suficientemente flexible tal que el usuario final pueda adaptarlo a sus necesidades. Esta herramienta, llamada SimiOO y que presentaremos a continuación, está construida sobre la Plataforma de Cliente Rico (Rich Client Platform), de reciente aparición en el Proyecto Eclipse [2]. Esta característica permite que SimiOO pueda ser extendido, mediante la construcción de plug-ins para lograr diferentes funcionalidades, adaptándose a las necesidades del usuario. 2. El Proyecto Eclipse El Proyecto Eclipse comienza en noviembre de 2001, como la unión de varias empresas de tecnología de la información (Borland, IBM, MERANT, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft y Webgain). El propósito de este consorcio consiste en...promover la creación, la evolución, el fomento, y el soporte de la Plataforma Eclipse y cultivar una comunidad de código abierto y un ecosistema de productos complementarios, capacidades, y servicios. [2]. Actualmente, la comunidad Eclipse mantiene y desarrolla el producto público y de código abierto Eclipse SDK (para desarrollo de aplicaciones), junto con un gran número de proyectos asociados. Eclipse SDK es más que una herramienta para el desarrollo de aplica- 2

ciones. En los últimos tiempos (particularmente con el lanzamiento de sus versiones 3.x), se ha convertido en una plataforma flexible, capaz de ser adaptada a cualquier necesidad, ya que se construye a partir de plug-ins. Además, ofrece un conjunto de herramientas para la construcción de interfaces gráficas de usuario, como ser SWT (Standard Widget Toolkit) y JFace. 2.1. La Plataforma de Cliente Rico - RCP Un cliente rico consiste en una porción de software que implementa toda la funcionalidad específica de la aplicación en el lado cliente, en contraposición al concepto de cliente delgado, en donde toda la funcionalidad específica de la aplicación está controlada en el lado servidor (típicamente, aplicaciones web) [1]. IBM junto con la comunidad Eclipse han desarrollado una arquitectura de cliente rico, conocida como Plataforma de Cliente Rico (Rich Client Platform RCP) [7], que permite trasladar las ventajas y características de Java hacia el lado del cliente, permitiendo la construcción de aplicaciones de escritorio robustas y vistosas. Si bien en la versión 2.x de Eclipse ya era posible la construcción de nuevas funcionalidades a través de plug-ins, debían restringirse a aplicaciones de tipo IDE (Integrated Development Environment) [1]. A partir de la versión 3, el desarrollador puede utilizar Eclipse como marco para nuevas aplicaciones, reutilizando los menúes, barras de herramientas, sistema de ayuda, etc. Más aún, RCP es en sí mismo una versión más reducida de la plataforma Eclipse 3.x, a la cual se le quitan varios plug-ins. 2.2. El Modelo de Plug-ins Un plug-in es una construcción de software que implementa una funcionalidad bien definida, y que es capaz de extender a otros programas para ofrecer sus servicios. En Eclipse, además, es la unidad más pequeña de extensión. Cuando la plataforma Eclipse comienza a ejecutarse, una de las primeras tareas que realiza consiste en relevar cuáles son los plug-ins disponibles y, así, construye una estructura llamada registro de plug-ins (plug-in registry). A lo largo de la ejecución de Eclipse, los plug-ins serán efectivamente cargados a memoria cuando sean utilizados por primera vez. Para que un plug-in sea añadido al registro, deberá estar almacenado (junto con sus recursos asociados) en el directorio de plug-ins de la plataforma Eclipse. 3

En Eclipse, todo plug-in está acompañado por un documento XML que lo define. Este archivo, conocido como manifiesto (y llamado plugin.xml), tiene una estructura similar a la que se muestra a continuación: <?xml version="1.0" encoding="utf-8"?> <?eclipse version="3.0"?> <plugin> <extension point="org.eclipse.ui.perspectives"> <perspective class="org.simulator.simulatorperspective" fixed="true" id="org.simulator.simulatorperspective" name="the Simulator Plugin"/> </extension> <extension point="org.simioo.traceprocessor"> <traceprocessor class="org.simulator.domain.core.simulatortraceprocessor" id="org.simulator.simulatortraceprocessor" name="simulator"/> </extension>... </plugin> La interfaz entre dos plug-ins (el que extiende yelextendido) seconoce como punto de extensión (extension point). Básicamente, unpuntodeextensión es la entrada a través de la cual un plug-in puede aportar una nueva funcionalidad. En el archivo plugin.xml presentado antes, una extensión se aporta definiendo el elemento XML extension. En ese caso, las extensiones aportadas son una perspectiva (agrupamiento de vistas) y un procesador de trazas (en la figura 1 se muestra de qué maneraunplug-in extiende a otro através de sus puntos de extensión). 4

Figura 1: Extensión de un plug-in. Además de los puntos de extensión, el anfitrión puede definir acciones globales (retargetable actions). Estas acciones, que son implementadas por el plug-in que extiende, tienen una semántica única. Como ejemplos, encontramos el caso de las acciones nuevo, abrir, cerrar y guardar. En ese caso, cada plug-in las implementará con un comportamiento adecuado, pero la semántica de la acción se conserva. A continuaciónsemuestralaformaen que el plug-in anfitrión crea una acción global: IAction copyaction = new RetargetAction( SimiooDefines.SIMIOO_NEW, "Nuevo"); La creación de una acción global requiere un id y una etiqueta. El id le permite a otro plug-in poder identificar la acción global a implementar, según se muestra a continuación: getviewsite().getactionbars().setglobalactionhandler( SimiooDefines.SIMIOO_NEW, newprojectaction ); 5

Donde newprojectaction es una instancia IAction que implementa el método run() con el comportamiento deseado para la acción global. Por otra parte, un plug-in podría no implementar todas las acciones globales definidas en el anfitrión, en cuyo caso, quedarían deshabilitadas. 3. La Herramienta SimiOO En esta sección se presenta SimiOO, una herramienta pública y de código abierto, que permite procesar trazas de referencias a memoria. En este trabajo, procesar una traza significará simular organizaciones de memoria caché a partir de ella. Sin embargo, es posible implementar diferentes funcionalidades mediante la construcción de nuevos plug-ins dado que su diseño se basa en la Plataforma de Cliente Rico presentada anteriormente. El usuario final, ante la necesidad de nuevas funcionalidades, solamente deberá construir su propio plug-in (en lenguaje de programación Java) que se integrará naturalmente a la herramienta SimiOO. En esta etapa, un plug-in de simulación de memorias caché (manejada por traza) se distribuye junto a SimiOO. El mismo soporta cualquier organización de una o más vías, asociativa por conjuntos y con direccionamiento por bits. Además, pueden definirse diferentes políticas de reemplazo, tamaños de las vías, etc. [4] 3.1. Diseño General Uno de los aspectos más importantes de SimiOO tiene que ver con la interfaz gráfica presentada al usuario (ver figura 2), compuesta por los siguientes elementos: Barra de menúes: en la parte superior de la pantalla, presenta los menúes básicos (File, Run, Plugins, Help). Barra de herramientas: implementa, mediante botones y otros controles gráficos, muchas de las funcionalidades de la barra de menúes. Perspectiva: región principal de la pantalla, donde el plug-in despliega información e interactúa con el usuario. Un plug-in aporta una perspectiva a SimiOO, y tiene la libertad de administrar el contenido de la misma según su conveniencia. Toda perspectiva estará integrada por una o más vistas. 6

La barra de menúes está integrada por las acciones que se listan en la tabla 1. Por otra parte, cada menú agrega dos secciones (group markers) al principio y al final en donde, de ser necesario, un plug-in podría agregar sus propias opciones (no globales). Menú File Run Plugins Help Opción New Open Close Save Exit Play Pause Stop Open Trace (lista de plugins disponibles) Preferences Help Contents About SimiOO Cuadro 1: Acciones definidas en SimiOO. La barra de herramientas está constituida por botones gráficos, que equivalen a algunas de las acciones (las más utilizadas) de la barra de menúes. A su vez, un plug-in podría agregar sus propios controles gráficos aestabarra. La perspectiva es lo que el plug-in está interesado en mostrarle al usuario en la región principal de la pantalla. Por ejemplo, para el caso del plug-in de simulación, la perspectiva está integrada por tres vistas: una para visualizar la representación gráfica de cada organización simulada, otra para navegar (en una jerarquía de árbol) las diferentes organizaciones, y otra para desplegar mensajes al usuario. El plug-in le aporta una perspectiva a SimiOO a través del punto de extensión org.eclipse.ui.perspectives. El otro aspecto importante tiene que ver con la forma en que un plug-in externo se enchufa en SimiOO. Para este fin, SimiOO define 7

Figura 2: Interfaz gráfica de SimiOO, presentada al usuario. un punto de extension propio (es decir, no perteneciente al conjunto estándar de puntos de extensión provistos por Eclipse) denominado org.simioo.traceprocessor, que permite aportar la lógica de procesamiento de cada referencia obtenida de la traza. Para ello, todo plug-in que desee contribuir a SimiOO a través de este punto, deberá extender la clase org.simioo.clients.simiootraceprocessor, sobreescribiendo, entre otros, los métodos initprocessor(), processreference(memoryreference) y finalizeprocessor(). De esta forma, el ciclo de vida de un procesador de trazas está definido por la siguiente secuencia (ver figura 3): 1. Inicialización del procesador (initprocessor()). 2. Lectura secuencial de la traza, e invocación al método de procesamiento (processreference(memoryreference)) por cada referencia leída. 8

3. Finalización del procesador (finalizeprocessor()). Es importante aclarar que ninguno de estos métodos debe ser obligatoriamente sobreescrito. En caso que el plug-in no lo haga, esa etapa tendrá un comportamiento nulo. Por otra parte, también es preciso notar que todo el trabajo de lectura de la traza y control de reproducción se encuentra del lado de SimiOO, lo cual permite el desarrollo de plug-ins livianos, cuya única preocupación radica en el procesamiento a aplicar a cada referencia leída. Figura 3: Integración SimiOO - Plug-in. 3.2. El Sistema de Ayuda Otra de las facilidades provistas por RCP tiene que ver con el sistema de ayuda, que también puede ser extendido (a partir del punto de extensión org.eclipse.help.toc). El mecanismo es simple, partiendo de la definición de una extensión en el plug-in, como se muestra a continuación: <extension point="org.eclipse.help.toc"> 9

<toc file="toc.xml" primary="true"/> </extension> El archivo toc.xml, al cual se hace referencia, define la estructura de la ayuda, e indica las fuentes a partir de las cuales se toman los contenidos (archivos HTML locales o URLs remotas). Por ejemplo, podría lucir de la siguiente manera: <?xml version="1.0" encoding="iso-8859-1"?> <toc label="the SimiOO Project Help" topic="html/help.html"> <topic label="overview" href="html/overview.html"/> <topic label="user Guide" href="html/user_guide.html"/>... </toc> 4. El Plug-in de Simulación A continuación se presentará, con más detalle, el plug-in de simulación de memorias caché, que se distribuye junto a SimiOO. Este implementa la técnica de simulación manejada por traza, que permite evaluar el desempeño de organizaciones de memoria caché, en base a la secuencia (traza) de referencias a memoria realizada por un conjunto de programas (benchmarks). 4.1. Diseño General El plug-in de simulación extiende al entorno SimiOO, aportándole una perspectiva, un conjunto de vistas y un procesador de trazas. Como ya se señaló, una perspectiva agrupa vistas, y permite la construcción de una interfaz gráfica de usuario. El plug-in que extiende, tiene la libertad de disponer el contenido de la perspectiva y las vistas como prefiera; en particular, la aportada por el plug-in de simulación contiene tres vistas: un navegador de organizaciones de memoria (en el lado izquierdo de la pantalla), una vista de representación gráfica y visualización de información (en la parte superior derecha de la pantalla), y una vista de mensajes (en la parte inferior derecha de la pantalla), según puede verse en la figura 4. 10

Figura 4: Interfaz gráfica del simulador. Por otra parte, el procesador de trazas aportado a SimiOO (y que extiendealaclasesimiootraceprocessor), toma cada referencia leída desde la traza abierta, y la alimenta en cada organización caché simulada. 4.2. Integración Dominio Interfaz El plug-in de simulación presenta dos aspectos muy bien definidos: por un lado, los objetos del dominio (memorias, organizaciones de memorias, referencias, etc.) y, por el otro, la representación gráfica de los mismos. En el caso particular de la vista (árbol) de navegación de organizaciones, la relación entre los objetos del dominio y su representación gráfica, se llevó a cabo utilizando el modelo de proveedores de contenidos y rótulos de JFace [5]. Un proveedor (de contenidos o rótulos) es una clase que se comporta como intermediario adaptando los datos del dominio al formato utilizado por 11

los controles gráficos, lográndose así un alto nivel de desacoplamiento. 4.3. Dominio El paquete org.simulator.domain.memory contiene todas las clases relacionadas al dominio del problema, como ser: Block, Memory (composición de bloques), Way (composición de memorias), y MemoryOrganization (composición de vías). En la figura 5 puede apreciarse esta relación. Figura 5: Relación de los objetos del dominio. Esta relación entre los objetos del dominio permite un alto nivel de flexibilidad al momento de construir organizaciones de memorias caché para simular. Por ejemplo, una memoria caché de correspondencia directa (Direct Mapped DM) de 64 kbytes, con bloques de 32 bytes, se construiría con 2048 instancias Block, todas ellas agrupadas en una instancia Memory,contenida en una instancia Way, contenida en una instancia MemoryOrganization. De igual forma, podrían armarse otras organizaciones, con dos o más vías, incluso asimétricas (diferente cantidad de memorias en cada vía), como la presentada por Hamkalo et al. [3]. 4.4. Motor de Simulación Por su parte, la clase MemoryOrganization también contiene la lógica de simulación. A través de un método, es posible alimentarla con las referencias leídas desde la traza, lo cual producirá aciertos (hits) o desaciertos (misses) en la memoria, con sucesivas actualizaciones de la información estadística de cada bloque. Es preciso aclarar que, en esta primer etapa del proyecto, solo se contempla la política de reemplazo LRU (Least Recently Used). La clase SimulatorTraceProcessor es la responsable de alimentar cada una de las organizaciones simuladas, con las referencias leídas. Esta clase extiendealaprovistaporsimioo, SimiooTraceProcessor, sobreescribiéndo- 12

le los métodos de inicialización, finalización y procesamiento de referencias (ver figura 6). Figura 6: Modelo de clases del motor de simulación. 5. Conclusiones Se presentó unambiente,público y de código abierto, para el estudio de organizaciones de memoria caché mediantelatécnica de simulación manejada por traza (trace-driven simulation). Esta herramienta, llamada SimiOO, está construida sobre la Plataforma de Cliente Rico (Rich Client Platform) del Proyecto Eclipse, y basada en plug-ins. Estaúltima característica permite la implementación de diferentes funcionalidades aplicables a una traza, tales como convertirla de su formato original a uno nuevo, o tomarla desde un archivo de texto plano y almacenarla en un archivo comprimido, aplicarle algún tipo de filtrado o muestreo, etc. En este sentido, la simulación manejada por traza es un caso particular. Finalmente, este trabajo muestra una posibilidad de integración de herramientas de desarrollo de software (como ser Eclipse y el lenguaje Java) en el ámbito de la computación científica [6]. 13

6. Agradecimientos El presente trabajo cuenta con subsidios de la Universidad de Buenos Aires y el Consejo Nacional de Investigaciones Científicas y Técnicas (CO- NICET). Referencias [1] B. Daum, Professional Eclipse 3 for Java Developers, Wrox, 2004. [2] The Eclipse Project; http://www.eclipse.org/ [3] J. Hamkalo, A. Vega, B. Cernuschi Frías, SWSA-MT: Un Esquema de Memoria Caché para Ambientes Multihilo, 5th Argentine Symposium on Computing Technology (AST 04), 2004. [4] J. L. Hennessy, D. A. Patterson, Computer Architecture. A Quantitative Approach, 3ra Edición, Morgan Kaufmann Publishers, 2000. [5] JFace, http://wiki.eclipse.org/index.php/jface [6] D. A. Patterson, Computer Science Education in the 21st Century, Communications of the ACM, vol. 49, no. 3, 2006, pp. 27-30. [7] Rich Client Platform, http://wiki.eclipse.org/index.php/rich Client Platform [8] R. A. Uhlig, T. N. Mudge, Trace-Driven Memory Simulation: A Survey, ACM Computing surveys, vol. 29, no. 2, 1997, pp. 128-170. [9] A. Vega, J. Hamkalo, B. Cernuschi Frías, Generación de Trazas Multihilo Simultáneo, 6th Argentine Symposium on Computing Technology (AST 05), 2005. 14