instrumentacion de código - ctr.unican.es · diseño y evaluación de configuraciones...

Instrumentacion de código

Miguel Telleria de Esteban

telleriam AT unican.es

Computadores y Tiempo Real

http://www.ctr.unican.es

Diseño y Evaluación de Configuraciones

Curso 2010-11

http://www.ctr.unican.es/

5 Abr 2011 Miguel Telleria de Esteban telleriam AT unican.es) Página 2 de 29

Instrumentacion de códigoDiseño y Evaluación de ConfiguracionesComputadores y Tiempo RealUniversidad de Cantabria

Contenido● Introducción

● Medida de tiempo en java

● Dynamic Probekit de TPTP

Introducción



Estrategias para medir el tiempo en un programa● De menor a mayor intrusismo

● Monitorización externa periódica (top, htop, ps)

– El programa y el sistema se ejecutan de manera independiente

– Los muestreos se realizan puntualmente a nivel de sistema

● Activación de las trazas del kernel

– El programa sigue ejecutándose igual

– El sistema está instrumentado y nos da información del programa

● Ejecución bajo un profiler

– El programa se ejecuta en un entorno de vigilancia

● Instrumentación de código fuente

– El programa se ejecuta modificado

– Java permite instrumentar en el Bytecode (BCI)



Concepto de instrumentación de código● Idea:

● Se insertan sondas en el código fuente (o en el binario)● Estas sondas recogen información que nos interesa

– Timestamps absolutos, de ejecución

– Información aplicativa (pid, dato)

● Estos datos se almacenan rápidamente en bruto y en un buffer● Se analizan externamente

● Necesitamos:● Conocer el código fuente de la aplicación a debuguear

● Poder modificar dicho código



Tiempo transcurrido y tiempo de proceso● Tiempo transcurrido (Wall clock time):

● Desde que empezamos hasta que acabamos incluyendo todo

● Es influido por otros procesos o sistemas externos

– Procesos de mayor prioridad

– Sobrecargas externas

● No representa el consumo de recurso (CPU, red...)

– No es lo más aconsejable para nuestros modelos

● Sí representa un objetivo (plazos, deadlines)

● Tiempo de proceso (CPU time)● Tiempo que estamos realmente ejecutando

● Indepediente de la carga del sistema

– mientras podamos ejecutar

● Válido para modelos



Tiempo transcurrido y tiempo de proceso (II)● Buenas noticias

● El sistema operativo lleva la cuenta del tiempo de proceso

– Lo necesita para implementar la planificación, balance de carga...

● Existen estandares de API para la obtención de este tiempo

– POSIX

– RTSJ

● Malas noticias● Java 1.6 no contempla este concepto en su API

● Alternativas para obtener el tiempo de proceso en Java● Medir TODO el sistema (o el más prioritario) e ir descontando trozos

– Es lo que hacen los profilers (Eclipse TPTP, Jensor...)

● JNI: Hacemos visibles los servicios POSIX a nuestras clases en Java

Midiendo el tiempo desde Java



Medida de tiempos en Java● Java tiene ciertas limitaciones intrínsecas para dar precisión

● Garbage collector● JIT compiling

● En JRE 1.6 sólo existen 2 funciones de medidas de tiempo (ambas en la clase System)

● public static long currentTimeMillis()

– Resolución de milisegundos

● public static long nanoTime()

– Resolución de nanosegundos

– Precisión: Los jiffies del kernel (msg)

● Ninguna de ellas soporta tiempos de ejecución



Opción 1: Real Time Specification for Java (RTSJ)● Es una especificación de API (javax.realtime)

● Existen diferentes implementaciones

– http://java.sun.com/javase/technologies/realtime.jsp

– http://en.wikipedia.org/wiki/Javolution

● La experiencia de sistemas de tiempo real llevada a Java● Limitación de acción del garbage collector

● Políticas de planificación estrictas

● Mutexes con techos de prioridad o herencia de prioridad● Relojes de tiempo de ejecución● …

● Basado en las API's POSIX de tiempo real

http://java.sun.com/javase/technologies/realtime.jsp



Opción 2: Métodos JNI con la API de POSIX

● Valida para el Java normal

● Nos permite usar tecnología genérica (no sólo de Java)

● Es la que vamos a usar

● Vamos a cambiar a C un rato



Soporte de POSIX en el kernel Linux● La gestión del tiempo está definida en el estándar 1003.1a

(Extensiones de tiempo real) y no en el estándar que define los PThreads (1003.1b).

● Aunque pertenezca a la parte de tiempo real ya está plenamente integrado en el kernel sin necesidad de añadir ningún parche externo

● El soporte está implementado en el kernel, pero la interfaz se utiliza a través de la glibc que implementa la abstracción de pthreads.

● Desde el kernel 2.6.16 (marzo 2006) se usan los hrtimers para los timers POSIX.

● La resolución pasa a depender del hardware y es superior a los jiffies● Pasamos de milisegundos a microsegundos



Medidas de tiempo en POSIX● Se basan en relojes virtuales (clockid_t)

● A partir de una única fuente de tiempo hardware

– en la CPU o en el chipset

● Se ofrecen diferentes vistas

– Manteniendo un registro de desfase

– Manteniendo estadísticas de consumo de tiempo

● Esos relojes se les puede:● Consultar “la hora”

– Y calcular incrementos

● Preguntar la precisión

● Programar timers

– De tiempo absoluto

– De tiempo relativo

● Dormirse



Tipos de relojes disponibles en POSIX● CLOCK_MONOTONIC

– Wall clock time que mide el tiempo desde que se encendió la CPU

– Es inmutable, no se reajusta nunca

– Puede ser usado por las aplicaciones para periodos cortos de precision

● CLOCK_REALTIME

– Wall clock time pensado para el medir el tiempo del mundo real

– Se ajusta por el administrador, NTP...

– Pensado para medidas de tiempos largos o sincronismo con otros sistemas

● Relojes de proceso

– Mide tiempo consumido por un proceso acumulando el de todos sus threads

– Se obtiene a partir del PID del proceso

● Relojes de thread

– Mide el tiempo consumido por un thread

– Se obtiene a partir de su pthread_t



Demostración● Clase Multithread del proyecto ExecutionTime



API de relojes en Linux (glibc)● #include <time.h>

● Linkar con -lrt

● En Linux el tipo clockid_t es un entero de 32 bits● Necesario saber esto para la JNI

● Los relojes MONOTONIC y REALTIME tienen sus constantes predefinidas

● CLOCK_MONOTONIC

● CLOCK_REALTIME

● Los relojes de proceso se obtienen mediante la función● int clock_getcpuclockid(pid_t pid, clockid_t *clock_id);

● Los relojes de thread se obtienen mediante la función● int pthread_getcpuclockid(pthread_t thread, clockid_t *clock_id);



Formato de tiempo en POSIX● POSIX de tiempo real utiliza la estructura timespec

● Ventaja● Da un amplio rango de resoluciones en arquitecturas de 32 bit

– Desde 1 ns hasta 68 años

● Desventaja● Incómoda de operar

– Todos acabamos definiéndonos macros

● Solución: En sistemas modernos lo pasamos a enteros de 64 bits (long long)

– long long tiempo_64 = tiempo_tspec.tv_nsec + tiempo_tspec.tv_sec*1000000000L

struct timespec{

long tv_sec;long tv_nsec;

};



Usos de relojes POSIX● Pedir la hora

● Pedir la resolución

● Dormirse

● flags 0 (periodo relativo) o TIMER_ABSTIME (instante absoluto)

● request: El periodo de espera o el instante de despertarse

● remain: (sólo en timers relativos) tiempo que queda en caso de interrupción

● Asociar un timer

int clock_gettime(clockid_t clk_id, struct timespec *tp);

int clock_getres(clockid_t clk_id, struct timespec *res);

int clock_nanosleep(clockid_t clock_id, int flags, const struct timespec *request, struct timespec *remain);

int timer_create(clockid_t clockid, struct sigevent *evp, timer_t *timerid);



Interfaz JNI● Un buen recurso (a primer golpe de Google)

● http://macprogramadores.org/documentacion/jni.pdf



Clase Java resultantepackage cpuclock;

public class CpuClock {// Constructor (llamarlo desde el thread)public CpuClock();

// Tiempo de threadpublic long get_thread_time_ms()

// Tiempo de procesopublic long get_process_time_ms()

}

public class PidTid {// Constructorpublic PidTid();

// PID y TIDpublic long gettid();public long getpid();

}



Instalación de la librería JNI● Compilación (como usuario normal)

● Ir al directorio src del workspace● make

● Instalación de la librería en /usr/lib/jni (como root)● make install

● Limpieza de la librería● make clean● make distclean

● Desintalación (como root)● make uninstall

Eclipse TPTP Dynamic Probekits



Dynamic Probekit de TPTP● Permite insertar código de instrumentación en:

– Entrada de método (desde el método llamado)

– Salida de método (desde el método llamado)

– Antes de llamar a un método (desde el método llamante)

– Después de llamar a un método (desde el método llamante)

– Secuencias catch o finalize de una excepción

– Inicializadores estáticos de clase

● En dicho código de instrumentación se puede:

– Utilizar variables globales de la instrumentación

– Acceder al this de la clase y a valores de retorno de funciones

– Acceder a meta-data de la invocación (nombres de método, clase...)

– Lo único que no se puede: acceder a variables locales del método

● Se instrumenta el bytecode (.class)

– Estáticamente (modificando los .class del disco) manualmente

– Dinámicante (en memoria) automáticamente



Creación de una sonda TPTP● La sonda se crea como un fichero en el proyecto eclipse

● New → Other → Profiling and Logging → Probe source file● Se da un nombre a la sonda

– Tiene que acabar en .probe

● Se le asigna una carpeta en el workspace

● Se elige el tipo de sonda

– MethodProbe: Se inserta en el método o clase llamado

– CallsiteProbe: Se inserta en el método o clase llamante

● Opcional: Se especifica que metadata se quiere acceder

– Mejor hacerlo en el diseño de la sonda



Diseño de la sonda TPTP● Una sonda consta de:

● 1 target: Filtro de clase y método

– Lineas include

– Líneas exclude

– Igual que en el maletín de profiling. De hecho este filtro se añade a aquél

● 1 import: (Opcional) Una serie de paquetes que importamos

● 1 o más fragmentos de código java

– De un tipo determinado: entry, exit, catch, beforeCall, afterCall....

– Todos los fragmentos han de ser de la misma categoría

● method Probe · Callsite– Cada uno puede tener sus DataItems (metadata)

– Propiedades: Fragment at Class scope: Contenido global compartido

● Un proyecto eclipse puede tener muchas sondas



Inserción de las sondas● Dinámicamente (en memoria)

● Se hace con el “maletín de TPTP”● Hay que definir bien el filtro de clases si no se ha definido en los targets

de las probes

● Ventajas:

– No se modifican los .class

– No hace falta re-aplicar las sondas manualmente cuando cambia el código o las sondas

● Estáticamente (en ficheros .class)● Se hace desde el proyecto eclipse en menu contextual de las sondas

● Se han de especificar los ficheros .class uno por uno

Practica a realizar



Práctica a realizar● Caracterizar estadísticamente el tiempo de servicio de un

Cliente o Servicio de la práctica.● Que cada uno elija un servicio distinto: cliente a, a1, a2, a3, b, b1, b2

,b3.

● Se ha de instrumentar el método doWork() del Cliente o Servicio

● Se ha de conseguir● Tiempo medio● Desviación típica

● Histograma

●



Procedimiento a seguir● Parra arrancar el sistema usar el script launch.pl

● Luego quitar el componente que queráis medir y arrancarlo desde Eclipse con los parámetros de arranque.

● Crear una probe para el método doWork()● Codigo de ambito de clase (propiedades)

– Declara un ArrayList de tiempos de ejecución (long) y un cpuclock

● Sonda entry:

– Crea un objeto cpuclock (global) y mide el tiempo de CPU inicial en milisegundos añadiéndolo al final del array

● Sonda exit:

– Lee el tiempo de ejecución y substrae el tiempo leído por entry. Pintándolo en pantalla

– Cuando el tamaño del array size llega a 100 escribe los tiempos en un fichero y vacía el array

instrumentacion de código - ctr.unican.es · diseño y evaluación de configuraciones...

Documents