CARAMEL: Detecting and Fixing Performance Problems That

Have Non-Intrusive Fixes

Caramel: Deteccion y solucion de problemas de rendimiento que
tiene soluciones no-intrusivos
El software intrusivo es aquel que para llevar acabo su

tarea, interrumpe otras funcionalidades del sistema en

el que se usa.
El no intrusivo, realiza su labor sin interrumpir y
corriendo al lado de otros procesos.
En materia de seguridad, el software intrusivo, es el que
manipula datos y la funcionalidad del sistema, sin
consultar al operador.
El no intrusivo vendria siendo lo contrario.

Abstract:
Errores de funcionamiento son errores de programacion que relentizacion la
ejecucion de un programa. Mientras que las tecnicas existentes pueden detectar
varios tipos de errores de rendimiento, un aspecto crucial y practico de los
errores de funcionamiento que no ha recibido la atencion que merecen: Qu
posibilidades tienen los desarrolladores para corregir un error? En la practica,
solucionar un error de funcionamiento puede tener tanto ventajas como
invenientes, y desarolladores solo solucionan un error de funcionamiento solo
cuando los beneficios superan a los incovenientes. Desafortunadamente, para
muchos errores de funcionamiento, los beneficios e inconvenientes son
dificiles de evaluar con precision.
Este paper presenta CARAMEL una novedosa tecnica estatica que detecta y
soluciona errores de funcionamiento que tiene soluciones no-intrusivas capaces
de ser adaptadas por los desarrolladores. Cada error de funcionamiento
detectado por CARAMEL se asocia con un bucle y una condicion. Cuando la
condicion se convierte en verdadera durante la ejecucion del bucle, todo el
calculo restante realizado por el bucle se desperdicia. Tipicamente
desarrolladores solucionan dichos errores de rendimiento debido a que esos
errores desperdician calculos en bucles y tienen soluciones no-instrusivas:
cuando alguna condicion se convierte en verdadera dinamicamente, salir del
bucle. Dado un programa, CARAMEL detecta algunos errores de forma
estatica y le da al desarrollador una posible solucin source-level para cada
error. Evaluamos CARAMEL en aplicaciones del mundo-real, incluyendo 11
aplicaciones Java (Groovy, Log4J, Lucene, Struts, Tomcat, etc) y 4
aplicaciones C++ ampliamente usadas (Chromium, GCC, Mozilla, MySql).
CARAMEL encontro 61 nuevos errores de funcionamiento en aplicaciones

Java y 89 nuevos errores de funcionamiento en aplicaciones C++. Basados en

nuestros reportes de errores, desarrolladores han solucionado 51 y 65 errores
de funcionamiento en aplicaciones Java y C++, respectivamente. La mayoria
de errores restantes todavia estan bajo consideracion de desarrolladores.
Introduccion:
El rendimiento del software es critico para el xito de un proyecto de software,
errores de rendimiento son errores de programacion que relentizan la ejecucion
de un programa. Errores de rendimiento crean una pobre experiencia de
usuario, afectan la calidad de software percibida por el usuario, degradan la
respuesta de las aplicaciones, gastan recursos computaciones, y bajan el
rendimiento del sistema. Incluso los programadores expertos pueden introducir
errores de funcionamiento, que ya han causado graves y muy publicitado
incidentes. Productos comerciales bien testeados tales como Internet Explorer,
Microsoft SqlServer, Visual Studio, Acrobat Reader estan tambien ya afectados
por errores de funcionamiento.
Algunas tecnicas han sido propuestas para ayudar a detectar varios tipos de
errores de funcionamiento. Sin embargo hay muchos errores de
funcionamiento que no pueden ser detectados por las tecnicas existentes. Por
otra parte, un aspecto crtico y prctico de los errores de funcionamiento es que
no ha recibido la atencin que merece: Qu posibilidades tienen los
desarrolladores para corregir un error?.
En la practica, cuando desarrolladores deciden si ellos deberan solucionar un
error de rendimiento , los desarrolladores se enfrentan a una difcil eleccin
entre los posibles inconvenientes y los posibles beneficios de la correccin.
Por un lado, similar a solucionar errores funcionales, solucionar errores de
rendimiento pueden tener inconvenientes. Primero, solucionar errores de
funcionamiento pueden introducir errores funcionales graves, que pueden
conducir a la caida del programa o la perdida de datos. El riesgo de tener
efectos tan negativos y notables puede hacer a los desarrolladores muy
cauteloso a la hora de mejorar el rendimiento. En segundo lugar, corrigiendo
errores de rendimiento puede romper las buenas prcticas de ingeniera de
software, haciendo que el cdigo sea difcil de leer, mantener y evolucionar.
Por ejemplo, solucionar errores de rendimiento deba requerir romper la
encapsulacion, clonamiento de codigo, o especializacion. Tercero, solucionar
errores de rendimiento toma tiempo y esfuerzo, especialmente si la solucion
incluye algunos modulos de software o requiere una implementacion compleja.
Cuarto solucionar errores de rendimiento, que se manifiestan en algunas
entradas, pueden relentizar otro codigo, para algunas otras entradas, y
desarrolladores deben decidir cual de esos relentizaciones-la relentizacion
causada por el error de rendimiento para algunas entradas, o la relentizacion
causada por la solucion de alguna otra entrada- es preferible.

Por otra parte, corrigiendo errores de rendimiento tiene beneficios, es decir,

que acelera cdigo. Sin embargo, a diferencia de solucionar errores de
funcionamiento, los beneficios de solucionar un error de rendimiento son a
menudo difciles de evaluar con precisin, especialmente cuando la solucin es
compleja. En primer lugar, el aumento de aceleracion que ofrece la solucin
depende de la entrada, y muchos entradas no puede ser acelerado en absoluto,
debido a errores de rendimiento se manifiestan slo para ciertos entradas. Por
lo tanto, los desarrolladores necesitan estimar qu entradas tienen que
acelerarse y cuan importante y con que frecuencia estas esas entradas en
practica. Segundo, la aceleracion exacta ofrecida para la solucion de alguna
entrada es dificil de estimar sin ejecutar el codigo, y la velocidades de ordenes
de magnitud es decir aceleraciones para los que estimaciones precisas no son
necesarias, son una rareza. Desafortunadamente, los desarrolladores a menudo
tienen acceso a slo unas pocas entradas en el mundo real que desencadenan
un error, o ninguno en absoluto, si se ha detectado el error durante el desarrollo
usan puntos de referencia, herramientas estticas, o inspeccion de cdigo, y
pueden tener dificultades para estimar la esperada aceleracion para el resto de
las entradas del mundo real que pueden desencadenar el error.
En la practica, desarrolladores solucionar errores de funcionamiento cuando
los beneficios superan a los inconvenientes. En concreto, los desarrolladores
son propensos a corregir los errores de rendimiento que tienen soluciones
simples y no intrusivas. Tales soluciones son poco probables de introducir
nuevos errores funcionales, no aumentan los costos de la complejidad del
cdigo y de mantenimiento, son fciles de entender y poner en prctica, y es
improbable que degraden el rendimiento de otras entradas. En otras palabras,
la eleccion entre beneficios e inconvenientes es facil de determinar para
desarrolladores: porque las soluciones son simples y no intrusivas, solucionar
los errores trae solo beneficios.
Este paper hace la siguiente contribucion:
Perspectiva novedosa: en comparacin con trabajos anteriores, este trabajo
tiene una perspectiva nica hacia la deteccin de errores de rendimiento: nos
centramos en la deteccin de errores que son muy probables que se solucionen
por los desarrolladores. Despus de la discusin anterior, proponemos detectar
errores de rendimiento cuyas soluciones claramente ofrezcan mas beneficios
que incovenientes a los desarrolladores.
Nueva familia de errores de rendimiento: En este trabajo se identifica una
familia de errores de rendimiento que los desarrolladores son muy propensos a
solucionar. Cada error en esta familia est asociada con un bucle y una
condicin. Cuando la condicin se convierte en verdadera durante la ejecucin
del bucle, todo el cmputo restante realizado por el bucle se desperdicia. En el
caso extremo, cuando la condicin es verdadera en el inicio de la ejecucin del
bucle, todo el clculo de bucle se desperdicia. Generalmente, los
desarrolladores corregir los errores de rendimiento en esta familia debido a que
(1) estos errores gastan clculos en los bucles, y (2) estos errores de

rendimiento tienen soluciones simples y no intrusivas: cuando alguna

condicin se convierte en verdad, solo romper el bucle. Tipicamente, esos
errores son solucionados agregando una linea de codigo dentro del bucle (es
decir un condicion break) la cual llamamos una solucion CondBreak.
Llamamos condicion a una condicion de L-break.
Errores de rendimiento importantes: Los errores de rendimiento de esta
familia son importantes: los desarrolladores de aplicaciones del mundo real
normalmente solucionan estos errores. Los desarrolladores son los rbitros
finales de lo que es til y lo que no es til para su proyecto, y los
desarrolladores suelen pensar que estos errores se deben abordar. Por otra
parte, estos errores no son todos los errores de rendimiento que tienen arreglos
no intrusivos, y nuestro trabajo es un primer paso prometedor en esta lnea de
investigacin importante.
Tcnica: En este trabajo se propone CARAMEL, una tcnica novedosa y
esttica para la deteccin de errores de funcionamiento que tienen CondBreak.
CARAMEL toma como entrada un programa y da salida los bucles que pueden
ser corregidos por correcciones de CondBreak, junto con una posible solucin
para error de bucle. Las correcciones propuestas por CARAMEL se pueden
aplicar directamente al codigo fuente y son fciles de leer por los
desarrolladores. CARAMEL trabaja en la representacin del cdigo intermedio
y analiza cada bucle en cinco pasos. En primer lugar, CARAMEL identifica las
instrucciones de bucle que pueden producir resultados visibles despus de que
el bucle termina. En segundo lugar, para cada una de tales instrucciones,
CARAMEL detecta la condicin bajo la cual la instruccin se puede omitir
para el resto del bucle sin cambiar el resultado del programa. Llamamos a esta
condicin una condicin I-Break, de manera similar a la condicin L-Break
descrito anteriormente para todo el circuito. En tercer lugar, CARAMELO
chequea si todas las instrucciones desde el paso dos se pueden saltar al mismo
tiempo sin cambiar el resultado del programa, es decir, si todas las condiciones
I-Break se pueden satisfacer simultneamente. La conjuncin de todas las
condiciones de la I-Break es la condicin L-Break. En cuarto lugar,
CARAMEL comprueba si el residuo del calculo en el bucle no est evitada, es
decir, si el bucle todavia no ha terminado cuando la condicion L-Break se
cumple. Si todos los pasos anteriores tienen xito, CARAMEL informa de un
error de rendimiento. En quinto lugar, CARAMEL genera una solucin para el
error rendimiento. La revisin tiene el formato bsico if (cond) break, donde
cond es la condicin L-Break CARAMEL calculado en la tercera etapa.
Generacin automtica de la Solucon: una solucion automatizada
esdesafiante en general [30], pero CARAMEL es capaz de generar
automticamente las correcciones para la mayora de los errores porque
CARAMEL aprovecha las ventajas de las dos caractersticas de los errores de
rendimiento que detecta: (1) los errores tienen correcciones CondBreak, que se
pueden insertar justo el principio del bucle, evitando de este modo las
interacciones complejas con otro cdigo de bucle, y (2) la condicin L-Break

en una solucin CondBreak es una relativa expresion simple booleana

(Secciones II, III).