Realistic dose assessments in consultation with

Essa etapa consiste na execução da CECOTOOL. Com relação à análise estática, ela é realizada sobre a aplicação e independe do ambiente, ou seja, a análise só precisa ser realizada uma vez por aplicação. Para este trabalho a ferramenta coletou informações de uso das operações das coleções dos dois benchmarks, Xalan e Tomcat, gerando um arquivo com essa informações de uso. As análises demoraram cerca de 2 a 3 minutos para serem executadas nos benchmarks. É importante ressaltar que os benchmarks apenas cobrem uma parte das aplicações. Assim, a análise não é feita sobre todo o código das aplicações, e sim, sobre o escopo de execução dos benchmarks.

Como explicado no capítulo anterior, essa etapa utiliza a biblioteca WALA - T.J. Watson Libraries for Analysis (2016). A análise estática é baseada em dois arquivos: o primeiro é relativo ao escopo da análise, que neste caso é o arquivo “.jar” da aplicação. Esse arquivo foi gerado manualmente a partir do código fonte dos benchmarks; o segundo arquivo indica o que não faz parte do escopo da análise. Em geral, este arquivo contém informações das bibliotecas utilizadas internamente pela aplicação. Também se faz necessário configurar os pontos de partida da análise estática. Por padrão, a análise estática começa a partir de um método main(). Se necessário, podem-se definir outros métodos como pontos de partida além do método main() Ao final da análise estática, é gerado um arquivo .csv para cada aplicação analisada. Este arquivo contém as informações de uso das estrutura de dados. Essas informações são usadas posteriormente para recomendação das estruturas.

Além da análise de uso das coleções, CECOTOOLtem o segundo objetivo de recomendar uma implementação para as coleções que provavelmente reduzirá o consumo de energia da aplicação. A recomendação ocorre conforme explicado no Capítulo 3.

A ferramenta recebe como entradas os perfis de consumo energia das coleções (Etapa 1) e a análise do uso das coleções (Etapa 2-a). A Tabela 4.1 apresenta o número de recomendações para um determinado tipo para o Xalan, nos respectivos ambientes, assim como a quantidade de ocorrências daquela implementação na versão original. No Xalan foram analisadas 42 variáveis, utilizadas pelo benchmark. Das variáveis analisadas, 31 são do tipo Vector e 11 são Hashtablena versão original.

Para o Tomcat, no entanto, foram analisadas 27 variáveis. Dentre elas, 5 são do tipo Vectore 22 são do tipo Hashtable. Portanto, a Tabela 4.2 apresenta o resumo das recomen- dações para o Tomcat, considerando ambos ambientes.

Como pode ser observado nas tabelas, o número de recomendações pode variar de ambiente para ambiente, uma vez, que para uma mesma variável, podem ser feitas recomendações

4.2. RESULTADOS DOS EXPERIMENTOS 47 Tabela 4.1: Recomendações Xalan × Quantidade na versão original

Implementação #Versão Original #Recomendações

Ambiente1 #Recomendações Ambiente2 Vector 31 7 20 CopyOnWriteArrayList 0 11 11 synchronizedList 0 13 0 Hashtable 11 0 0 ConcurrentHashMap 0 11 11

Tabela 4.2: Recomendações Tomcat × Quantidade na versão original

Implementação # Versão Original # Recomenda-

ções Ambiente1 # Recomenda- ções Ambiente2 Vector 5 3 5 synchronizedList 0 2 0 Hashtable 22 0 0 ConcurrentHashMap 0 22 22

diferentes em ambientes diferentes. Isto deve-se ao fato do perfil de consumo de energia das coleções ser específico para cada ambiente.

Dos benchmarks DaCapo avaliados, percebe-se que ambos utilizam apenas Hashtable e Vector nas suas versões originais como implementações seguras para thread. Percebe-se também que as recomendações variam de acordo com o ambiente no qual a aplicação está sendo executada. Por exemplo, para o Xalan rodando no Ambiente1, são recomendadas 13 trocas de Vector para synchronizedList. Porém, no Ambiente2, não existe nenhuma recomendação deste tipo. No Ambiente1, nas operações de leitura, o synchronizedList consome menos que Vector, mas no Ambiente2 ocorre justamente o inverso.

Além disso, nota-se que a substituição de uma estrutura de dados por outra depende do contexto em que a variável é usada. Logo, para duas variáveis do mesmo tipo, é possível que haja recomendação para que o tipo de uma mude e outra não. Este comportamento pode ser visto por exemplo no Xalan e no Tomcat rodando no Ambiente1, onde é recomendado que algumas variáveis do tipo Vector tenham seu tipo trocado por synchronizedList, enquanto para outras não. Por exemplo, foi recomendado que a variável m_imports, do tipo Vector, no Xalan, rodando no Ambiente1, tivesse seu tipo alterado para synchronizedList devido ao contexto de uso dela, onde operações de leitura ocorreram mais vezes que inserções. Por outro lado, a variável recomposableElements, do tipo Vector, no Xalan, também rodando no Ambiente1, apresentou uma quantidade significativa de inserções. Desta forma, a recomendação foi para que seu tipo não fosse alterado.

Contudo, para todas as variáveis do tipo Hashtable, foi recomendado que seu tipo fosse alterado para ConcurrentHashMap. Como vimos na primeira etapa, nos dois ambientes a implementação ConcurrentHashMap demonstrou de fato consumir menos energia, sendo um dos fatores para que fosse recomendado o uso dessa estrutura de dados. Esse constatação

4.2. RESULTADOS DOS EXPERIMENTOS 48 é importante e corrobora com outros estudos, por exemplo, Dig, Marrero and Ernst (2009), que recomendam utilizar ConcurrentHashMap como substituto de Hashtable. Além disso, Pinto et al. (2016) demonstraram que a implementação de ConcurrentHashMap no Java 8 reduz ainda mais o consumo de energia quando comparada com Hashtable, o que ratifica a utilização da versão mais atualizada dessa estrutura de dados.