Implementando Escape Analysis no Jikes RVM

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 de
N
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 objetos
alocados dinamicamente e reduzir o overhead de Escape analysis possibilita ao compilador realizar dois tipos
sincronização, introduziram um novo algorítimo para de otimização: ela indica ao compilador oportunidades para
determinar estaticamente se um dado objeto “escapa” seu alocação de memória mais restritiva e, portanto, de baixo
método ou linha de execução (thread) [2]. Em particular, custo, e oportunidades de remoção de operações de
Choi et al. introduziram uma nova representação estática do sincronização desnecessárias. Em Java, objetos e arrays são
estado 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 ou
flow analysis – DFA) baseada neste estado. Enquanto Choi et coleta de lixo (garbage collection).
al. realizaram suas analises em um compilador estático, High
Performance Compiler for Java – HPCJ, os autores Através da análise se há ou não referências a um objeto fora
implementaram 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 determinar
perceberam no entanto que há um custo de performance estaticamente que um objeto não sobreviverá ao método que o
significativo neste tipo de análise quando aplicada em tempo alocou, o código pode ser transformado para usar uma das
de execução, porém os resultados indicaram que algumas técnicas descritas a seguir: o armazenamento do objeto pode
analises 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ção
longos.
Para endereçar estes problemas, os autores propuseram então III.SCALAR REPLACEMENT AND STACK ALLOCATION
modificações requeridas neste tipo de analise para serem
Os autores usaram esta forma de Scape Analysis para realizar
realizadas no contexto de um sistema de otimização em
uma otimização chamada de Scalar Replacement of
tempo de execução. Este resumo traz uma visão geral da
aggregates. Ao invés de alocar objetos e pequenos arrays no
analise 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 Intermediate
Park e Goldberg introduziram o termo Escape Analysis para Representation). Neste estágio de compilação, pilha e
descrever a analise que determina que partes de uma lista não registradores são referenciados uniformemente como
escapa de uma chamada de função. No contexto da linguagem registradores virtuais. Com isto, a otimização pode ser
de programação Java estamos interessados em determinar se realizada independente de máquina e tirar proveito do passo
um objeto ou vetor (array) não escapa o método que o de alocação de registradores. Em contrapartida, há uma série
invocou ou sua thread de execução. Para cada alocação ou de restrições sobre estes objetos e arrays considerados para
atribuição no programa, representa-se seu estado corrente replacement. O tamanho dos arrays, bem como todas as
como um grafo de conexão. Nós são adicionados para operações de indexação, precisam ser determinados
representar a alocação de objetos ou arrays, bem como as estaticamente. Além disso, objetos e arrays não podem ser
referências a estas alocações, seus campos e elementos. usados com certas operações que requerem uma referência
Atribui-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 PACT'07 realizado
entre os dias 15 e 19 de setembro de 2007 na cidade de Brasov, Romenia. O
distinta, conhecida como Stack Allocation. Ao invés de
resumo é parte do trabalho de pesquisa de doutorado do Instituto de Computação atribuir campos individuais ou elementos para registradores
da UNICAMP (IC-Unicamp) e foi elaborado por Pereira, M. M. (e-mail: virtuais, aloca-se o objeto inteiro ou array na pilha, incluindo
mpereira@ic.unicamp.br ). qualquer informação de cabeçalho associada ao objeto ou

2. set-2011 2
array. Stack Allocation é, em muitos casos, menos restritivo exemplo de quando a substituição não é válida é dada na
que Scalar Replacement, porém ela não é independente de figura abaixo:
plataforma. Como o compilador trabalha neste caso com
endereços de memória ao invés de registradores virtuais que
pode ou não ser mapeado em memória, Stack Allocation
suporta, por exemplo, operações com indices de arrays não
constantes.
A fim de identificar corretamente as oportunidades para o uso
de Scalar Replacement, os autores tiveram que fazer várias
modificações no algoritmo dado em [2], que é orientado para
Stack Allocation:
Quando um objeto é alocado na pilha, tem-se ainda um
ponteiro para um bloco de memória contendo o objeto. Com
Scalar Replacement, nenhum pointeiro para o objeto está
disponível. O primeiro problema que isto causa é quando uma
variável de referência x aponta para objetos diferentes em
caminhos diferentes através do código. Se pelo menos um A idéia deste Scalar Repacement é muito similar ao Copy
desses objetos “escapa”, devemos alocar todos os objetos Propagation. De fato, ele é válido exatamente quando Copy
referenciados por x no heap, pois em algum ponto, x conterá Propagation é permitido. A última alteração é a inclusão do
um endereço de um objeto real. A solução dada pelos autores valor BOUNDED_BY_METHOD. Este nome reflete o fato de
para isso foi o de propagar estas informações para trás e para que os argumentos passados para os procedimentos escapam
frente durante a fase de propagação do algoritmo. O estado do escopo estático do chamador, mas eles podem ser alocados
escape de um nó de referência é definido como o encontro na pilha uma vez que sua vida útil é limitada pelo tempo de
dos 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 de
propagaçõ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 virtual
O 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 única
chance razoável de lidar com isso é quando a e b são
marcados como método local. Pode-se ir em frente
substituindo todos os usos de a.x com o escalar
correspondente b.x no entanto, há que se analisar todos os
usos de a para garantir que esta substituição é válida. Um