OpenJDK passa a ser a implementação de referência para o JavaSE 7

JavaGuru Membro desde: 04/06/2006 13:50:18 Mensagens: 223 Offline

juliocbq wrote:

marcosalex wrote:

juliocbq wrote:
Eu usei a jrockit e achei inviável para todo tipo de projeto que se pode imaginar. É simplesmente uma jvm que aloca ela mesma(completamente) na memória ram. Um netbeans rodando nela ocupa mais de 1Gb de memória.

A jvm convencional resolve de maneira muito mais equilibrada a grande maioria dos problemas. Esse produto na minha opinião é para inglês ver.

Por falar nisso quem mais daqui do forum fez experiência com a JRockit?

O jRockit não é pra rodar em sistemas standalone, é pra rodar em servidores. Eu mesmo nunca fiz testes, mas aqui no GUJ tem muita gente que postava ganhas consideráveis em desempenho com ele, principalmente se haviam várias conexões concorrentes, fora as ferramentas de monitoramento e gerenciamento da JVM que eram bem mais completas.

Mas nunca testei ele, no máximo fiz testes semelhante ao seu, usando na máquina pra desenvolvimento.

Pois é, isso eu imaginei mesmo. Tem que ser servidor muito robusto. Mas em termo de processamento sinceramente não existe ganho. Existe a redução do gargalo do coletor de lixo porque tudo já está alocado em memória(o que descarta praticamente a necessidade de um gc para gerenciar tempo de vida de objetos). Pra desktop não serve como solução.

O que torna a logica de uma aplicação standalone diferente de uma enterprise ? não vejo como diferenciar isso em nivel de negocio.

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3371 Offline

benflodin wrote:

juliocbq wrote:
Pois é, isso eu imaginei mesmo. Tem que ser servidor muito robusto. Mas em termo de processamento sinceramente não existe ganho. Existe a redução do gargalo do coletor de lixo porque tudo já está alocado em memória(o que descarta praticamente a necessidade de um gc para gerenciar tempo de vida de objetos). Pra desktop não serve como solução.

O que torna a logica de uma aplicação standalone diferente de uma enterprise ? não vejo como diferenciar isso em nivel de negocio.

Mas não é em nível de negócio, é na JVM. Não conheço o jRockit a fundo, mas um exemplo seria um algoritmo mais eficiente pra gerenciar concorrência ou um melhor escalonador de processos. Tem algumas implementações que são mais rápidas pra grandes volumes e mais lentas pra pequenas coisas. Por exemplo, um seria da ordem de n^8, outro seria de 2^n. Até uma certa quantidade de n, o segundo seria mais eficiente, mas a partir de um determinado valor, a diferença inverte.

Outro é em algoritmos de escalonamento, um pode prioriazar o primeiro processo, ou então o mais rápido ou o menor ou dividir igual por quantum de tempo, etc. Tudo isso pode influenciar em situações mais comuns no desktop ou outras mais comuns nos servidores.

Um outro exemplo, poderia ser no próprio just-in-time, que otimizaria o código utilizando melhor instruções próprias de servidores.

Só lembrando pra quem não sabe, o jRockit não foi criado pela Oracle, mas foi adquirido por ela, que continuou trabalhando na JVM.

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Offline

No caso ela é inviável para o mundo das aplicações de prateleira. Se você colocar o jdownloader para rodar na rockit, vai ver que ele vai consumir uns 250% (ou mais) memória. Pelo que eu entendi foi a maneira que eles encontraram para sanar o problema de latência do coletor de lixo. Aplicações para usuários comuns não podem consumir muita memória porque são utilizadas em larga escala( exemplo explorer: quantidade de instâncias executadas).

Para um servidor robusto acredito que seja uma ótima solução, já que a ferramenta rodou muito bem( netbeans e glassfish). Embora somente o netbeans alcançasse brincando 1.2 Gb de ram. Se eu tivesse executado o glassfish facilmente alcaçavam os 2Gb de ram da minha máquina.

Notícias, artigos e o maior fórum brasileiro sobre Java