Revista Tecnolgica Maring, v. 21. p.

103-118, 2012
A MQUINA VIRTUAL JAVA E A OTIMIZAO INLINE: UM ESTUDO DE CASO
THE JAVA VIRTUAL MACHINE AND THE INLINE OPTIMIZATION: A CASE STUDY

Francis Rangel
1

Anderson Faustino da Silva
2









































1
B. Sc. Universidade Estadual de Maring,
Departamento de Informtica. Email:
francis.rangel@gmail.com
2
D. Sc. Universidade Estadual de Maring,
Departamento de Informtica. Email:
anderson@din.uem.br
Resumo. Embora seja conhecido que a otimizao
inline produza benefcios considerveis um desafio
desenvolver uma boa heurstica de sua aplicao, de
forma que o ganho de desempenho seja efetivo para
diversas classes de programas. O objetivo deste
trabalho realizar uma anlise do impacto de inline,
na execuo de programas Java e demonstrar que a
estratgia utilizada durante a aplicao de inline nem
sempre alcana o objetivo proposto.

Palavras Chave: Mquina Virtual Java. Otimizao.
Inline.
























Abstract. Although it is well-known that the inline
optimization produces goods results it remains a
challenge to develop a good heuristic of its
application, so that the performance profit is
effective for many applications. The goal of this
paper is to present an experimental analysis about
the impact of inline on Java programs, and
demonstrate that the inline strategy not always
reaches the considered goal.

Keywords: Java Virtual Machine. Optimization.
Inline.
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
1. INTRODUO

Diversas linguagens de programao
interpretadas (DEITEL e DEITEL, 2010; LUTZ,
2007) utilizam uma mquina virtual (CRAIG,
2006) para executar seus programas. O
objetivo na utilizao de mquinas virtuais e
linguagens interpretadas obter a mxima
independncia possvel de plataforma.
Portabilidade possibilita ao desenvolvedor
projetar um determinado programa que ser
executado em diferentes plataformas de
hardware, sem a necessidade de refaz-lo
para cada uma destas. Esta a maior
vantagem das linguagens interpretadas.
A grande desvantagem de se utilizar
programas em ambientes interpretados que
estes so mais lentos, quando comparados
com programas desenvolvidos em ambientes
compilados. Isto devido ao fato de cada
instruo do cdigo intermedirio ser lida,
decodificada, traduzida para cdigo de
mquina e depois executada. Este processo
ocasiona um atraso na execuo do
programa. J em ambientes compilados o
cdigo gerado o cdigo de mquina, sendo
necessrio apenas execut-lo.
Para melhorar o desempenho de
linguagens interpretadas (SEBESTA, 2011),
diversos ambientes de execuo utilizam um
mecanismo de compilao dinmica,
denominado Just-in-Time Compilation (JIT)
(SCOTT, 2008). Este mecanismo responsvel
por gerar cdigo nativo otimizado durante a
execuo do programa, no sendo mais
necessrio interpretar novamente algumas
pores do cdigo do programa. Atualmente,
a maioria das implementaes da Mquina
Virtual Java (JVM Java Virtual Machine)
(MEYER e DOWNING, 1997) possuem um
compilador JIT em sua arquitetura
(MICROSYSTEMS, 2010; CIERNIAK et al., 2000;
BURKE et al., 1999).
Um ambiente de compilao dinmica
alm de gerar cdigo nativo, aplica diversas
otimizaes como o objetivo de melhorar a
qualidade do cdigo gerado. No contexto de
linguagens orientadas a objetos uma
otimizao que possui um alto potencial
inline (MUCHNICK, 1997). Isto devido ao fato
de programas orientados a objetos possurem
uma grande quantidade de invocaes de
mtodos. Embora seja conhecido que esta
otimizao seja efetiva, os trabalhos que
desenvolvem ambientes de compilao dinmica
para Java (BURKE et al, 1999; CIERNIAK et al, 2000,
GU et al, 2000; MICROSYSTEMS, 2010; SUGANUMA
et al, 2000) no demonstram o quo esta otimizao
efetiva, nem os custos decorrentes de sua m
utilizao.
O objetivo deste artigo avaliar o impacto
efetivo da otimizao inline em programas Java
executados pela JVM da Sun Microsystems Inc.
(MICROSYSTEMS, 2010), visando entender o
funcionamento desta otimizao, bem como os
motivos que a levam a degradar o desempenho do
sistema para alguns programas. Uma anlise deste
porte fundamental para possveis alteraes na
estratgia de aplicao desta otimizao,
consequentemente, melhorar o desempenho de
sistemas que a utilizam.
O restante deste artigo est organizado da
seguinte forma. A Seo 2 descreve a arquitetura da
JVM da Sun. A Seo 3 descreve a otimizao inline e
seu funcionamento na JVM da Sun. A Seo 4
apresenta uma avaliao experimental realizada
para avaliar o impacto da otimizao inline em
programas Java. E, finalmente, a Seo 5 conclui
este artigo.

2. A MQUINA VIRTUAL JAVA DA SUN

A Mquina Virtual Java um computador
abstrato (LINDHOLM, 1999), capaz de carregar
classes e executar os bytecodes, que so instrues
codificadas no formato da Mquina Virtual Java,
nelas contidos. Ela composta por trs elementos:

1. Um carregador de classe, que carrega as
classes da API Java e as do programa a ser
executado;
2. Uma heap, a regio de dados que armazena
as classes; e
3. Um motor de execuo responsvel por
interpretar os bytecodes que implementam os
mtodos das classes.

A Figura 1 apresenta os componentes da JVM. A
heap uma rea de dados na qual todas as instncias
de classes e arrays so armazenados. A heap criada
durante a iniciao da JVM. O armazenamento de
dados na heap gerenciado por um coletor de lixo,
pois objetos Java no so desalocados
explicitamente (VERNNERS, 1999). A heap pode ter
um tamanho fixo, ou pode expandir caso o
programa crie vrios objetos e contrair quando
objetos no so mais referenciados.

104
Rangel e Silvaiiiiii

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012

Figura 1. Arquitetura da Mquina Virtual da Sun

O motor de execuo suporta a execuo
de instrues da mquina virtual em dois
modos de execuo: um modo interpretado e
um modo misto de execuo. No modo
interpretado, o motor de execuo simples
apenas interpreta os bytecodes, um por um.
Por outro lado, no modo misto, a mquina
virtual inicia interpretando bytecodes, porm
o programa em execuo monitorado para
deteco das reas de cdigo executadas
com frequncia, os chamados hot-spots.
Assim, durante a execuo do programa, a
mquina virtual Java gera cdigo nativo para
os hot-spots e continua interpretando os
outros bytecodes.
Uma mquina virtual Java possui dois tipos
de mtodos: mtodos Java e mtodos
nativos. Um mtodo Java escrito em
linguagem Java (DEITEL e DEITEL, 2010),
compilado para bytecodes e armazenado em
arquivos de classes. Um mtodo nativo
escrito em outra linguagem, tal como C
(DAMAS, 2007), e compilado para cdigo de
mquina nativo de um particular processador.
Mtodos nativos so armazenados em
bibliotecas dinmicas. Quando um programa
Java invoca um mtodo nativo, a mquina
virtual carrega a biblioteca dinmica que
contm a implementao do mtodo e o
invoca.

2.1. O CARREGADOR DE CLASSES

A JVM possui uma arquitetura flexvel para
carregadores de classes, permitindo a um
programa Java carregar dinamicamente
classes tanto do disco local, como da Internet.
O carregador de classes (LIANG, 1998)
responsvel no apenas por localizar e
importar os dados binrios das classes. Ele
tambm tem as funes de verificar os dados
importados, alocar e inicializar memria para
as variveis das classes e resolver as referncias
simblicas. Estas atividades so realizadas na
seguinte ordem:
1. Carregar: encontrar e importar os dados
binrios para uma classe.
2. Ligar: executar a verificao, a preparao, e
opcionalmente a definio.
(a) Verificar: assegurar a exatido da classe
importada.
(b) Preparar: alocar memria para variveis da
classe e iniciar a memria alocada com o valor
padro zero (0).
(c) Definir: transformar referncias simblicas em
referncias diretas.
3. Iniciar: invocar o cdigo Java que inicia as
variveis da classe com seus valores apropriados.
Um programa Java pode fazer uso de diferentes
carregadores de classes. Existe um carregador
padro, que um componente da implementao da
mquina Java, e podem existir carregadores
definidos pelo usurio, capaz de carregar classes por
meios no convencionais.
Enquanto o carregador padro parte da
implementao da JVM, o carregador definido pelo
usurio uma classe Java, inicialmente carregada
pela JVM e instanciado como qualquer outro objeto.
Para cada classe carregada, a mquina virtual
mantm um histrico contendo qual carregador
carregou a classe. Quando uma classe faz referncia
a uma classe no carregada, a mquina virtual Java
utiliza para a carga da classe referenciada o
carregador da classe que contm a referncia. O uso
deste mecanismo pressupe que uma classe apenas
referencie classes carregadas pelo mesmo
carregador.

2.2. A HEAP

Em uma instncia da JVM, informaes sobre os
tipos carregados so armazenadas em uma rea
lgica da memria denominada rea de mtodos
(VERNNERS, 1999). A rea de mtodos
105
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
compartilhada por todos os threads do
programa. Porm, quando dois threads
tentam encontrar uma classe que ainda no
foi carregada, apenas uma carrega a classe,
enquanto a outra fica bloqueada em espera.
Quando um programa Java em execuo
cria uma nova instncia de uma classe, a
memria para este novo objeto alocada em
uma heap. A mquina Java possui apenas uma
heap, que compartilhada por todos os
threads do programa. Note que threads
podem, portanto acessar objetos
pertencentes a outra thread. Java fornece
primitivas de sincronizao, tais como wait,
notify e notifyall para que o programador
possa evitar condies de corrida.
A JVM possui uma instruo que aloca
memria na heap para um novo objeto,
porm no possui uma instruo para liberar
memria. A liberao das reas de memria
ocupadas por objetos que no so
referenciados pelo programa de
responsabilidade do coletor de lixo (APPEL,
1998) da JVM. O coletor de lixo um
componente fundamental da JVM
responsvel por gerenciar a heap e a rea de
mtodos. O coletor de lixo, alm de liberar as
reas utilizadas pelos objetos e classes que
no esto sendo referenciados, possui a
capacidade de realocar classes e suas
instncias para reduzir a fragmentao da
rea de mtodos e/ou da heap.
Em geral, o tamanho das reas de
mtodos e da heap no so fixos. Durante a
execuo de um programa Java, estas podem
ser expandidas ou contradas pela JVM.

2.3. O MOTOR DE EXECUO

O ncleo da JVM seu motor de execuo
(VERNNERS, 1999), cujo comportamento
definido por um conjunto de instrues.
Cada thread do programa uma instncia
do motor de execuo. Durante o perodo de
vida do thread, ela est executando bytecodes
ou mtodos nativos. O thread pode executar
bytecodes diretamente, interpretando, ou
indiretamente, executando o cdigo nativo
resultante da compilao.
A JVM pode usar threads que no so
visveis ao programa, por exemplo, o thread
que executa o coletor de lixo. Tais threads no
precisam ser instncias do motor de
execuo. Entretanto, os threads que
pertencem ao programa so motores de execuo
em ao.
O motor de execuo funciona executando
bytecodes de uma instruo por vez. Este processo
ocorre para cada thread do programa. Uma
seqncia de bytecodes uma sequncia de
instrues. Cada instruo consiste de um cdigo de
operao seguido por zero ou mais operandos. O
cdigo de operao indica a operao a ser
executada. Os operandos fornecem os dados
necessrios para executar a operao especificada.
No prprio cdigo de operao implcita a
existncia ou no de operandos e dos mecanismos
para acess-los.
O motor de execuo busca um cdigo de
operao e se esse cdigo possuir operandos busca
os operandos, aps executa a ao solicitada pelo
cdigo e em seguida busca outro cdigo. A execuo
dos bytecodes continua at que um thread termine
retornando de seu mtodo inicial.
Cada tipo de cdigo do conjunto de instrues da
Mquina Virtual Java possui um mnemnio, no estilo
tpico de linguagem Assembly (STREIB, 2011).

2.4. O COMPILADOR JIT

O compilador JIT (MICROSYSTEMS, 2010) traduz
cdigo fonte em cdigo de mquina a medida que
este cdigo executado. Consequentemente, o
tempo de compilao passa a estar inserido no
tempo total de execuo da aplicao. Desta forma,
o compilador JIT da JVM da Sun apenas traduz as
unidades cujo tempo gasto em traduo seja
amortizado pelo ganho de desempenho em cdigo
nativo. Alm disto, este compilador utiliza tcnicas
de otimizao de cdigo para obter cdigo de alta
qualidade.
A JVM da Sun utiliza a abordagem de interpretar
primeiro e depois compilar, baseada na observao
de que a maioria dos programas gasta a maior parte
do seu tempo em uma pequena faixa de cdigo. Esta
abordagem compila apenas as partes do cdigo
executadas frequentemente. Para tal, as unidades
de cdigo so instrumentadas com contadores.
Cada unidade possui dois contadores: um
contador de entrada e um contador de retorno. O
primeiro incrementado no incio da execuo de
cada unidade. O outro incrementado quando um
salto de retorno unidade executado. Se estes
contadores excedem um limite pr-definido a
unidade escalonada para compilao.
Por outro lado, os contadores das unidades que
no so executados frequentemente, por exemplo,
apenas uma vez no incio do programa, nunca
106
Rangel e Silvaiiiiii
Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
atingiro o limite determinado e
consequentemente nunca sero compilados.
Isto reduz drasticamente o nmero de
unidades que so compiladas. Desta maneira,
o compilador gera menos cdigo e pode
gastar mais tempo otimizando o cdigo das
unidades mais importantes. esperado que
os contadores de frequncia, de todas as
unidades executadas, alcancem o limite
determinado e que estas unidades sejam
compiladas sem gastar demasiado tempo
com sua interpretao.
A implementao da JVM da Sun possui
dois compiladores, os quais so denominados
Cliente e Servidor. O compilador Cliente
mais simples e aplica o mnimo de otimizaes
possveis no cdigo, pois tem o objetivo de
reduzir as pausas do sistema. Por outro lado,
o compilador Servidor mais agressivo e
utiliza diversas otimizaes para tentar
melhorar o desempenho do cdigo
compilado. Porm, esta agressividade do
compilador Servidor pode ser prejudicial.
Dependendo das caractersticas do programa
em execuo pode ocorrer um crescimento
prejudicial do cdigo e/ou aumento na
presso por registradores, entre outros
problemas.
A estrutura do compilador Cliente
formada por um frontend, independente de
mquina, e por um backend, parcialmente
dependente de mquina. O frontend constri
uma representao intermediria de alto nvel
(em ingls, HIR). Apenas otimizaes simples
so utilizadas neste momento, como
propagao de constantes. Aps isto, os laos
mais internos so detectados para facilitar a
alocao de registradores, realizados pelo
backend.
O backend converte o HIR para uma
representao intermediria de baixo nvel.
Registradores so alocados quando
necessrio e liberados quando o seu valor
armazenado em uma varivel local.
Registradores no utilizados armazenam o
valor da varivel local mais utilizada. Para
identificar estes registradores, o gerador de
cdigo utiliza duas passagens. Primeiramente,
a gerao de cdigo desabilitada e a
alocao de registradores monitorada. Em
seguida, a gerao de cdigo acionada e o
gerador executa a segunda passagem.
O compilador Servidor utiliza um grafo
para a representao intermediria. Os
seguintes passos so realizados durante a
compilao: traduo de bytecodes, otimizaes
independentes de mquina, seleo de instrues,
escalonamento global de cdigo, alocao de
registradores, otimizao peephole e, por ltimo,
gerao de cdigo.
Duas passagens pelos bytecodes so necessrias
para a compilao do mtodo. Durante ambas as
passagens otimizaes so utilizadas. A alocao de
registradores realizada utilizando uma estratgia
de colorao de grafo. Aps este processo a
otimizao peephole aplicada e, enfim, o cdigo
gerado.

3. INLINE

Quando um procedimento invocado existe uma
srie de operaes necessrias para que este seja
executado (AHO et al, 2007). De maneira
simplificada, o computador necessita realizar os
seguintes passos: criar um registro de ativao
(APPEL, 1998) em memria, para armazenar os
dados gerenciais do procedimento; ajustar
registradores e armazenar informaes de retorno
para o procedimento corrente; executar o
procedimento; retornar o resultado, se necessrio;
ajustar o ponto de execuo seguinte invocao do
procedimento; e voltar a execuo normal do
procedimento anterior. Todo este processo causa
uma perda considervel de desempenho, quando
realizado inmeras vezes.
Para melhorar o desempenho de programas que
contenham inmeras chamadas a procedimentos foi
desenvolvida a otimizao inline (ARNOLD et al,
2000). O objetivo desta otimizao eliminar a
chamada do procedimento, trocando a chamada por
uma cpia do seu corpo.
Realizar a cpia do corpo do programa no local
de sua chamada significa eliminar as operaes
necessrias durante a gerncia da execuo de um
procedimento. Com isso, o tempo de execuo do
procedimento reduzido. O nico ajuste necessrio
ao se realizar inlining ajustar os argumentos
formais, antes passados como argumentos reais,
agora presentes no corpo do procedimento que
realizaria a chamada. Isto porque os argumentos
deixaram de existir, visto que a chamada do
procedimento no mais existe mais.
No incio, algumas linguagens de programao
no utilizavam inline, mas um recurso semelhante.
Macro (CHIBA, 1998), um recurso disponvel na
linguagem Lisp (BAKER, 1992), realiza um processo
semelhante ao funcionamento de inline. Por outro
lado, outras linguagens comearam a utilizar esta
107
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
otimizao por meio de instrues especiais.
Um exemplo o que ocorreu com a
linguagem Ada (DEPARTAMENT OF DEFENSE,
2006). Nesta linguagem o inline era tratado
como um pragma (LEDGARD, 1983), sendo
necessrio que o programador selecionasse
os procedimentos aos quais ele gostaria que
fosse aplicado inline.
Esta flexibilidade na utilizao da
otimizao nem sempre vantajosa, visto que
inline pode ocasionar alguns problemas se
no for aplicado de maneira correta. Uma
escolha equivocada de procedimento pode
ocasionar um efeito colateral ao proposto
pela otimizao, ocasionando uma perda de
desempenho (DA SILVA e SANTOS COSTA,
2006). Por este motivo, algumas vezes esta
deciso tomada pelo prprio compilador.
Isto ocorre porque o compilador pode coletar
informaes sobre as caractersticas do
progama e us-las no processo de seleo de
procedimentos para aplicao de inline. Estas
informaes podem ser coletadas tanto em
tempo de compilao, denominadas
informaes estticas, quanto em tempo de
execuo, denominadas informaes
dinmicas ou de tempo de execuo, e no
esto disponveis ao desenvolvedor enquanto
este est codificando seu programa.
Com a utilizao destas informaes, um
compilador pode ser mais seletivo no
processo de inlining. Sendo assim, um
conjunto mais restrito de procedimentos
sofre a aplicao da otimizao, garantindo
que este conjunto seleto, com inline aplicado,
melhore a qualidade do cdigo gerado e,
consequentemente, reduza o tempo total de
execuo do programa.
Em linguagens orientadas a objeto
(STROUSTRUP, 1991) a utilizao de inline se
tornou extremamente necessria pela
quantidade de mtodos pequenos que so
criados para realizar o encapsulamento
proposto pelo paradigma. Um exemplo deste
comportamento o acesso a atributos de
classes. Geralmente, um atributo possui, ao
menos, dois mtodos dentro da classe, sendo
um para retornar e outro para alterar seu
valor. Somente este processo implica na
criao de muitos mtodos por classe, os
quais so invocados muitas vezes durante a
execuo do programa, consequentemente,
impactando em alto custo execuo do
programa.
3.1. VANTAGENS DE INLINE

A aplicao de inline ocasiona uma srie de
vantagens durante a compilao de um programa.
As duas principais so: a invocao de mtodos no
ocasiona a criao de registros de ativao, incluindo
os procedimentos de controle dos mesmos; e
aumento do escopo do programa, sendo possvel
aplicar outras otimizaes onde antes no era
possvel.
Em um programa com inmeras classes e
mtodos, reduzir a quantidade de invocaes
crucial para um bom desempenho, pois muitos
mtodos estaro integrados ao cdigo dos seus
chamadores. Isto implica em certo custo para o
compilador e para o tempo total de execuo, em
um ambiente com compilao dinmica.
Inline possui uma relao direta com o uso da
cache (TANENBAUM, 2006). Aps aplicar esta
otimizao, instrues relacionadas so dispostas
juntas, reduzindo as chances de conflitos na cache
(ZHAO, 2003). Se o mtodo for invocado de maneira
convencional, um registro de ativao ser criado e
seu cdigo se encontrar segmentado do cdigo do
seu chamador. Isto pode significar uma troca de
dados na cache, mesmo que os mtodos tenham um
relacionamento muito grande e atuem sobre as
mesmas informaes.
O acesso a informaes na cache muito mais
rpido, em relao a acessos na memria principal.
Sendo assim, quanto mais instrues puderem ser
agregadas e compartilharem a cache, melhor ser o
desempenho do programa em execuo.

3.2. DESVANTAGENS DE INLINE

Apesar de ser uma tcnica com grande potencial,
inline tambm possui certas desvantagens,
principalmente relacionadas m utilizao da
otimizao.
O principal problema desta otimizao o
crescimento excessivo do tamanho do cdigo
(SERRANO, 1995). Desta forma, um dos fatores mais
importantes no momento da seleo para realizar
inlining de um mtodo o tamanho do seu corpo,
assim como o tamanho do corpo do seu chamador.
Anteriormente foi citada uma vantagem quanto
ao sequenciamento de instrues para melhor
utilizar a cache (CHEN et al, 1989). Isto ocorre
quando o cdigo, tanto do mtodo chamador,
quanto do mtodo chamado, utilizam instrues que
a memria cache comporta, efetuando assim uma
utilizao extremamente mais vantajosa de acessos
memria. Porm, quando o cdigo gerado possui
108
Rangel e Silvaiiiiii
Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
instrues demasiadas para execuo dos
mtodos, agora compartilhando do mesmo
corpo, isto pode se tornar um problema.
Alm de ocasionar problemas de acesso a
cache, inlining de mtodos muito grandes
pode gerar problemas para o alocador de
registradores (LUEH, 1997). Se inline gerar um
cdigo com um nmero elevado de instrues
e operaes sobre dados, aumentar a
presso por registradores. O problema
semelhante ao que ocorre com a memria
cache. Vrias operaes e instrues sero
realizadas no mesmo momento, sendo
necessrio utilizar muitas vezes a memria
para armazenar valores dos registradores
enquanto se executa todas as operaes.
Os melhores mtodos para sofrerem a
aplicao de inline so aqueles com um corpo
pequeno e que so os mais utilizados dentro
do programa. Selecionar mtodos que so
pouco utilizados no significa uma melhora no
desempenho do programa.
Para realizar o controle do crescimento do
cdigo gerado, muitos compiladores utilizam
informaes referentes ao aumento do
cdigo, em percentual. Geralmente, existe um
limite estabelecido para o tamanho final do
cdigo gerado. Assim, durante o processo de
seleo dos mtodos para aplicar inline o
tamanho do cdigo verificado, visando
avaliar o benefcio obtido pela aplicao da
otimizao no mtodo em questo. Isto limita
a seleo de mtodos muito grandes, assim
como a utilizao demasiada de inline.

3.3. FUNCIONAMENTO DE INLINE NA JVM DA
SUN

O processo de compilao inicia no
momento em que o mtodo que est sendo
interpretado atinge um limite de invocaes.
Este processo verifica algumas propriedades
do mtodo, para avaliar se possvel ou no
compil-lo. O tamanho do cdigo gerado no
pode ultrapassar o valor mximo estabelecido
de oito mil (8000) bytes. Se o tamanho do
cdigo ultrapassar este limite, o mtodo no
ser compilado. Alm desta verificao,
outras so realizadas. O mtodo precisa estar
carregado, a estrutura de controle de
bytecode precisa estar criada e sua anlise de
fluxo deve estar presente.
Uma compilao diferente invocada para
mtodos virtuais e no-virtuais. Neste
momento, a JVM possui condies e informaes de
perfil
3
suficientes para identificar o tipo de chamada
de cada mtodo. Se for um mtodo no-virtual, a
JVM verifica a aplicao de inline para este mtodo.
Para o caso de inline de mtodos virtuais, o
processo realizado diferente. Neste caso
executada uma tentativa de tornar o mtodo no-
virtual. Caso obtenha sucesso, este mtodo sofre a
aplicao de inline como se fosse um mtodo no-
virtual. No sendo possvel a aplicao de inline,
utilizada uma rvore de inline. Isto ocorre pelo fato
de que um mtodo virtual pode possuir inmeras
implementaes. A implementao do mtodo atual
localizada nesta rvore de inline, e ento ocorre a
compilao e aplicao da otimizao para a
implementao em questo e o mtodo retornado,
j com seu cdigo utilizando inlining.
Tanto para inlining de mtodos virtuais, quanto
de no-virtuais, necessrio que este tenha sido
utilizado uma grande quantidade de vezes. Existe
um parmetro que controla a quantidade de
invocaes de um mtodo, antes que este seja
selecionado para ser aplicada a otimizao. O valor
padro para este parmetro, na JVM analisada, de
duzentos e cinquenta (250) execues. Sendo assim,
um mtodo pode ser compilado, mas pode no
sofrer inline, caso alguma das verificaes da
otimizao falhe.
Caso o mtodo candidato a utilizar a otimizao
possua chamadas a outros mtodos, existe um
parmetro que controla o nvel em que o compilador
pode chegar ao tentar aplicar a otimizao s
chamadas aninhadas. Por padro, este parmetro
permite que at nove (9) nveis sejam alcanados,
antes que o compilador pare de aplicar a otimizao
em mtodos aninhados. Existe a mesma verificao
de nvel para o caso de mtodos recursivos. Porm,
o valor padro deste parmetro um (1). Isto limita
razoavelmente a aplicao de inline em mtodos que
possuam chamadas recursivas.
A JVM da Sun utiliza uma classificao de
mtodos por temperatura que composta de trs
nveis: frio, morno e quente. Para avaliar a
temperatura de um determinado mtodo alguns
parmetros so utilizados e, com estes, uma
heurstica aplicada. Esta classificao realizada
com base em mdias, estimativas do perfil do
mtodo e do histrico do mesmo. Os valores

3
O perfil de um mtodo composto por informaes
como o tamanho do cdigo, a quantidade de invocaes e
a quantidade de vezes que foi interpretado, entre outras
informaes. Este perfil utilizado durante toda a vida do
programa, sendo essencial no processo de compilao.
109
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
utilizados neste processo so: contagem,
benefcio, trabalho, tamanho e temperatura.
Contagem o nmero de vezes que se
espera executar uma determinada chamada.
Valores mais altos so considerados melhores
para inline, evitando o processo de invocao
convencional um grande nmero de vezes.
Benefcio uma estimativa de tempo que ser
economizado, por execuo, aps a aplicao
de inline a este mtodo. O valor um (1) indica
que est ocorrendo overhead. Valores altos
facilitam a execuo da otimizao, enquanto
valores negativos desabilitam a mesma.
Trabalho uma estimativa de quanto
tempo uma chamada convencional, para este
mtodo, ser necessria. Valores menores so
favorveis para a otimizao, visto que
mtodos pequenos tm tempo de execuo
menor e estes so os mais proveitosos para
sofrerem inlining. Tamanho a quantidade de
ns que se espera gerar para este mtodo, no
grafo de fluxo de controle. Este valor no
considera o inline de chamadas aninhadas
neste mtodo. Para avaliar este valor so
utilizados o cdigo de mquina, se j foi
gerado em uma compilao posterior, e o
bytecode do mtodo. Valores menores de
tamanho so melhores para inline, pois como
mencionado anteriormente, mtodos
pequenos tendem a gerar um benefcio maior
quando se aplica inline.
Temperatura o resultado da heurstica
utilizada. Este valor a base da classificao,
com os mtodos podendo ser considerados
frios, mornos ou quentes. Segundo os
desenvolvedores da JVM, se pudessem ser
oniscientes, haveria dois valores para
temperatura: com e sem inline. Este valor
conseguido utilizando a expresso:

Contagem x Benefcio.

Este valor ajustado automaticamente
para cada mtodo analisado, levando em
considerao que os valores utilizados na
expresso so atualizados de acordo com o
perfil de cada programa. Porm, a heurstica
muito simplificada, podendo falhar durante o
processo de aplicao da otimizao.
Caso alguma das verificaes realizadas
antes de aplicar inline do mtodo falhe, este
ser classificado como frio e gerado com o
cdigo normal, sem que seja realizada a cpia
de seu corpo no local onde h chamadas para
o mesmo. Portanto, mtodos muito grandes, pouco
utilizados, que estejam aninhados em muitos nveis,
entre outras caractersticas, no sofrero a aplicao
de inline e sero classificados como frios. Porm,
mesmo um mtodo no sofrendo a aplicao
imediata da otimizao, ele pode ser selecionado
para aguardar em uma fila de mtodos mornos. Isto
ocorre quando o resultado da heurstica de
classificao no foi considerado bom o suficiente
para aplicar inline do mtodo, mas seus parmetros
no fazem com que este seja considerado um
mtodo frio. Por isto este mtodo que no frio,
mas tambm no quente, considerado um
mtodo morno.
Os mtodos que compem a fila de mtodos
mornos so os que no possuem um grande
benefcio, mas que podem aumentar, mesmo que
pouco, o desempenho do programa se sofrerem a
aplicao de inline. A utilizao de mtodos desta fila
depende dos mtodos anteriormente utilizados para
aplicar a otimizao. Existe um controle do tamanho
mximo do programa aps a compilao e aplicao
de inlining. A diferena entre este valor mximo e o
valor utilizado para aplicar a otimizao
anteriormente considerada um espao disponvel
para a aplicao de inline em outros mtodos.
Caso ainda exista recursos disponveis para
aplicao da otimizao, a fila de mtodos mornos
percorrida. Se um mtodo couber no espao
disponvel, este selecionado para sofrer inline. Caso
o espao no seja suficiente, este mtodo
removido da fila e o prximo verificado. O
tamanho do mtodo, para verifica se h espao
disponvel ou no, encontra-se no seu perfil.
Enquanto ainda h espao disponvel e mtodos na
fila, novos mtodos so avaliados.
Se o espao disponvel for totalmente utilizado, a
fila de mtodos candidatos a inline esvaziada. Isto
realizado para que, se esta tentativa, de aplicar a
otimizao em mtodos armazenados na fila,
ocorrer novamente, nada seja executado e o
processo finalize sem desperdcio de tempo. Afinal,
sem espao disponvel para realizar inline, no faz
sentido tentar aplicar a otimizao em outros
mtodos. Este espao disponvel atualizado no
momento que mtodos e classes so desalocados.
Aps aplicar inline, outras otimizaes so
executadas no cdigo j expandido. Esta uma
grande vantagem desta otimizao, pois agora as
outras otimizaes tem um escopo maior para
serem aplicadas onde antes havia apenas uma
chamada a mtodo e no era possvel otimizar esta
parte do cdigo. Algumas das otimizaes
executadas so: peephole, alocao de
110
Rangel e Silvaiiiiii
Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
registradores, conditional constant
propagation e loop unrolling, entre outras
(MUCHNICK, 1997).
Logo em seguida, a execuo do
programa retomada normalmente. Agora,
possivelmente, com um mtodo no mais
interpretado, mas compilado, aplicado inline e
com outras otimizaes realizadas em seu
novo corpo. Isto pode ocasionar um ganho de
desempenho considervel, mesmo com todos
estes processos sendo realizados em tempo
de execuo.

4. AVALIAO EXPERIMENTAL

A avaliao experimental foi realizada em
um computador com processador Intel Dual
Core T2160 2.1 GHZ, 2GB de memria principal,
e utilizando o sistema operacional Ubuntu
8.10, com kernel 2.6.27-14 generic. A JVM da Sun
utilizada foi a verso 1.6.19.
A Tabela 1 fornece uma descrio dos programas
utilizados na avaliao experimental. Os oito
primeiros fazem parte do DaCapo Benchmark
(BLACKBURN et al, 2006), os prximos cinco
programas fazem parte do Java Grande Frum
Benchmark (BULL et al, 2000) e os ltimos sete
fazem parte do Shootout Benchmark (FULGHAM,
2010). Cada conjunto de benchmark possui um foco
diferente. Trs aspectos da execuo so explorados
pelos programas: utilizao de memria, utilizao
de processador e operaes de entrada e sada. Os
programas do DaCapo Benchmark exploram os trs
aspectos. J os programas do Java Grande Frum
Benchmark exploram mais o uso do processador e
acessos memria. Por fim, os programas do
Shootout Benchmark exploram as operaes de
entrada e sada.

Programa Caractersticas Entrada


Descrio Classes Mtodos

ANTLR Gerador de analisador sinttico 675 3368 Large
BLOAT Otimizador de bytecode Java 831 3180 Large
CHART JFree Chart 1531 6474 Large
ECLIPSE Testes na IDE Eclipse 2627 7276 Large
JYTHON Interpretador Python 1329 4889 Large
LUSEARCH Busca Lucene 688 3252 Large
PMD Analisador de arquivos Java 1192 3805 Large
XALAN Transforma XML em HTML 1170 3727 Large
EULER Resoluo de equaes de Euler 406 2300 sizeB
MOLDYN Simulao molecular 441 2433 sizeB
MONTECARLO Simulao Monte Carlo 420 2332 sizeB
RAYTRACER Renderizao 3D 409 2310 sizeB
SEARCH Busca alfa-beta 402 2297 sizeB
BINARY-TREES Gerador de rvores binrias 345 2132 22
CHAMENEOS Simulao de criaturas 366 2219 80000000
FASTA Gerador de sequncias de DNA 344 2133 500000
K-NUCLEOTIDE Atualizao de hash 493 2546 484 MB
MANDELBROT Gerador bitmap 412 2327 6000
N-BODY Simulao de corpos 440 2425 100000000
SPECTRAL Calcula da norma espectral 438 2401 10000x10000
Tabela 1. Programas utilizados na avaliao

4.1. ANLISE DE DESEMPENHO

A Figura 2 apresenta o tempo mdio de
execuo de cada programa, com inline ligado
e desligado. Em cada figura, as duas primeiras
colunas representam a execuo do programa
utilizando o compilador Cliente, enquanto as duas
ltimas a execuo com o compilador Servidor. A
primeira e a terceira coluna representam a
otimizao inline desligada e as outras duas colunas
111
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
a otimizao ligada. Alm disto, cada barra
est dividida em trs componentes, a saber:
tempo gasto em mtodos interpretados,
tempo gasto em mtodos compilados e tempo
gasto em outras atividades.

Figura 2. Tempo total de execuo em segundos, para cada programa.

4.1.1. Impacto de Inline no Compilador Cliente

O compilador Cliente obteve um resultado
interessante quando a otimizao foi ligada.
Pode-se verificar que a sua estratgia muito
superior adotada pelo compilador Servidor.
Apenas FASTA apresentou queda de 7,21% no
desempenho quando a otimizao foi ligada e

112
Rangel e Silvaiiiiii

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
apenas SEARCH obteve um ganho
insignificante de desempenho. Os programas
executados utilizando este compilador
apresentaram desempenho, em mdia, 26,25%
superior quando a otimizao inline foi
utilizada.
A variao de ganho de desempenho foi
de 0,20% (SEARCH) a 81,39% (CHAMENEOS).
Mesmo entre os piores resultados, o ganho
de desempenho com inline razovel.
Portanto, faz muito sentido utilizar esta
otimizao no compilador Cliente.
Os programas que obtiveram os piores
resultados so os considerados kernels. Estes
programas possuem poucos mtodos e
geralmente, apenas um mtodo invocado
frequentemente. Portanto, os resultados
demonstraram que inline no faz sentido em
programas muito pequenos, com pouca
quantidade de mtodos. Esta otimizao atua
melhor quando diferentes mtodos so
invocados frequentemente, pois neste caso o
overhead da no utilizao de inline seria
maior. Alm disso, uma maior poro do
cdigo disponibilizada para sofrer a
aplicao de outras otimizaes. Outro ponto
importante a ressaltar o fato de inline
reduzir consideravelmente a chamada de
mtodos nativos.
Com o objetivo de reduzir o slowdown
ocasionado por inline para FASTA e SEARCH, a
entrada destes programas foi alterada para
obter um aumento do tempo de execuo.
No caso de FASTA, ao invs de uma perda de
desempenho de 7,21%, este obte um ganho de
0,42%. Mesmo no sendo um ganho
significativo, este ainda melhor do que uma
perda. Contudo, estes resultados somente
foram obtidos quando o tempo total de
execuo deste programa atingiu,
aproximadamente, uma hora. J para SEARCH
O resultado obtido com o aumento do tempo
de execuo foi significativo. Este programa
passou de um ganho 0,20% para 7,21%. Embora
os resultados obtidos pelo compilador Cliente
sejam significantes, estes ltimos resultados
demonstram que a estratgia utilizada pela JVM
(parametrizao esttica de inline) vantajosa, em
alguns casos, apenas para longos tempos de
execuo.

4.1.2. Impacto de Inline no Compilador Servidor

Para o compilador Servidor, a estratgia da
aplicao de inline no to eficiente quanto a do
compilador Cliente. Quando comparado com o
tempo de execuo do compilador Cliente, o
Servidor se mostrou mais rpido, tanto para a
otimizao ligada quanto desligada. Porm, a
reduo do tempo de execuo com a aplicao de
inline mais significativo no Cliente do que no
Servidor.
A variao do desempenho, considerando apenas
os programas que obtiveram ganho de
desempenho, foi de 0,09% (N-BODY) a 39,73%
(RAYTRACER). Esta variao tem um limite superior
inferior variao constatada no compilador Cliente.
Alm disso, a quantidade de programas que
obtiveram um melhor resultado com a otimizao
ligada foi menor.
Com base nos resultados possvel concluir que
o compilador Servidor age melhor durante a
execuo de programas que despendem um tempo
maior de execuo. Um dos fatores para que isto
ocorra est no fato de que o compilador Servidor
tende a adiar, mais que o compilador Cliente, a
compilao de mtodos. Isto pode ser verificado
com base no percentual de compilao de mtodos.
A Tabela 2 apresenta informaes sobre a
requisio e compilao de mtodos, feita pelos dois
compiladores. Estas informaes foram coletadas
durante a execuo dos programas com a
otimizao inline ativada. Comparando os dados de
um compilador com o outro, nota-se que o Servidor
mais seletivo quanto a compilao de mtodos.
Estes dados demonstram que este compilador adia
mais a deciso de compilar um mtodo, quando
comparado ao compilador Cliente.
113
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
Cliente Servidor
Mtodos Mtodos

Programas
Requisitados Compilados Requisitados Compilados
ANTLR 18054 497 (2,75%) 8086 335 (4,15%)
BLOAT 7229 748 (10,35%) 16328 562 (3,44%)
CHART 2439 675 (27,68%) 12493 343 (2,75%)
ECLIPSE 15839 3311 (20,90%) 50785 2240 (4,41%)
JYTHON 16402 1170(7,13%) 16934 963 (5,69%)
LUSEARCH 4440 420 (9,46%) 3655 360 (9,85%)
PMD 2876 991 (34,46%) 10393 607 (5,84%)
XALAN 4179 1581 (37,83%) 12704 1314 (10,34%)
EULER 524 70 (13,36%) 1446 50 (3,46%)
MOLDYN 155 27 (17,42%) 153 27 (5,88%)
MONTECARLO 680 146 (21,47%) 524 146 (21,56%)
RAYTRACER 323 35 (10,84) 394 23 (5,84%)
SEARCH 192 24 (12,50%) 1281 11 (0,86%)
BINARY-TREES 107 21 (19,63%) 65 8 (12,31%)
CHAMENEOS 145 69 (47,59%) 578 51 (8,82%)
FASTA 109 25 (22,94%) 49 3 (6,12%)
K-NUCLEOTIDE 252 64 (25,40%) 348 56 (16,09%)
MANDELBROT 49 18 (36,73%) 45 2 (4,44%)
N-BODY 85 18 (21,18%) 61 2 (3,28%)
SPECTRAL 245 23 (9,39%) 62 5 (8,06%)
Tabela 2. Histrico de compilao

No caso de um programa possuir um
tempo de execuo curto e ser executado
pelo ambiente justamente com o compilador
Servidor, pode ocorrer de seus mtodos
serem interpretados a maior parte deste
tempo, pois este compilador ainda estar
reunindo informaes para decidir sobre a
compilao do mtodo e a possvel aplicao
de inline. Esta deciso de adiar a compilao e
otimizao do mtodo pode ocasionar uma
perca de desempenho em programas
menores. Porm, esta deciso se mostra
eficiente quando o programa possui muitos
mtodos e um longo tempo de execuo.
Assim como realizado com o compilador
Cliente, o tamanho da entrada dos programas
foi aumentado para avaliar os resultados do
compilador Servidor para programas com um
tempo maior de execuo. Contudo,
diferentemente dos resultados obtidos pelo
compilador Cliente, em alguns casos o degradao
do desempenho se agrava.
Surpreendentemente o ganho de desempenho
no ocorreu na execuo dos programas kernel,
utilizando o compilador Servidor. Porm, o problema
diminuiu consideravelmente na maioria dos
programas. Por exemplo, FASTA passou de uma
perda de 14,78% para, apenas, 0,28%, para um tempo
de execuo de aproximadamente uma hora.
Embora esta perda seja insignificante, este programa
ainda no atingiu o que se espera da otimizao. A
mesma situao ocorre com MOLDYN. Este passou de
uma perda de 27,79% para 9,68%, para um tempo de
execuo aproximadamente de cinquenta minutos.
Por outro lado, outros programas obtiveram um
resultado positivo, tendo o ganho de desempenho
variando entre 3,90% e 69,38%. Isto ocorreu para
EULER (+3,90%), CHART (+20,84%), LUSEARCH (+30,19%)
e ANTLR (+69,38%). Estes que anteriormente no
obtiveram um bom desempenho (no caso de ANTLR,
114
Rangel e Silvaiiiiii

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
inline ocasionava uma perda de 17,31%), foram
consideravelmente beneficiados pela
aplicao de inline, isto para um tempo de
execuo superior a uma hora.
No caso do compilador Servidor, os
resultados demonstram que um ganho con-
sidervel de desempenho somente obtido
por programas com longo tempo de
execuo. Alm disto, no compilador Servidor
a estratgia de aplicao de inline funciona
melhor para programas reais.

4.1.3. Compilador Cliente x Compilador
Servidor

Como mencionado anteriormente, a
estratgia do compilador Cliente superior a
do Servidor. Quando a otimizao foi ligada,
em mdia, os programas obtiveram um ganho
de 26,25%, contra apenas 6,67% para o
compilador Servidor. Porm, o compilador
Cliente no o mais vantajoso entre os dois.
Este ganho de desempenho no significa que
o tempo total de execuo do programa ser
menor. Foram poucos os programas
utilizados em que isto ocorreu. Geralmente, o
compilador Servidor obtm um desempenho
muito superior ao do compilador Cliente,
mesmo com o problema da otimizao inline
ocorrendo.
Com os dados da Tabela 2 possvel traar
um comparativo entre o comportamento dos
dois compiladores. O compilador Servidor,
apesar de receber mais requisies, muito
mais seletivo que o compilador Cliente. Seu
percentual de compilao foi de apenas 5,18%
das requisies recebidas. Enquanto isso, o
compilador Cliente compilou 13,36% das
requisies que recebeu. Mesmo compilando
um nmero menor de mtodos, o compilador
Servidor obtm um tempo total de execuo
menor que o compilador Cliente. Isto
demonstra que os problemas ocasionados
por inline so contornados pela aplicao de
outras otimizaes.
Apenas um programa apresentou um
maior percentual de mtodos compilados
pelo Servidor. ANTLR saltou de 2,75% para
4,15%. Contudo, seu desempenho no
compilador Servidor com inline ligado foi
17,31% pior do que com o inline desligado. J
no compilador Cliente, este programa obteve
um ganho de desempenho de 24,03% no seu
tempo total de execuo, quando inline foi
ativado. Isto caracteriza os problemas que podem
ocorrer pela agressividade do compilador Servidor e
tambm pela sua m utilizao da otimizao inline,
sendo uma delas a parametrizao esttica, o que
no leva em considerao as caractersticas do
programa.

4.1.4. Decises de Inline

Para compreender o que ocasionou uma perda
de desempenho para os programas necessrio
analisar os seus perfis. Desta forma, os bytecodes
dos programas ANTLR, CHART, LUSEARCH, EULER,
MOLDYN, FASTA, N-BODY e SPECTRAL foram analisados
para gerar um perfil dos bytecodes utilizados. Devido
as restries de espao, os dados coletados no
sero apresentados.
Como o padro de bytecodes d origem ao
cdigo de mquina, no momento em que o mtodo
compilado, programas com um padro semelhante
de bytecodes iro gerar um padro semelhante de
cdigo de mquina. Desta forma, existe a
possibilidade de programas com as mesmas
caractersticas sofrerem o mesmo problema. Um
ponto interessante em relao aos bytecodes dos
programas que obtiveram uma perda de
desempenho que o seu padro foi alterado quando
utilizado o compilador Servidor.
Os bytecodes mais utilizados nestes programas
realizam operaes aritmticas, o controle para o
carregamento de valores e clculo. Este ltimo gera
um alto custo de processamento. Alm destas
instrues, outro tipo muito utilizado o de
instrues de acesso e gravao de atributos de
objetos e invocaes de mtodos virtuais.
A maior parte das instrues de carregamento e
armazenamento de valores substituda no
compilador Servidor por instrues com o prefixo
fast. Este tipo de instruo no foi utilizada pelo
compilador Cliente. Com isto, pode-se avaliar que
este tipo de instruo tem o objetivo de otimizar a
execuo. Porm, este perfil de programa pode
sofrer degradao de desempenho para casos onde
a quantidade de mtodos pequena e exista uma
grande quantidade de bytecodes utilizados para
operaes aritmticas.
Instrues fast, quando utilizado inline, fazem
com o que o tempo total de execuo aumente. Isto
ocorre pelo fato de que a cpia de um mtodo para
dentro de outro, utilizando este perfil de bytecodes,
degrada a gerao de cdigo. Isto ocasiona um
crescimento do cdigo gerando presso por
registradores e misses na cache. Portanto, um
programa que gere este perfil de instrues de
115
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
bytecode est propenso a sofrer destes
problemas, quando a otimizao inline
ativada.
Utilizando as informaes sobre a
compilao de mtodos nos dois
compiladores, juntamente com esta deciso
de substituir os bytecodes durante a execuo
com o compilador Servidor, pode-se concluir
que estas no formam uma estratgia
consistente para programas pequenos.
Porm, esta estratgia tende a melhorar o
desempenho da maior parte dos programas
quando o tempo de execuo elevado.

4.2. ANLISE DETALHADA

Alm de medir o tempo de execuo com
inline desligado e ligado, durante a anlise
experimental foram coletadas para alguns
programas informaes de hardware por
meio da ferramenta Performance Application
Programming Interface (PAPI) (TERPSTRA et
al, 2010). As informaes mais importantes
quando se trata da otimizao inline so:
quantidade de instrues por ciclo (IPC) e
acessos memria cache.
Para o compilador Cliente os
experimentos foram realizados para SEARCH
e FASTA. SEARCH apresentou o mesmo IPC,
para inline desligado ou ligado. J FASTA
obteve uma reduo do IPC, passando de
0,84 para 0,75 instrues por ciclo, quando a
otimizao inline foi ligada. Estes resultados
demonstram que a otimizao causa um
efeito negativo para FASTA, quanto
quantidade de instrues executadas por
ciclo. Esta reduo de IPC uma das causas da
degradao de desempenho deste programa.
Para o compilador Servidor os
experimentos foram realizados apenas para
EULER, MOLDYN, FASTA, N-BODY e SPECTRAL. No
foram coletadas informaes para os outros
programas (que obtiveram uma queda de
desempenho) devido ao fato da ferramenta
utilizada no funcionar corretamente para o
benchmark DaCapo.
EULER e MOLDYN apresentaram um
pequeno aumento no IPC utilizando inline
(0,91 para 0,92 e 1,45 para 1,46
respectivamente). Fasta obteve uma reduo
de IPC passando de 0,92 para 0,89. N-BODY se
manteve estvel, este foi um dos motivos que
o levou a ter um desempenho insignificante.
Outros experimentos foram realizados com os
mesmos programas para avaliar o acesso memria.
Para o compilador Cliente os dois programas
apresentaram uma reduo na quantidade de
acertos cache (de 1,64% para SEARCH e 1,93% para
FASTA). Para SEARCH esta reduo no ocasionou
perda de desempenho. FASTA ainda apresentou um
aumento de 3% na quantidade de acessos cache,
ocasionando perda de desempenho. Isto demonstra
que a qualidade do cdigo gerado pelo compilador
cliente (utilizando inline) para estes programas no
possui uma boa localidade.
J no compilador Servidor os resultados foram
mais variados. EULER apresentou um aumento, tanto
para os acertos, quanto para os erros de acesso
cache. Porm, os erros aumentaram em 5,17%,
enquanto os acertos aumentaram em apenas 1,43%.
Este um dos motivos deste programa ter perda de
desempenho, pois muitos erros de acesso a
memria cache ocorrem, quando a otimizao
ligada.
Para MOLDYN OS aumentos na quantidade de
acessos e erros foram insignificantes (de 0,09% e
0,58% respectivamente). Embora estes dados no
indiquem o que ocasionou a perda de desempenho
de 27,79%, possivelmente isto foi ocasionado pelo
tempo gasto pelo compilador. Como o compilador
Servidor um compilador agressivo, ele tende a
gerar um alto tempo de compilao.
FASTA apresentou nmeros negativos nos dois
aspectos. A quantidade de erros de acesso
aumentou em 4,25% e a quantidade de acertos de
memria aumentou em 19,05%. Estes dados
demonstram que a utilizao da cache, quando a
otimizao inline foi ligada, foi prejudicial para a
execuo. Neste caso, ocorreu o mesmo problema
ocasionado com o compilador Cliente, o cdigo
gerado pelo compilador Servidor possui uma
qualidade baixa, ocasionando uma m localidade.
N-BODY se manteve estvel tambm quanto aos
acessos cache, obtendo apenas um aumento na
quantidade de erros de 0,87% e um aumento
insignificante na quantidade de acertos de 0,001%.
Mesmo com este aumento nos erros de acesso, o
desempenho deste programa se manteve
consideravelmente estvel. For fim, para SPECTRAL o
uso de inline no teve impacto na quantidade de
acessos cache, contudo ocasionou uma reduo de
35,14% na quantidade de acertos.
Consequentemente, ocasionando uma perda de
desempenho.

5. CONCLUSES E TRABALHOS FUTUROS

116
Rangel e Silvaiiiiii
Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
Em geral, os trabalhos que descrevem
ambientes Java com compilao dinmica,
no apresentam uma anlise detalhada do
impacto das otimizaes aplicadas pelo
compilador. Embora, alguns trabalhos
(BURKE et al, 1999; CIERNIAK et al, 2000; GU
et al, 2000; SUGANUMA et al, 2000)
destaquem a importncia da aplicao de
inline no descrevem a heurstica utilizada,
nem apresentam o ganho real obtido por esta
otimizao. Este trabalho descreveu de forma
detalhada a heurstica utilizada na aplicao
de inline pela mquina Virtual Java da Sun,
como tambm apresentou uma anlise
detalhada do ganho de desempenho obtido
por esta otimizao.
A aplicao de inline realizada pelo
compilador Cliente se mostrou mais eficiente.
Apenas um programa, obteve perda de
desempenho. Por outro lado, a agressividade
do compilador Servidor se torna prejudicial
em muitos casos, ocasionando uma perca de
desempenho significativa em alguns casos.
Outro aspecto interessante que o tempo de
execuo drasticamente reduzido quando
chamadas de mtodos nativos sofrem a
aplicao de inline. Em mdia, os programas
utilizando o compilador Cliente obtiveram
uma melhora de 26,25% no seu desempenho.
Por outro lado, utilizando o compilador
Servidor, estes programas obtiveram uma
mdia geral de 6,67%. Esta diferena
comprova que nem sempre a agressividade
a escolha correta.
O problema para o compilador Servidor
ocorre quando comparamos a sua execuo
com inline ligado e desligado. Porm, o
compilador Servidor se mostra mais eficiente,
considerando-se apenas o tempo total de
execuo. Os programas obtiveram na mdia
um tempo total de execuo menor quando
este compilador foi utilizado. Contudo, este
tempo poderia ser ainda melhor se a
estratgia utilizada na aplicao de inline
fosse ajustada para cada programa.
Uma alterao nos algoritmos que fazem
parte da aplicao desta otimizao
possivelmente melhoraria o benefcio de
inlining. Uma alterao que, pelo menos,
impea a degradao do desempenho dos
programas j seria interessante. Informaes
sobre o perfil de bytecodes, a quantidade de
chamadas a mtodos, o tamanho e o tempo
de execuo esperado para um determinado
programa podem ser utilizadas para realizar esta
alterao.
Um trabalho futuro ser alterar a poltica de
aplicao de inline, inicialmente com o objetivo de
evitar a perda de desempenho que ocorre em alguns
programas, de forma que inline possibilite um ganho
de desempenho para todos os programas que
possuam um determinado perfil.
O objetivo principal alcanar um ganho de
desempenho significativo para todas os programas
Java que utilizem esta JVM, realizando o que
proposto pela otimizao inline. Isto pode ser
alcanado com a utilizao de parmetros dinmicos
para o controle da utilizao da otimizao. Hoje
estes parmetros so fixos e independem do perfil
do programa. Sendo assim, possvel utilizar as
informaes sobre as caractersticas dos programas
para parametrizar a seleo e aplicao de inline de
mtodos. Este um trabalho futuro mais ambicioso,
alterar dinamicamente a parametrizao de inline.

REFERNCIAS

AHO, A. V., SETHI, R., ULLMAN, J. D. Compiladores,
Princpios, Tcnicas e Ferramentas. So Paulo, Brasil:
Pearson, 2007.
APPEL, A. W. Modern Compiler Implementation in C.
New York, USA: Cambridge University Press, 1998.
ARNOLD, M., FINK, S. J., SARKAR, V., SWEENEY, P. F.
A Comparative Study of Static and Profile-based
Heuristics for Inlining. In: ACM SIGPLAN Workshop
on Dynamic and Adaptive Compilation and
Optimization. USA: ACM Press, 2000.
BAKER, H. G. Inlining Semantics for Subroutines
which are Recursive. ACM Sigplan Notices, v. 27, p.
3946, 1992.
BLACKBURN, S. M., GARNER, R., HOFFMAN, C.,
KHAN, A. M., McKINLEY, K. S., BENTZUR, R., DIVAN,
A., FEINBERG, D., FRAMPTON, D., GUYER, S. Z.,
HIRZEL, M., HOSKING, A., JUMP, M., LEE, H., MOSS,
J. E. B., PHANSALKAR, A., STEFANOVI C, D.,
VANDRUNEN, T., von DINCKLAGE, D.,
WIEDERMANN, B. The DaCapo Benchmarks: Java
Benchmarking Development and Analysis. In:
Proceedings of the Conference on Object-oriented
Programming Systems, Languages, and Applications,
volume 41, pages 169-190, USA. ACM, 2006.
BULL, M., SMITH, L., WESTHEAD, M., HENTY, D.,
DAVEY, R. Benchmarking Java Grande Applications.
In: Proceedings of the International Conference on
The Practical Applications of Java, pages 63-73, 2000.
BURKE, M. G., CHOI, J.-D. The Japaleno Dynamic
Optimizing Compiler for Java. In: Proceedings of the
Java Grande Conference, pages 129-141, 1999.
117
A mquina virtual Java e a otimizao inline: um estudo de caso

Revista Tecnolgica Maring, v. 21. p. 103-118, 2012
CHEN, W. Y., CHANG, P. P., CONTE, T. M.,
HWU, W. W. The Effect of Code Expanding
Optimizations on Instruction Cache Design.
IEEE Transactions on Computers, v.42 n.9,
p.1045-1057, 1989.
CHIBA, S. Macro Processing in Object-
Oriented Languages. In: Proceedings of the
Technology of Object-Oriented Languages
and Systems. Tsukuba, Japo: IEEE, IEEE
Press, 1998.
CIERNIAK, M., LUEH, G.-Y, STICHNOTH, J. M.
Practicing JUDO: Java Under Dynamic
Optimizations. In Proceedings of the
Conference on Programming Languages
Design and Implementation, Vancouver,
Canad. ACM SIGPLAN, 2000.
CRAIG, I. D. Virtual Machines. Inglaterra:
Springer-Verlag London Limited, 2006.
DAMAS, L. M. D. Linguagem C. Brasil: LTC,
2007.
DA SILVA, A. F., SANTOS COSTA, V. Our
Experiences with Optimizations in Sun's Java
Just-in-time Compilers. In Proceedings of the
Brazilian Symposium on Programming
Languages, pages 51-65, Brasil. SBC, 2006.
DEITEL, H. M., DEITEL, P. J. Java Como
Programar. Porto Alegre, Brasil: Prentice Hall,
2010.
DEPARTMENT OF DEFENSE. Ada 2005
Reference Manual. USA, 2006.
FULGHAM, B. The Computer Language
Benchmark Game. http:// shootout.
alioth.debian.org/; acesso em 20 de Maro
2010.
GU, W., BURNS, N. A., et al. The Evolution of a
High-Performing Java Virtual Machine. IBM
Sytems Journal, 39(1): 135-150, 2000.
LEDGARD, H. Reference Manual for the ADA
Programming Language. USA: Springer-Verlag
New York, Inc., 1983.
LIANG, S., BRACHA, G. Dynamic Class
Loadding in Java VirtualMachine. In:
Proceedings of the Conference on Object-
Oriented Programming Systems, Languages
and Applications, pp. 3644, Vancouver,
Canada, October 1998.
LINDHOLM, T., YELLIN, F. The Java Virtual
Machine Specification Second Edition.
California, USA: Addison Wesley, 1999.




LUEH, G.-Y.; GROSS, T.; ADL-TABATABAI, A.-R. Global
Register Allocation Based on Graph Fusion. In:
Proceedings of the International Workshop on
Languages and Compilers for Parallel Computing.
Londres: Springer-Verlag, 1997.
LUTZ, M., ASCHER, D. Aprendendo Python. Porto
Alegre, Brasil: Bookman, 2007.
MEYER, J., DOWNING, T. Java Virtual Machine. USA:
O'Reilly, 1997.
MICROSYSTEMS, S. The Java HotSpot Virtual
Machine. Technical report, Sun Developer Network
Community, 2010.
MUCHNICK, S. S. Advanced Compiler Design And
Implementation. USA: Morgan Kauf-mann, 1997.
SCOTT, M. L. Programming Language Pragmatics.
USA: Elsevier, 2008.
SEBESTA, R. W. Conceitos de Linguagens de
Programo. Brasil: Bookman, 2011.
SERRANO, M. A Fresh Look to Inlining Decision. In:
Proceedings of the International Computer
Symposium. Cidade do Mxico, Mxico: Universit
de Montral, 1995.
STREIB, J. T. Guide To Assembly Language. USA:
Springer Verlag, 2011.
SUGANUMA, T., OGASAWARE, T., TAKEUCHI, M.,
YASUE, T., KAWAHITO, M., ISHIZAKI, K., KOMATSU,
H., NAKATANI, T. Overview of the IBM Java Just-in-
Time Compiler. IBM Systems Journal, v. 39, n. 1, p.
175193, 2000.
STROUSTRUP, B. What is Object-Oriented
Programming? In: Proceedings of the European
Conference on Object Oriented Programming. Paris,
Frana: Springer-Verlag, 1991.
TANENBAUM, A. S. Organizaco Estruturada de
Computadores. Brasil: Prentice-Hall, 2006.
TERPSTRA, D., JAGODE, H., YOU, H., DONGARRA, J.
Collecting Performance Data with PAPI-C. In
Proceedings of the Parallel Tools Workshop, pages
63-73, Germany. Springer Verlag, 2010.
VERNNERS, B. Inside the Java 2 Virtual Machine. New
York, USA: Mc Graw Hill, 1999.
ZHAO, P.; AMARAL, J. N. To Inline or Not to Inline?
Enhanced Inlining Decisions. In Proceedings of the
Workshop on Languages and Compilers for Parallel
Computing, 2003.

118