dalvikvm e jvm (victor nascimento)
TRANSCRIPT
Quando eu comecei...
- Background Javeiro
- Algumas brincadeiras com Swing™
- Não existia Java FX™
- Acreditava que Java era a melhor coisa já
inventada pela humanidade
- Me disseram que Android == Java
Java Virtual Machine
- Máquina virtual de pilha (stack)
- Carrega e interpreta arquivos .class
- Possui JIT (Just in Time compilation)
- Possui duas principais áreas de memória:
- Heap: memória de instâncias
- PermGen (Metaspace): memória de classes, métodos,
construtores e estado de classe (estático)
Dalvik Virtual Machine
- Máquina virtual de registros (register)
- Carrega e interpreta arquivos .dex
- Possui JIT (Just in Time) a partir de Android 2.2
- Possui diferentes estruturas de memória:
- Heap? PermGen? Method Area?
Objetivos da DalvikVM:
- 20MB!!! de RAM para a aplicação
- CPUs de 250-500MHz (pior que um Pentium 4)
- Executada na bateria (não na tomada)
https://sites.google.com/site/io/dalvik-vm-internals
Estratégia:
1. Formato de execução mais enxuto
a. .dex ao invés de .class e .jar
2. Diminuir o número de instruções na execução
a. register based VM ao invés de stack based VM
3. Compartilhar a inicialização dos processos
a. processo de fork da Dalvik (Zygote)
.dex
- Pool compartilhado de constantes entre todas as
classes:
- Strings
- Type ids
- Proto ids
- etc...
Problemas e limites da Dalvik
- Garbage Collector tem que respeitar o
compartilhamento de constantes
- Dex limit 65k
- Será que o Java não tem nenhum limite?
Testando o limite do Java
- Dex limit é quando temos mais que 65536 (2^16)
métodos OU atributos em um único arquivo.
- Vamos gerar um único arquivo Java (um .class)
que ultrapasse este número?
.dex não é um .class gigante
- Possuem os mesmos limites
- Possuem quase as mesmas estruturas
- Diferenciam nos opcodes (instruções virtuais)
- etc...
ATENÇÃO!!!
- Para diminuir o número de métodos gerados (e
ajudar a se manter longe do Multidex), evitem criar
métodos acessores sintéticos!
http://jakewharton.com/exploring-java-hidden-costs/
2 - Register based VM
- Diminui o número de instruções executadas
- Evita acesso à memória desnecessariamente
- Consome o fluxo de instruções de forma mais
eficiente (maior valor semântico por instrução)
3 - Fork da VM: Zygote
- O init.rc do Android inicializa um serviço daemon
chamado Zygote que é uma instância da DalvikVM
“purinha”
- Através de uma socket, o Zygote faz um fork de si
mesmo e retorna o pid para o ActivityManager
3 - Fork da VM: Zygote (parte 2)
- Um fork copia toda a memória do Zygote para um
espaço de memória reservado de forma bem
eficiente.
- Assim, ao abrir um app ele já possui uma instância
da VM “a quente”
Referências
https://dzone.com/articles/jvm-architecture-explain
ed
https://docs.oracle.com/javase/specs/jvms/se8/ht
ml/
https://source.android.com/devices/tech/dalvik/in
dex.html
Referências
https://anatomyofandroid.com/2013/10/15/zygote/
http://multi-core-dump.blogspot.com.br/2010/04/a
ndroid-application-launch.html
www.concretesolutions.com.br
Rio de Janeiro – Rua São José, 90 – cj. 2121Centro – (21) 2240-2030
São Paulo - Av. Nações Unidas, 11.541 3º andar - Brooklin - (11) 4119-0449
Ajudamos empresas a criar produtos digitais de sucesso