View
226
Download
5
Category
Preview:
Citation preview
Escape Analysis for Escape Analysis for Java
Jong-Deok Choi, Manish Gupta, Mauricio Serrano, Vugranam C. Sreedhar, Sam Midkiff
IBM T.J. Watson Resarch CenterIBM T.J. Watson Resarch CenterOOPSLA’99 11/99, Denver, CO, USA
MO615 – Marcio Machado Pereira
Escape Analysis for Java [1]
� Objetos são alocados no heap e só podem ser
Em Java:
� Objetos são alocados no heap e só podem serdealocados pelo GC;
� Objetos tem associado a eles um objeto “lock”usado para garantir a exclusão mútua quando ummétodo ou ação de sincronização é invocado.método ou ação de sincronização é invocado.
� Overhead no desempenho.
Escape Analysis for Java [2]
� Determina se um objeto “escapa” ou não o método
Escape analysis no contexto de Java:
� Determina se um objeto “escapa” ou não o métodoque o criou (i.é., o objeto é local ao método ou não)
�Aplicações:�Objeto pode ser alocado na pilha (stack frame) do
método que o criou;método que o criou;
�Alocação na pilha é mais barata do que no heap;
�Reduz overhead do GC.
Escape Analysis for Java [3]
Escape analysis no contexto de Java:
� Determina se um objeto “escapa” a thread que ocriou (i.e., outras threads podem acessar o objeto).
�Aplicações:�Pode-se eliminar os mecanismos de sincronização
associado ao objeto que não escapa a thread;associado ao objeto que não escapa a thread;
�Objeto pode ser alocado na memória do processador
onde a thread foi agendada (scheduled), melhorando a
localidade do dado.
Escape Analysis for Java [4]
� Choi et al. introduziram um novo framework paraEscape analysis baseado em uma abstração doEscape analysis baseado em uma abstração doprograma chamada de Connection Graph (CG).
�Connection Graph captura a relação deconectividade entre os objetos alocados no heap e asreferencias a estes objetos
� A DFA simplesmente realiza uma análise de alcance(reachability analysis) no CG para determinar se umobjeto é local a um método ou local a uma thread.
� CG pode ser sumarizado para cada método deforma que a mesma informação pode ser
Escape Analysis for Java [5]
forma que a mesma informação pode serusada eficientemente em diferentes contextosde chamada (calling contexts).
� Choi et al. apresentaram um algorítmointerprocedural que usa a propriedade deinterprocedural que usa a propriedade desumarização para computar de forma eficienteo CG e identificar objetos que não escapammétodos ou threads.
Escape de um Objeto [1]
� Seja O uma instância de um objeto e M a invocação deum método. O escapa M, denotado por Escapes (O,M),um método. O escapa M, denotado por Escapes (O,M),se o tempo de vida de O exceder o tempo de vida de M.
� Um objeto O é alocavel na pilha (stack-allocatable) deM se ¬Escapes (O,M)
�Seja O uma instância de um objeto e T uma thread�Seja O uma instância de um objeto e T uma thread(instância). O escapa T, denotado por Escapes (O,T), seoutra thread T' ≠ T, puder acessar O.
�Um objeto O é local a uma thread T se ¬Escapes (O,T)
Escape de um Objeto [2]
� Proposição:
Para todo objeto O, onde o método M é invocado nathread T:
¬Escapes (O,M) ⇒⇒⇒⇒ ¬Escapes (O,T)
� Intuitivamente:
⇒⇒⇒⇒
� Intuitivamente:
“Um objeto cujo tempo de vida é limitado pelo tempo devida do método que o invocou, só pode ser acessado poruma única thread”.
Connection Graph [1]
CG = ( No U Nr U Nf U Ng, Er U Ed U Ef )
N – representa o conjunto de objetosNo – representa o conjunto de objetosNr – variáveis de referência (locais e formais)Nf – fields não estáticosNg – fields estáticos (variáveis globais)Er – arestas “point-to”
x → y ∈∈∈∈ Er ⇒⇒⇒⇒ x ∈∈∈∈ Nr U Nf U Ng & y ∈∈∈∈ No
⇒⇒⇒⇒
⇒⇒⇒⇒
Ed – arestas deferred (diferidas)x → y ∈∈∈∈ Ed ⇒⇒⇒⇒ x, y ∈∈∈∈ Nr U Nf U Ng
Ef – arestas field
x → y ∈∈∈∈ Ef ⇒⇒⇒⇒ x ∈∈∈∈ No & y ∈∈∈∈ Nf U Ng
Connection Graph [2]
Representa uma aresta “point-to” do nó x para o nó yRepresenta uma aresta “point-to” do nó x para o nó y
Representa uma aresta deferred (diferida) do nó x para o nó y
Representa uma aresta field do nó x para o nó y
Idéia Básica do Escape Analysis
Escapement Lattice: NoEscape < ArgEscape < GlobalEscape
�ArgEscape – objeto escapa o método via argumentos, mas não escapa a thread
�GlobalEscape – objeto escapa globalmente (i.e., todas as threads e métodos)
Seja CG o grafo de conexão do método M e seja O um nó objeto emCG. Se O pode ser alcançado em CG por algum nó cujo estado édiferente de NoEscape, então O escapa M.
�GlobalEscape – objeto escapa globalmente (i.e., todas as threads e métodos)
Após DFA todos os objetos marcados como NoEscape sãoApós DFA todos os objetos marcados como NoEscape sãoalocáveis na pilha (stack-allocatable) e todos os objetos marcadoscomo NoEscape ou ArgEscape são locais à thread e, portanto, asoperações de sincronização podem ser eliminadas sem violar asemântica do programa.
Análise Intraprocedural [1]
DFA forward, disjuntiva:
Se C1 = (N1, E1) e C2 = (N2, E2) então C1 Λ C2 = (N1 U N2, E1 U E2)
Para cada nó n ∈ N, associa-se um estado de Escape:
fs é a função de transferência e Meet ( Λ ) = U, i.e.
Ng – inicializado como GlobalEscapeNo U Nr U Nf – inicializado como NoEscape
Associa-se a cada field f de um objeto um identificador único fid(f) quecorresponde ao offset de f na classe que define o objeto. Isto posto, se O1 e O2,são 2 objetos da mesma classe C, então fid(O1.f) = fid (O2.f)
Análise Intraprocedural [2]
Dado um nó de referencia m ∈ Nr U Nf U Ng, o conjunto de nós objetos
O ⊆ ΝΝΝΝοοοο que m “aponta para” (point-to) é determinado percorrendo asοοοο que aponta para” ( ) é determinado percorrendo as
arestas diferidas a partir de m até visitarmos a primeira aresta point-to no
caminho. Formalmente:
onde é uma sequência de arestas onde é uma sequência de arestas
que termina em exatamente uma aresta “point-to”
Análise Intraprocedural [3]
A função ByPass (p) quando aplicada ao nó p ∈ Nr U Nf redireciona as arestas
diferidas incidentes em p aos nós sucessores de p
ByPass
Formalmente, sejam:
ByPass (p) remove as arestas do conjunto:
e adiciona as arestas no conjunto:
Análise Intraprocedural [4]
Transfer functions (4 ações afetam o Escape Analysis):
p = new r ();
�Cria o nó objeto O (se não existir)
�(Flow-Sensitive) → aplica ByPass (p)
�(Flow-Sensitive/Insensitive) → adiciona aresta “point-to” de p para O
p = q;p = q;
�(Flow-Sensitive) → aplica ByPass (p)
�(Flow-Sensitive/Insensitive) → adiciona aresta
Análise Intraprocedural [5]
p.f = q;
� Faça U = PointsTo (p)
� Se U = Ø então ou p = null (null pointer exception) ou o objeto para o qual
p aponta foi criado fora do método (p é um parâmetro formal ou alcançável por
um parâmetro formal). Conservativamente, cria-se um objeto fantasma Oph
(phantom object node) e insere-se a aresta p Oph
� Faça V = { v| u v, u,v ∈∈∈∈ U & fid(v) = f }� Faça V = { v| u v, u,v ∈∈∈∈ U & fid(v) = f }
� Se V = Ø cria-se um nó field e adiciona-se a V
� Finalmente, adiciona-se arestas {v q | v ∈∈∈∈ V}
Análise Intraprocedural [6]
p = q.f;
� Faça U = { u | q u },
V = { v | u v, u ∈∈∈∈ U & fid (v) = fid (f) }
� Se U = Ø então cria-se um phantom object e adiciona-se a U.
V = Ø então cria-se um field reference e adiciona-se a V
� (Flow-Sensitive) → Aplica-se ByPass (p)� (Flow-Sensitive) → Aplica-se ByPass (p)
� (Flow-Sensitive/Insensitive) → Adiciona-se arestas { p v | v ∈∈∈∈ V }
Análise Intraprocedural [7]
Análise Interprocedural [1]
Vamos assumir que um método A chama outro método B. Então,
�Se método B já foi analisado pelo Escape Analysis então, quando for feito aanálise intraprocedural de A este simplesmente usa uma informação sumarizadaanálise intraprocedural de A este simplesmente usa uma informação sumarizadade B.
�Usa-se o Program Call Graph para representar a relação Caller – Callee.
�Uma vez que Java suporta métodos virtuais usa-se a informação de tipo pararefinar o Call Graph.
�4 pontos são relevantes na análise interprocedural:
� Entrada do método B� Saída do método B� Imediatamente antes da invocação do método B� Imediatamente após a invocação do método B
Análise Interprocedural [2]
No exemplo abaixo o método L() constrói uma lista ligada e o método T() constrói umaestrutura em árvore. A figura ao lado mostra a relação Caller-Callee para o programaexemplo:
Análise Interprocedural [3]
Análise Interprocedural [4]
Connection Graph na entrada do método:
�Para cada parâmetro formal fi, existe um parâmetro real ai no Caller, que produzo valor para f .o valor para fi.
�No ponto de entrada do Callee cria-se então uma atribuição da forma fi = ai
�fi é tratado como uma variável local dentro do método, então ela pode ser morta(killed) por outras atribuições a fi. Cria-se então um nó de referência phantom paraai e insere uma aresta diferida de fi para ai .
�Os estados de fi e ai são inicializados como:
EscapeState [ fi ] = NoEscapeEscapeState [ ai ] = ArgEscape
Análise Interprocedural [5]
Connection Graph na saída do método:
�Modela-se a ação return que retorna uma referência a um objeto como umaatribuição a uma variável especial phantom chamada return.atribuição a uma variável especial phantom chamada return.
�Multiplas ações de retorno são resolvidas no CG executando o “merge” dosrespectivos valores return.
�Após completar o Escape Analysis intraprocedural para um método usa-se afunção ByPass para eliminar todas as arestas diferidas no CG, criando nósphantom onde forem necessários. É o caso do nó R para o exemplo:
Análise Interprocedural [6]
Connection Graph na saída do método:
�Ao final, faz-se a análise de alcançe (reachability analysis) no CG para atualizaros estados de Escape dos objetos. Esta análise particiona o grafo em trêsos estados de Escape dos objetos. Esta análise particiona o grafo em trêssubgrafos:
1. Subgrafo induzido Sg do conjunto de nós que são “alcançaveis” a partir de umnó GlobalEscape (inicialmente, static fields e objetos runnable).
2. Subgrafo induzido Sa do conjunto de nós “alcançaveis” a partir de um nóArgEscape (inicialmente, nós de referência phantom que representam osparâmetros reais criados na entrada do método, como a1 e a2 no exemplo.
3. Subgrafo induzido Sn do conjunto de nós que não são alcançaveis pornenhum nó GlobalEscape ou ArgEscape.
� Então:
� Sg U Sa ≅≅≅≅ NonLocalGraph (representa CG sumarizado do método)
� Sn ≅≅≅≅ LocalGraph (todos os objetos são marcados stack-allocatable)
Análise Interprocedural [7]
Análise Interprocedural [8]
Análise Interprocedural [9]
Connection Graph imediatamente antes da invocação do método:
�A passagem de parâmetros é tratada como uma atribuição ao parâmetro real nochamador. A chamada u1.foo (u2, u3, ..., un) é modelada como:
�Cada parâmetro no local da chamada será comparado com o nó de referênciaphantom do método chamado. No exemplo, 2 nós â1 e â2 são criados comoarestas diferidas apontando para o 1º e 2º parâmetros reais da chamada, u e v,respectivamente.
Análise Interprocedural [10]
Connection Graph imediatamente após a invocação do método:
�Faz-se o mapeamento das informações contidas no CG sumarizado do métodochamado de volta para o CG do chamador.chamado de volta para o CG do chamador.
� Três tipos de nós desempenham um papel importante na atualização do CG, âi'sdo caller's CG, ai's do callee's CG e o nó return.
� Relações de mapeamento MapsToObj ( ↦ ) para atualização dos nós:
Análise Interprocedural [11]
Connection Graph imediatamente após a invocação do método:
�A atualização das arestas é feita da seguinte maneira. Sejam p e q objetos doCallee’ CG tal que:Callee’ CG tal que:
Análise Interprocedural [12]
Análise Interprocedural [13]
� Protótipo → IBM High Performance Compiler for Java.
� Target → PowerPC 333Mhz, 128MB
Resultados Experimentais
� no de objetos que puderam ser alocados na pilhaexcedeu 70% dos objetos criados dinamicamenteem 3 de 10 benchmarks (com a mediana em 19%)
� 11% a 92% de todas as operações de lock forameliminadas nos 10 programas (com a mediana emeliminadas nos 10 programas (com a mediana em51%)
� A redução no tempo de execução foi de 2% a 23%(com a mediana em 7%)
Escape Analysis x Points-to Analysis
�Connection Graph (CG) → Escape Analysis�Points-to Graph (PG) →Pointer-induced Alias Analysis
�CG e PG são abstrações de estruturas de dadosdinâmica com ponteiros ou referencias.
�Alias Analysis → desambiguação de memória� PG mesmo nó se duas referencias apontam para omesmo objetomesmo objeto
�Escape Analysis → identificar objetos que escapam oescopo (dinâmico) do método ou da thread que o invocou.
� CG permite diferentes nós referenciando o mesmoobjeto (pode ignorar o contexto de chamada).
Histórico e Trabalhos relacionados� Analises do tempo de vida de objetos alocados dinâmicamente tem sidotradicionalmente usadas para gerenciar o espaço de armazenamento emtempo de compilação.
� Park & Goldeberg[2] introduziram o termo Escape Analysis em� Park & Goldeberg[2] introduziram o termo Escape Analysis emlinguagens funcionais para determinar estaticamente quais partes de umalista passada para uma função não escapa a chamada da função. Outrosmelhoraram e estenderam o trabalho de Park & Goldeberg.
� Birkedal et al. propuseram um modelo de alocação baseado em regiõesque são gerenciadas durante a compilação.
� Tem havido uma série de esforços paralelos em Escape Analysis paraJava. Bogda & Holzle[3] usam um conjunto de restrições para computarJava. Bogda & Holzle[3] usam um conjunto de restrições para computarobjetos locais às threads.
� Blanchet[4] atribui “pesos” a tipos para codificar como um objeto de umtipo pode ter referências a outros objetos ou é um subtipo de outro objeto.Ele propõe uma analise flow-insensitive em duas fases (backward e forward)para computar as informações de Escape..
[1] Jong-Deok Choi, M. Gupta, M. Serrano, V.C. Sreedhar and S. Midkiff. Escape Analysis for Java. In Proceedings of ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages and Applications, Denver, Colorado, November 1999.
Referências
November 1999.
[2] Y.G. Park and B. Goldberg. Escape analysis on lists. In Proceedings of. ACM SIGPLAN Conference Programming Language Design and Implementation, pages 117-127, July 1992.
[3] Jeff Bodga and Urs Holzle. Removing unnecessary synchronization in java. In Proceedings of ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages and Applications, Denver, Colorado, November 1999.Systems, Languages and Applications, Denver, Colorado, November 1999.
[4] Bruno Blanchet. Escape Analysis for object-oriented languages: Applications to Java. In Proceedings of ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages and Applications, Denver, Colorado, November 1999.
Recommended