Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML.
Tira-Dúvidas
Caches e DAOs, driblando restrições de máquina, VMs alternativas e relatórios.
JVM mais enxuta?
Existe alguma JVM que ocupe menos memória RAM que a da Sun (o mínimo possível) e que ainda seja compatível com o máximo da especificação? Não é necessário que a JVM inclua a parte de interfaces gráficos (Swing e AWT): o objetivo é usá-lo para executar processos junto com o sistema operacional.
Carlos Alberto Nakazawa
O uso de mais memória RAM pelo Java é inevitável, porque características como código portável, garbage colection, segurança e frameworks ricos têm seu custo. Tanto é que você não encontrará alternativas com arquitetura e características semelhantes (ex.:Smalltalk ou .Net) que sejam significativamente melhores em uso de memória. É o preço a se pagar por uma plataforma de desenvolvimento de mais alto nível.
Disto isto, não adianta muito procurar implementações alternativas, pois uso de RAM do JRE da Sun não é uma “deficiência” que talvez outras implementações não tenham. Outras implementações poderão usar menos RAM se fizerem sacrifícios em outra parte – por exemplo, usando compiladores JIT menos sofisticados (que vão produzir código menos eficiente) ou técnicas mais simples de garbage collection (que, por exemplo, geram pausas maiores). Mesmo assim, a diferença não será grande. Você acabará fazendo grandes sacrifícios de desempenho em troca de 15%, 20% de economia de RAM. Geralmente não vale a pena.
Se a aplicação tiver muito pouca necessidade de desempenho, pode valer a pena desativar o compilador JIT (na JVM da Sun, use o switch –Xint). Isso pode ser uma boa idéia também para processos de duração muito curta, como pequenas ferramentas de linha de comando, cujo tempo de execução não dá ao JIT tempo para otimizar bem o código.
Agregando processos
Se você quer implementar algo semelhante a daemons em Java – processos que tratam continuamente determinados eventos, mensagens de rede etc., ou fornecem algum serviço – uma solução interessante seria definir uma arquitetura de maneira que se tenha executando apenas um desses processos executando. Nesse caso, vale mais a pena ter um processo consumindo 20 Mb para implementar cinco serviços , por exemplo, que ter cinco processos separados usando 12 Mb cada um. Essa “agregação” de processos pode custar algum esforço adicional, por exemplo, para possibilitar reinicialização/reconfiguração de serviços individuais. Mas economiza memória, talvez o bastante para resolver o seu problema. E se houver um número suficiente de processos, o consumo de memória inicial da JVM logo se dilui, e o uso de RAM fica bem próximo ao de processos nativos. Até mesmo serviços nativos costumam usar truque para economizar memória.o daemon ...
