Antes de descrever a organiza¸c˜ao do texto, uma pequena nota ao leitor. Esta Tese, em concordˆancia com as normas atuais que regem a p´os-gradua¸c˜ao da Universidade Estadual de Campinas, possui partes do texto escritas em l´ıngua estrangeira, cor- respondentes a artigos publicados ou submetidos a jornais cient´ıficos e conferˆencias internacionais. Ainda de acordo com esta norma, o conte´udo desses textos repro- duz fielmente aqueles dos artigos originais. Contudo, a formata¸c˜ao dos mesmos foi adequada para ficar compat´ıvel com o estilo do restante desse documento.
O Cap´ıtulo 2 lista trabalhos anteriores relacionados `a esta Tese. Nele s˜ao detalhadas t´ecnicas anteriores de TLS.
O Cap´ıtulo 3 inicia a coletˆanea com o primeiro artigo publicado durante a pesquisa deste trabalho. Nele, descreve-se uma nova t´ecnica ara identifica¸c˜ao de traces. Durante os estudos sobre identifica¸c˜ao de traces, desenvolvemos uma nova forma para representa¸c˜ao dos mesmos, que ´e descrita no Cap´ıtulo 4.
O Cap´ıtulo 5 apresenta uma extens˜ao de DSWP para utiliza¸c˜ao em n´ıvel de c´odigo- fonte em Java. Nos experimentos realizados, nenhum suporte extra foi adicionado `a JVM. O trabalho de paraleliza¸c˜ao, embora tenha sido feito manualmente, foi de extrema importˆancia para o resultado final desta Tese por ter exposto os problemas intr´ınsecos `a DSWP, em especial os problemas de alias de mem´oria. As solu¸c˜oes para os problemas encontrados neste estudo foram ´uteis para a arquitetura descrita no Cap´ıtulo 6.
O Cap´ıtulo 6 apresenta a principal contribui¸c˜ao desta tese: uma arquitetura paralela com suporte `a execu¸c˜ao de c´odigo paralelizado utilizando estrat´egias baseadas no modelo DOPIPE [42] de paraleliza¸c˜ao como DSWP.
As conclus˜oes da Tese s˜ao apresentadas no Cap´ıtulo 7, que tamb´em lista trabalhos futuros poss´ıveis.
O Apˆendice A apresenta uma prova de corretude para o mecanismo de coerˆencia utilizado pela arquitetura proposta pelo Cap´ıtulo 6. Esta prova utiliza protocolo
Trabalhos Relacionados
Neste Cap´ıtulo, ´e feita uma revis˜ao dos trabalhos anteriores em Traces (Se¸c˜ao 2.1) e em paraleliza¸c˜ao n˜ao-tradicional de la¸cos usando TLS (Se¸c˜ao 2.2). As t´ecnicas de pa- raleliza¸c˜ao tradicionais, utilizadas para paraleliza¸c˜ao de la¸cos regulares, s˜ao descritas na Se¸c˜ao 5.2.
2.1
Traces
Ao contr´ario de TLS, a literatura a respeito de traces n˜ao ´e t˜ao extensa e, os trabalhos, n˜ao t˜ao diversificados. Ainda assim, como uma importante parte deste trabalho, esta Se¸c˜ao dedica-se a listar alguns trabalhos relacionados detec¸c˜ao e usos de traces.
Cifuentes et al. [10] prop˜oem Most Frequently Executed Tail (MFET). Nesta t´ecnica, as arestas do GFC do programa s˜ao instrumentadas. MFET tamb´em instrumenta as instru¸c˜oes alvos de salto para tr´as. Quando uma instru¸c˜ao ´e identificada como “quente”, MFET utiliza a informa¸c˜ao sobre a frequˆencia de execu¸c˜ao das arestas para determinar o trace que deve ser formado.
Duesterwald et al. [16] prop˜oem MRET. Assim como MFET, os in´ıcios de traces s˜ao identificados em instru¸c˜oes que s˜ao alvo de saltos para tr´as. Entretanto, MRET segue o fluxo da execu¸c˜ao do programa para determinar o trace a ser gravado. A id´eia ´e evitar a custosa instrumenta¸c˜ao em todas as arestas do GFC do programa original.
Last Executed Iteration (LEI) [26], proposto por Hiniker et al., procura identificar
c´odigo quente mais significativo que MRET. Basicamente, a t´ecnica utiliza um buffer com os ´ultimos saltos executados pelo programa. Uma entrada repetida neste buffer indica a detec¸c˜ao de um loop header. Quando este loop header executar mais que um n´umero determinado de vezes, LEI grava a execu¸c˜ao do programa at´e que um ciclo seja formado, ou at´e que a execu¸c˜ao do programa atinja um trace pr´e-existente.
Como MRET n˜ao ´e seletivo em rela¸c˜ao ao caminho escolhido para gerar um trace,
Two-pass MRET (MRET2
)2
foi desenvolvida. Como o nome indica, ela ´e derivada de MRET. Seu funcionamento ´e bem simples: ao inv´es de gravar um trace assim que seu c´odigo se torna quente, MRET2
grava um trace potencial, e programa continua a executar c´odigo normal. Quando um segundo trace for identificado, MRET2
faz a intersec¸c˜ao de ambos os traces potenciais. Esta heur´ıstica tende a identificar caminhos mais significativos para execu¸c˜ao do programa.
H´a uma ampla literatura de ambientes de otimiza¸c˜ao de c´odigo baseados em traces. Por exemplo, Baraz et al. [6] introduz IA32-EL, um tradutor bin´ario dinˆamico que traduz c´odigo x86 para execu¸c˜ao em sistemas Itanium ®. Este tradutor otimizante mostrou
um desempenho superior `a solu¸c˜ao inicialmente empregada (i.e., uso de um n´ucleo de um processador 386 para execu¸c˜ao nativa de c´odigo x86). Este ganho de desempenho somente foi poss´ıvel pois IA32-EL identificava traces de execu¸c˜ao, armazenando-os em uma trace
cache para posterior otimiza¸c˜ao.
Dehnert et al. [15] descreve Code Morphing Software (CMS), a grande novidade da Transmeta em seus processadores: ao inv´es de manter a compatibilidade com x86 em
hardware, uma camada de software (a CMS) foi utilizada. Desta forma, os engenheiros
do processador se viram livres das idiossincrasias de x86. CMS tamb´em mant´em os traces descobertos em uma trace cache, focando maior esfor¸co de otimiza¸c˜ao nos traces mais executados.
Digital FX!32, proposto por Hookway [27], ´e um subsistema presente nos sistemas operacionais Windows NT 4.0 em sistemas Alpha para execu¸c˜ao de aplica¸c˜oes x86 sem a necessidade de recompila¸c˜ao para a nova arquitetura. Diferentemente dos trabalhos ante- riores, FX!32 inicialmente interpretava as aplica¸c˜oes, instrumentando o c´odigo executado. A otimiza¸c˜ao dos c´odigos mais executados era feita offline. As unidades de otimiza¸c˜ao eram traces de execu¸c˜ao.
Gal et al. [17] prop˜oem TraceMonkey, um compilador dinˆamico para JavaScript que emprega TT para identificar c´odigo quente em aplica¸c˜oes Web. Compilar JavaScript para execu¸c˜ao nativa ´e extremamente interessante, haja vista a quantidade de c´odigo JavaScript dispon´ıvel que pode beneficiar-se direta e automaticamente da compila¸c˜ao.
Em comum, todos estes trabalhos n˜ao identificam oportunidades de paraleliza¸c˜ao de c´odigo em n´ıvel de threads, optimizando, contudo, o c´odigo com otimiza¸c˜oes tradicionais, tais quais Elimina¸c˜ao de Subexpress˜oes Comuns (ESC) e Elimina¸c˜ao de C´odigo Morto (ECM) [1, 39].