jan2012

I. INTRODUÇÃO

o artigo[1], os autores descrevem a implementação de um sistema de otimização dirigida (guiada) por dados

coletados durante a execução (online feedback-directed optimization system – FDO). O mesmo é totalmente automatico, não requerendo que estas informações sejam capturados em uma execução prévia da aplicação (offline profile). Para isto, o sistema usa um framework de baixo impacto (low-overhead) denominado “general instrumentation sampling framework – ISF”[2] que coleta dados como, por exemplo, a frequencia nas arestas de controle do fluxo de execução. Estas informações são usadas para guiar várias otimizações tradicionais, bem como uma transformação conhecida como Splitting, no qual o artigo faz uma contribução apresentando um algoritmo denominado “feedback-directed splitting” mais agressivo que seus predecessores.

N

Os autores argumentam que a realização de “profiling” e otimizações “online” é uma bordagem atrativa pois evita os incovenientes do “profiling” realizado “offline”. No entanto esta abordagem pode ocasionar um overhead no tempo de execução para se coletar as informações de profile, tomar as decisões baseadas nestas informações e realizar as otimizações selecionadas. Para solucionar estes problemas utilizou-se o ISF para obter um profiling eficiente e o sistema de otimização adaptativo AOS (ver seção II) que proveu o contexto para a implementação do FDO.

II. BACKGROUND

A implementação do FDO é uma instância da arquitetura Jikes RVM Adaptive Optimization System – AOS[3]. AOS provê um design de alto nível para a realização de otimizações guiadas por feedback, tanto offline quanto online. No entanto, as otimizações dirigidas por feedback online são mais difíceis do que as otimizações dirigidas por feedback offline. As principais razões são: o aumento (overhead) no tempo de execução e a precisão e disponibilidade das informações de profile. Esta última depende dos dados que estão sendo coletados; quando a coleta é realizada, se durante a execução do código não-otimizado, durante a execução do

O trabalho em referência foi apresentado na conferência OOPSLA’02 realizado na cidade de Seattle, Washington, USA. O resumo é parte do trabalho de pesquisa de doutorado do Instituto de Computação da UNICAMP (IC-Unicamp) e foi elaborado por Pereira, M. M. (e-mail: mpereira@ic.unicamp.br ).

código otimizado ou durante toda a execução; e por quanto tempo os dados são coletados.

Coletar dados durante o estágio inicial pode não ser efetivo ou não produtivo uma vez que o comportamento dominante da aplicação não é exercitado neste estágio. Coletar dados sobre código otimizado pode endereçar o problema descrito acima porém o overhead pode ser proibitivo, principalmente quando instrumentação é inserida no código para se coletar informações de granularidade mais fina. Coletar dados por um período curto (short bursts) pode reduzir o overhead porém o resultado é menos preciso, principalmente se o comportamento do programa varia no tempo.

Alguns tipos de coleta de informações podem ser realizadas sem a necessidade de instrumentação no código. Por exemplo, o Jikes RVM AOS coleta dados para a construção do grafo de chamadas (call graph) amostrando a pilha de chamada (call stack) em intervalos regulares. Infelizmente, muitos tipos de informações de granularidade mais fina como por exemplo, a frequencia de execução de blocos básicos podem ser difícies de coletar usando esta abordagem. Para resolver estas limitações, os autores propuseram um framework denominado “full-duplication instrumentation sampling framework”, descrito a seguir.

III.INSTRUMENTATION SAMPLING

A idéia chave da técnica de full-duplication, mostrada na figura abaixo, é o seguinte:

Online Feedback-Directed Optimization of Java

Matthew Arnold* Michael Hind Barbara G. Ryder*IBM T.J. Watson Research Center *Rutgers University

hind@watson.ibm.com {marnold, ryder}@cs.rugters.edu

Resumo realizado por Marcio Machado Pereira – RA 780681

jan2012

Quando um método é instrumentado, o corpo do método é duplicado e toda instrumentação é inserida no código duplicado. A versão original é minimamente instrumentada nos pontos de amostragem para permitir que o controle seja transferido para o código duplicado. Amostras são tomadas em intervalos regulares através de um mecanismo de amostragem baseada em contador. Este mecanismo mostrou ser de baixo overhead e de alta acuracia para muitos exemplos de instrumentação. A principal desvantagem desta técnica é que o método inteiro é duplicado aumentando o espaço e o tempo de compilação, portanto, métodos candidatos para instrumentação online precisam ser escolhidos cuidadosamente.

IV.FDO IMPLEMENTATION

AOS provê um ambiente de execução para implementação do FDO na qual um mecanismo leve identifica os métodos quentes e os promove para níveis mais altos de otimização. A implementação do FDO adiciona neste métodos informações para se coletar dados de granularidade mais fina com os objetivos de melhorar o desempenho de aplicações de longa duração; manter o desempenho na inicialização e melhorar o desempenho o mais cedo possível. Para isto, os autores empregaram uma estratégia de dois passos. Primeiro, o sistema utiliza os mecanismos de amostragem existentes no AOS para se encontrar os métodos quentes. Segundo, para estes métodos, o sistema aplica um mecanismo de instrumentação para coletar dados mais detalhados. Esta abordagem é consistente com o projeto geral do AOS e pode ainda ser generalizado para incluir uma hierarquia de mecanismos de profile para prover mais informações, com um overhead adicional, porém aplicados em porções menores da aplicação.

Os passos desta abordagem estão descritas abaixo:

1. A execução inicia sem instrumentação e o sistema AOS recompila os métodos baseado nas amostras coletadas (timer-based samples), possívelmente utilizando múltiplos níveis de otimização.

2. Após o método ser otimizado “estaticamente” (em tempo de execução, porém sem FDO) este continua a ser monitorado usando o mesmo mecanismo de amostragem baseado em intervalos regulares. Se o mesmo sem mantém suficientemente quente ele então é instrumentado para se coletar informações de granularidade mais fina usando a técnica descrita acima.

3. Após se coletar informações suficientes, o método é recompilado e as otimizações guiadas por este feedback são aplicadas.

4. Conforme o tempo passa, o comportamento do programa pode mudar. Para garantir que o seu desempenho não degrade com o passar do tempo, dados de profile podem ser reavaliados periodicamente.

V. FEEDBACK-DIRECTED OPTIMIZATIONS

Muitas otimizações podem se beneficiar deste mecanismo. Para validar o sistema, os autores implementaram 4

otimizações a saber: Splitting, Code motion, method inlining e loop unrolling.

Feedback-Directed Splitting Splitting é uma transformação que expõe novas oportunidades de otimização tornando otimizações existentes mais efetivas, principalmente àquelas que dependem de informações do fluxo de dados à frente, como por exemplo, load elimination, array bounds elimination, devirtualization, etc. O algoritmo utilizado resultou em duas vantagens em relação às abordagens anteriores: Primeiro, os esforços são focados no “caminhos quentes” permitindo um Splitting mais agressivo do que os possíveis baseados em heurísticas estáticas. Segundo, o algoritmo é simples de implementar, não impactando nas outras analises.

Feedback-Directed Method Inlining Usar dados de profile para melhorar as decisões de expandir métodos “em linha” pode ter um impacto significativo no desempenho de linguagens orientadas a objetos. A frequencia de execução de blocos básicos provê informações de profile de granularidade mais fina e são usadas para melhorar as decisões de Inlining.

Feedback-Directed Code Positioning Code Positioning rearranja a ordem de blocos básicos com o objetivo de aumentar a localidade e reduzir o número de desvios incondicionais. FDO usa a frequencia de execução de blocos básicos para conduzir o algoritmo de posicionamento descrito por Pettis e Hansen[4].

Feedback-Directed Loop Unrolling Loop unrolling é uma transformação na qual o corpo do laço é duplicado diversas vezes permitindo melhores otimizações dentro do laço. A implementação FDO usa a frequencia de execução dos blocos básicos para desenrolar mais o laço e aumentar o desempenho, porém laços que não são executados frequentemente são desenrolados menos, preservando tempo de compilação e espaço.

VI. REFERENCIAS

[1] Arnold, M. Hind, M., and Ryder B. G. 2002. Online feedback-directed optimization of Java. ACM SIGPLAN Notices 37, 11 (Nov.), 111-129. Proceedings of the 2002 ACM SIGPLAN Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA'02)

[2] Matthew Arnold and Barbara Ryder. A framework for reducing the cost of instrumented code. In SIGPLAN 2001 Conference on Programming Language Design and Implementation, pages 168—179, June 2001

[3] Matthew Arnold , Stephen Fink , David Grove , Michael Hind , Peter F. Sweeney, Adaptive optimization in the Jalapeño JVM, Proceedings of the 15th ACM SIGPLAN Conference on Object-oriented programming, systems, languages, and applications, p.47-65, October 2000, Minneapolis, Minnesota, United States.

[4] Karl Pettis and Robert C. Hansen. Profile guided code positioning. In SIGPLAN '90 Conference on Programming Language Design and Implementation, June 1990.