[Magill 03] resume

233 views

Published on

Implementando Escape Analysis no Jikes RVM

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
233
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

[Magill 03] resume

  1. 1. set-2011 1 Implementing Escape Analysis in the Jikes RVM Stephen Magill Daniel Spoonhower April 28, 2003 Resumo realizado por Marcio Machado Pereira – RA 780681 estado da variável ou objeto representado pelo nó. Arestas representam tanto as referências criadas por atribuições ou I. INTRODUÇÃO referências de um objeto para os seus campos. Nos nós deN intersecção do programa, simplesmente faz-se a união dos o artigo [1], os autores citam a contribuição de Choi et grafos a partir dos nós predecessores. al. que, num esforço em limitar o número de objetosalocados dinamicamente e reduzir o overhead de Escape analysis possibilita ao compilador realizar dois tipossincronização, introduziram um novo algorítimo para de otimização: ela indica ao compilador oportunidades paradeterminar estaticamente se um dado objeto “escapa” seu alocação de memória mais restritiva e, portanto, de baixométodo ou linha de execução (thread) [2]. Em particular, custo, e oportunidades de remoção de operações deChoi et al. introduziram uma nova representação estática do sincronização desnecessárias. Em Java, objetos e arrays sãoestado do programa chamada de grafo de conexão criados pelo operador new, alocados no heap e gerenciados(connection graph) e uma análise de fluxo de dados (data por algum tipo de gerenciamento automático de memória ouflow analysis – DFA) baseada neste estado. Enquanto Choi et coleta de lixo (garbage collection).al. realizaram suas analises em um compilador estático, HighPerformance Compiler for Java – HPCJ, os autores Através da análise se há ou não referências a um objeto foraimplementaram suas analises como um passo de otimização do método que o alocou ou da sua thread de execução,em tempo de execução (run-time optimization) no Jikes podemos colocar um limite superior conservador ligado àResearch Virtual Machine – Jikes RVM [3]. Os autores vida do objeto. Se o compilador puder determinarperceberam no entanto que há um custo de performance estaticamente que um objeto não sobreviverá ao método que osignificativo neste tipo de análise quando aplicada em tempo alocou, o código pode ser transformado para usar uma dasde execução, porém os resultados indicaram que algumas técnicas descritas a seguir: o armazenamento do objeto podeanalises adicionais podem oferecer oportunidades para uma ser vinculado ao registro de ativação do método.execução mais eficiente em programas de tempo de execuçãolongos.Para endereçar estes problemas, os autores propuseram então III.SCALAR REPLACEMENT AND STACK ALLOCATIONmodificações requeridas neste tipo de analise para serem Os autores usaram esta forma de Scape Analysis para realizarrealizadas no contexto de um sistema de otimização em uma otimização chamada de Scalar Replacement oftempo de execução. Este resumo traz uma visão geral da aggregates. Ao invés de alocar objetos e pequenos arrays noanalise usada pelos autores. heap, eles são definidos na pilha ou mesmo em registradores. No Jikes RVM esta otimização é realizada sob a II. ESCAPE ANALYSIS representação intermediária HIR (High-level IntermediatePark e Goldberg introduziram o termo Escape Analysis para Representation). Neste estágio de compilação, pilha edescrever a analise que determina que partes de uma lista não registradores são referenciados uniformemente comoescapa de uma chamada de função. No contexto da linguagem registradores virtuais. Com isto, a otimização pode serde programação Java estamos interessados em determinar se realizada independente de máquina e tirar proveito do passoum objeto ou vetor (array) não escapa o método que o de alocação de registradores. Em contrapartida, há uma sérieinvocou ou sua thread de execução. Para cada alocação ou de restrições sobre estes objetos e arrays considerados paraatribuição no programa, representa-se seu estado corrente replacement. O tamanho dos arrays, bem como todas ascomo um grafo de conexão. Nós são adicionados para operações de indexação, precisam ser determinadosrepresentar a alocação de objetos ou arrays, bem como as estaticamente. Além disso, objetos e arrays não podem serreferências a estas alocações, seus campos e elementos. usados com certas operações que requerem uma referênciaAtribui-se a cada nó os valores GLOBAL_ESCAPE, para os mesmos (e.g., invoke).THREAD_LOCAL ou METHOD_LOCAL para indicar o Choi et al. descrevem uma forma de alocação similar, mas  O trabalho em referência foi apresentado na conferência PACT07 realizadoentre os dias 15 e 19 de setembro de 2007 na cidade de Brasov, Romenia. O distinta, conhecida como Stack Allocation. Ao invés deresumo é parte do trabalho de pesquisa de doutorado do Instituto de Computação atribuir campos individuais ou elementos para registradoresda UNICAMP (IC-Unicamp) e foi elaborado por Pereira, M. M. (e-mail: virtuais, aloca-se o objeto inteiro ou array na pilha, incluindompereira@ic.unicamp.br ). qualquer informação de cabeçalho associada ao objeto ou
  2. 2. set-2011 2array. Stack Allocation é, em muitos casos, menos restritivo exemplo de quando a substituição não é válida é dada naque Scalar Replacement, porém ela não é independente de figura abaixo:plataforma. Como o compilador trabalha neste caso comendereços de memória ao invés de registradores virtuais quepode ou não ser mapeado em memória, Stack Allocationsuporta, por exemplo, operações com indices de arrays nãoconstantes.A fim de identificar corretamente as oportunidades para o usode Scalar Replacement, os autores tiveram que fazer váriasmodificações no algoritmo dado em [2], que é orientado paraStack Allocation:Quando um objeto é alocado na pilha, tem-se ainda umponteiro para um bloco de memória contendo o objeto. ComScalar Replacement, nenhum pointeiro para o objeto estádisponível. O primeiro problema que isto causa é quando umavariável de referência x aponta para objetos diferentes emcaminhos diferentes através do código. Se pelo menos um A idéia deste Scalar Repacement é muito similar ao Copydesses objetos “escapa”, devemos alocar todos os objetos Propagation. De fato, ele é válido exatamente quando Copyreferenciados por x no heap, pois em algum ponto, x conterá Propagation é permitido. A última alteração é a inclusão doum endereço de um objeto real. A solução dada pelos autores valor BOUNDED_BY_METHOD. Este nome reflete o fato depara isso foi o de propagar estas informações para trás e para que os argumentos passados para os procedimentos escapamfrente durante a fase de propagação do algoritmo. O estado do escopo estático do chamador, mas eles podem ser alocadosescape de um nó de referência é definido como o encontro na pilha uma vez que sua vida útil é limitada pelo tempo dedos estados escape dos objetos que ele aponta (backward vida do método chamado.propagation). Esta informação é então propagada para frente IV. CONCLUSÃO(forward propagation) para os objetos. Esta sequencia depropagações backward/forward é repetida até que se convirga No contexto estático, o custo de um passo de otimização épara um ponto fixo. Isto é ilustrado na figura abaixo: muito menos importante do que os resultados. Já em um sistema de otimização em tempo de execução, o custo de cada passo deve ser considerado em relação ao benefício de seu resultado, seja em termos de tempo de execução ou redução dos requisitos de memória. Tem-se afirmado frequentemente que a análise de fluxo de dados é muito cara para uso em tempo de execução. A experiência dos autores fundamenta essa afirmação. Mas, ao mesmo tempo, parece haver benefício significativo para otimizações como a alocação de pilha e eliminação de sincronização. Com base nos resultados obtidos, valeria a pena considerar análises mais rápidas e que permitam que estas otimizações sejam baseadas no formato SSA do programa. V. REFERENCIAS [1] S. Magill, D. Spoonhower. Implementing Escape Analysis in the Jikes RVM. April 28, 2003. [2] Jong-Deok Choi, Manish Gupta, Mauricio J. Serrano, Vugranam C. Sreedhar, and Samuel P. Midkiff. Escape analysis for Java. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), pages 1-19, 1999. [3] B. Alpern, C. R. Attanasio, J. J. Barton, M. G. Burke, P. Cheng, J.-D. Choi, A. Cocchi, S. J. Fink, D. Grove, M. Hind, S. F. Hummel, D. Lieber, V. Litvinov, M. F. Mergen, T. Ngo. J. R. Russell, V. Sarkar, M. J. Serrano, J. C. Shepherd, S. E. Smith, V. C. Sreedhar, H. Srinivasan, and J. Whaley. The Jalapeño virtualO segundo problema ocorre com instruções do tipo a = b, que machine. IBM Systems Journal, 39(1):2111-238, 2000.corresponde a instruções ref_move no Jikes RVM. A únicachance razoável de lidar com isso é quando a e b sãomarcados como método local. Pode-se ir em frentesubstituindo todos os usos de a.x com o escalarcorrespondente b.x no entanto, há que se analisar todos osusos de a para garantir que esta substituição é válida. Um

×