Java 8 e o fim do PermGen

Uia, Legal. Sabia disso não.
[=

Mto bom!!!

opa artigo muito bom mesmo.

No meu ver acho que a JVM poderia ser um pouco mais inteligente nesse gerenciamento de espaço, com o uso de alguns algoritmos.

A solução ideal (em ambientes de produção / missão crítica) poderia-se determinar um mínino + máximo como é feito hoje. Porém deveria haver uma porcentagem de acréscimo quando atingido o máximo. Atualmente quando se ultrapassa esse máximo, não só a aplicação sai do ar como em muitos casos é necessário reinicar todos os servidores sejam eles de aplicação JEE ou containers web.

Giulliano:

No meu ver acho que a JVM poderia ser um pouco mais inteligente nesse gerenciamento de espaço, com o uso de alguns algoritmos.

A solução ideal (em ambientes de produção / missão crítica) poderia-se determinar um mínino + máximo como é feito hoje. Porém deveria haver uma porcentagem de acréscimo quando atingido o máximo. Atualmente quando se ultrapassa esse máximo, não só a aplicação sai do ar como em muitos casos é necessário reinicar todos os servidores sejam eles de aplicação JEE ou containers web.

Hebert Coelho:

Giulliano:

No meu ver acho que a JVM poderia ser um pouco mais inteligente nesse gerenciamento de espaço, com o uso de alguns algoritmos.

A solução ideal (em ambientes de produção / missão crítica) poderia-se determinar um mínino + máximo como é feito hoje. Porém deveria haver uma porcentagem de acréscimo quando atingido o máximo. Atualmente quando se ultrapassa esse máximo, não só a aplicação sai do ar como em muitos casos é necessário reinicar todos os servidores sejam eles de aplicação JEE ou containers web.

Mas não vejo lógica em haver essa % máxima.
Se essa % máxima já está disponível, por que ñ utilizá-la?

Na nova implementação vai ter isso (mais ou menos). O espaço será aumentado conforme necessário, mas o usuário pode esbelecer um limite. E sempre é bom estabelecer este limite. Não é inteligente simplesmente explodir com a memoria da máquina.

ifbcqueiroz:

Saudações a todos!

Acredito que muitos já saibam que com o lançamento do JDK 8 a Oracle removeu o espaço de memória chamado de PermGem e substituiu por um novo conceito de gerenciamento chamado de Metaspace, que utiliza a memória nativa, parecido com o encontrados na Oracle JRockit e IBM JVM’s.

Eu já sabia desta noticia, mas agra lendo melhor os detalhes dicou claro que é tudo a mesma coisa. Na realidade é pior. Agora uma aplicação java pode consumir a máquina inteira sem nunca ninguem saber. A modificação foi apenas para poder fundir o hotspot com o JRokit e não para facilitar a nossa vida.É a Oracle fazendo 'arte"… no mau sentido. Vamos ver no que isso no mundo real. Logo para começar vai dar dor de cabeça para quem nunca usou outra jvm senão o hotspot e estava habituado ao OutOMemoryError

…the Metaspace will dynamically re-size depending of the application demand at runtime. Essa alteração será uma gerenciamento inteligente (por isso fiz meu primeiro comentário). Lógico que ele não pode acabar com a memória do meu servidor…mas se tem memória livre e minha aplicação precisa de memória…pq não usá-la em runtime…

Mal posso esperar! Demais!!!

Já fazia um tempo que haviam anunciado a fusão do Java da Sun com o jRockit. E o melhor é que o recurso está sendo incorporado no openJDK também.

O que não dá pra entender é quando vem alguém nos fóruns e postam fim do java, o java não evolui.

O Java está evoluindo e surpreendendo cada vez mais.

Cheguei a conclusão que Java é uma linguagem para programadores sérios.

paulo_1981:

O que não dá pra entender é quando vem alguém nos fóruns e postam fim do java, o java não evolui.

O Java está evoluindo e surpreendendo cada vez mais.

Cheguei a conclusão que Java é uma linguagem para programadores sérios.

A linguagem não sei como anda, mas que demorava pra evoluir demorava, vamos ver como a Oracle vai gerir daqui pra frente, pois essa primeira feature valendo que a Oracle pegou não conta, pois o pepino era realmente grande… O tempo e a relevância do Java 8 para o 9, nos ajudará a medir o qaunto a linguagem estará evoluindo com a Oracle.

Quanto à sua última afirmação, Java sempre foi e nunca deixará de ser uma linguagem para programadores sérios, só que está atrasada alguns anos em relação às outras como linguagem, já como plataforma, está uns bons anos na frente de todas, talvez só não de .NET.

Enfim, eu estou confiante em relação aos próximos passos da plataforma e da linguagem.

adriano_si:

Mas a alteração é JDK, ou seja, na plataforma.

A linguagem não sei como anda, mas que demorava pra evoluir demorava, vamos ver como a Oracle vai gerir daqui pra frente, pois essa primeira feature valendo que a Oracle pegou não conta, pois o pepino era realmente grande… O tempo e a relevância do Java 8 para o 9, nos ajudará a medir o qaunto a linguagem estará evoluindo com a Oracle.

Enfim, eu estou confiante em relação aos próximos passos da plataforma e da linguagem.

Por que só com o Java 9? A Oracle já lançou atualização da linguagem com o Java 7, que estava com o cronograma atrasado mais de 2 anos. E o Java 8 também está vindo com evolução na linguagem, inclusive muitas solicitadas há anos. Não precisa esperar pra ver que o Java acelerou, bastava ter acompanhado os builds de quando a Sun administrava o Java e de agora, é nítida a melhora. O problema é que o Java ficou tempo demais parado, então tem muita coisa pra evoluir ainda.

bom??? booomm?? como assim, bom?
isso não pode ser bom! isso pode muito bem ser olhado com incertezas!
quem garante que esse tipo de substituição não irá afetar a homogeneidade com versões anteriores!!! quer dizer que o que for feito em java 7 pode não rodar em java 8 ? vai ser compatível?

Victor Neves:

bom??? booomm?? como assim, bom?
isso não pode ser bom! isso pode muito bem ser olhado com incertezas!
quem garante que esse tipo de substituição não irá afetar a homogeneidade com versões anteriores!!! quer dizer que o que for feito em java 7 pode não rodar em java 8 ? vai ser compatível?

Putz sorry mas o java não M$ pelo menos neste critério … basta pegar a evolução da plataforma e ou jvm … disso acredito que estamos livres, uma vez que qualquer alteração da linguagem em si passe pelo JCP …ai vão dizer aqui : - Ahhh mais a oracle que manda lá e tal … o core da oracle não é o java , mas muitos sistemas e ou softwares da oracle hoje em dia tem cada vez mais java , ou seja, não é o core mas é interesse dela manter a linguagem atual e difundida cada vez mais …

Isso se chama “paranoia de programador bitolado”.

Também programo um pouco em .NET (C#) e digo: quando há uma versão nova do framework, é um verdadeiro caos mudar de versão. Eu mesmo tenho várias versões do Visual Studio aqui na minha máquina, uma para cada versão do framework, porque código perfeitamente bom que rodava em uma versão precisa de várias alterações para rodar na versão seguinte.
E em C++ o problema é um pouco minorado porque tentamos usar bibliotecas que nos blindam desses problemas de versões incompatíveis de bibliotecas do sistema operacional ou do compilador, mas mesmo assim temos um sistema grande aqui que foi desenvolvido com o VS 2005 e não será atualizado para o 2010 ou 2012 a menos que arranjemos orçamento para fazer o reteste completo, além de várias adaptações nos programas.

Entretanto, os programas em Java têm pouquíssimos problemas quando passamos de uma versão para outra do Java. Basta não usar classes do tipo “com.sun” ou outras classes não-documentadas ou que estão explicitamente marcadas para não serem usadas (por exemplo, muitas classes com.sun.misc estão documentadas mas na sua documentação indica-se que não devem ser usadas por programas de usuários.)

marcosalex:

adriano_si:

Mas a alteração é JDK, ou seja, na plataforma.

A linguagem não sei como anda, mas que demorava pra evoluir demorava, vamos ver como a Oracle vai gerir daqui pra frente, pois essa primeira feature valendo que a Oracle pegou não conta, pois o pepino era realmente grande… O tempo e a relevância do Java 8 para o 9, nos ajudará a medir o qaunto a linguagem estará evoluindo com a Oracle.

Enfim, eu estou confiante em relação aos próximos passos da plataforma e da linguagem.

Por que só com o Java 9? A Oracle já lançou atualização da linguagem com o Java 7, que estava com o cronograma atrasado mais de 2 anos. E o Java 8 também está vindo com evolução na linguagem, inclusive muitas solicitadas há anos. Não precisa esperar pra ver que o Java acelerou, bastava ter acompanhado os builds de quando a Sun administrava o Java e de agora, é nítida a melhora. O problema é que o Java ficou tempo demais parado, então tem muita coisa pra evoluir ainda.

Acho que só do Java 7 já ter saído já foi um senhor avanço e o 8 já estar a mostra? Realmente parece que o Java está sendo “acelerado”.

Victor Neves:

bom??? booomm?? como assim, bom?
isso não pode ser bom! isso pode muito bem ser olhado com incertezas!
quem garante que esse tipo de substituição não irá afetar a homogeneidade com versões anteriores!!! quer dizer que o que for feito em java 7 pode não rodar em java 8 ? vai ser compatível?

marcosalex:

adriano_si:

Mas a alteração é JDK, ou seja, na plataforma.

A linguagem não sei como anda, mas que demorava pra evoluir demorava, vamos ver como a Oracle vai gerir daqui pra frente, pois essa primeira feature valendo que a Oracle pegou não conta, pois o pepino era realmente grande… O tempo e a relevância do Java 8 para o 9, nos ajudará a medir o qaunto a linguagem estará evoluindo com a Oracle.

Enfim, eu estou confiante em relação aos próximos passos da plataforma e da linguagem.

Por que só com o Java 9? A Oracle já lançou atualização da linguagem com o Java 7, que estava com o cronograma atrasado mais de 2 anos. E o Java 8 também está vindo com evolução na linguagem, inclusive muitas solicitadas há anos. Não precisa esperar pra ver que o Java acelerou, bastava ter acompanhado os builds de quando a Sun administrava o Java e de agora, é nítida a melhora. O problema é que o Java ficou tempo demais parado, então tem muita coisa pra evoluir ainda.

O Java 7 e o 8 são na realidade o mesmo. Deveria ser 7.1 e 7.2. E isso sim mostra o atraso.
O Java 7 ainda foi iniciado quando era a Sun. O processo de compra e o desnorteamento da Oracle que não sabia o que estava comprando ( eles ahavam que tavam comprando o javaCard, mas na realidade estavam comprando o gerenciamento de uma comunidade ativa de milhões de pessoas) atrazou o processo. O JavaFX tb roubou recursos do java SE com a grande asneira que foi o java FX 1, o 2 promete arrazar a concorrencia ( o silverlight e o flash, … ops! perai, o HTML 5 tornou tudo isso obsoleto… )
Ou seja, as apostas erradas nos momentos errados. E é por isso que o java 9 irá medir o quanto realmente a Oracle sabe trabalhar com o java. Mas os sinais são claros desde já.
O Hotspot é a VM mais avançado do mundo , mesmo comparada com outras VM java e mesmo comparada com vm de outras linguagens. Logo, nem o JRokit ganha essa. Mas O JRockit é mais rápido em alguma coisas e é um produto comercial. A fusão dos dois é o seguinte : a comunidade fica com a mesma coisa , e tem que se adquar a alguns “quirks” do jrokit, a oracle unifica as duas máquinas, um só produto, duas licenças e pode continuar ganhando dinheiro como antes. Isto foi uma coisa que Sun não fazia. A sun só ganahava dinheiro com o javacard. o hotspot nunca foi “comercial”. Mas o bom é que a comunidade deve ganhar uma vm ligeiramente mais rápida. sobretudo em modo Servidor, que é onde interessa. Mas a Oracle continuou a tradição da Sun e apostou forte no desktop. O recente bug mostra que eles estão mudando o lado cliente tb e querem fazer ainda mais. Com as noticias do Java 8 já rodar no Raspberry Pi e demos o java rodando em ipad e android é uma questão de tempo que o java retome a promessa “write once, run anyhere” ,o java 9 vai realmente ser a prova dos 9.

Teoricamente tudo pode rodar em versões futuras, mas sempre alguma coisa dá problema. Um exemplo são os frameworks que você citou. E nas empresas sempre tem “aqueeeele” sistema legado que se atualizar o Java 1.4 dá pau.

Mas nesse caso é uma alteração no funcionamento interno da jvm, realmente não vejo como isso pode quebrar alguma coisa…

Minha impressão foi que teve uma considerável melhoria na performance na versão 8. Vamos ver nos próximos dias

Adelar:

Minha impressão foi que teve uma considerável melhoria na performance na versão 8. Vamos ver nos próximos dias :D

sergiotaborda:

marcosalex:

Por que só com o Java 9? A Oracle já lançou atualização da linguagem com o Java 7, que estava com o cronograma atrasado mais de 2 anos. E o Java 8 também está vindo com evolução na linguagem, inclusive muitas solicitadas há anos. Não precisa esperar pra ver que o Java acelerou, bastava ter acompanhado os builds de quando a Sun administrava o Java e de agora, é nítida a melhora. O problema é que o Java ficou tempo demais parado, então tem muita coisa pra evoluir ainda.

O Java 7 e o 8 são na realidade o mesmo. Deveria ser 7.1 e 7.2. E isso sim mostra o atraso.
O Java 7 ainda foi iniciado quando era a Sun. O processo de compra e o desnorteamento da Oracle que não sabia o que estava comprando ( eles ahavam que tavam comprando o javaCard, mas na realidade estavam comprando o gerenciamento de uma comunidade ativa de milhões de pessoas) atrazou o processo. O JavaFX tb roubou recursos do java SE com a grande asneira que foi o java FX 1, o 2 promete arrazar a concorrencia ( o silverlight e o flash, … ops! perai, o HTML 5 tornou tudo isso obsoleto… )

O Java 7 e 8 surgiram por causa do atraso da Sun. Depois de quase 3 anos atrasado tinha pouca coisa pronta, então a Oracle perguntou à comunidade se preferiam esperar ficar todos so recursos prontos pra lançar, ou lançar um Java 7 com alguns dos recursos e mais tarde o Java 8 com o restante. A comunidade preferiu o ‘plano B’ porque o JDK ficou muito tempo parado. O importante nessa parte é o ritmo de desenvolvimento do Java, que claramente acelerou.

Já o JavaFX foi aposta da Sun, não da Oracle. E a versão 2 foi uma mudança de redirecionamento da Oracle em não competir com o Flash e Silverlight (embora ainda possa ser usado pra isso), mas pra entrar nas aplicações desktop no lugar do Swing, e nesse ponto ele está se saindo melhor.

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.Bom saber.

Rodou com oq? JBoss? Tomcat? Qual DB?

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.Bom saber.

Rodou com oq? JBoss? Tomcat? Qual DB?
Por enquanto tive sucesso só com aplicações JSE mesmo. Tentei rodar o servidor de aplicação que mais utilizo (JBoss 6) mas existem algumas incompatibilidades. Talvez funcione com o JBoss 7. Tomcat, utilizo mas ainda não testei (Tomcat 7). Sobre os bancos, por enquanto foi somente MySQL… não acho que impacte a questão dos bancos, mas de qualquer forma. Estou curioso para ver qual será o impacto das mudanças em banco embutidos.

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.Bom saber.

Rodou com oq? JBoss? Tomcat? Qual DB?
Por enquanto tive sucesso só com aplicações JSE mesmo. Tentei rodar o servidor de aplicação que mais utilizo (JBoss 6) mas existem algumas incompatibilidades. Talvez funcione com o JBoss 7. Tomcat, utilizo mas ainda não testei (Tomcat 7). Sobre os bancos, por enquanto foi somente MySQL… não acho que impacte a questão dos bancos, mas de qualquer forma. Estou curioso para ver qual será o impacto das mudanças em banco embutidos.O banco é pela questão do driver jdbc. As vezes arreia! =D

Valeu pela info.

sergiotaborda:

ifbcqueiroz:

Saudações a todos!

Acredito que muitos já saibam que com o lançamento do JDK 8 a Oracle removeu o espaço de memória chamado de PermGem e substituiu por um novo conceito de gerenciamento chamado de Metaspace, que utiliza a memória nativa, parecido com o encontrados na Oracle JRockit e IBM JVM’s.

Eu já sabia desta noticia, mas agra lendo melhor os detalhes dicou claro que é tudo a mesma coisa. Na realidade é pior. Agora uma aplicação java pode consumir a máquina inteira sem nunca ninguem saber. A modificação foi apenas para poder fundir o hotspot com o JRokit e não para facilitar a nossa vida.É a Oracle fazendo 'arte"… no mau sentido. Vamos ver no que isso no mundo real. Logo para começar vai dar dor de cabeça para quem nunca usou outra jvm senão o hotspot e estava habituado ao OutOMemoryError

Não tem arte nenhuma no mau sentido. Eles precisam corrigir toda essa cagada que se extende por anos que deixa a jvm atrás das demais tecnologias de mercado. Esse conceito de “vm” caiu por terra a anos. O que existe hoje são compiladores inteligentes.

Hebert Coelho:

Adelar:

…

O banco é pela questão do driver jdbc. As vezes arreia! =D

Valeu pela info.

Um ponto do Java 5 nao e retrocompativel com 1.4, então não entendi esta paranoia que o 8 ou 9 pode não funcionar com 6 e 7, isto já é uma verdade, começou em X versão vc pode subir a JVM, mas não pode descer.

Quanto a não ter permgen é um alivio tremendo, quando trabalhei em um projeto com SOLR que tinha alguns indices na casa dos gigas, o permgen quebrava e só dava para descobrir em modo produção, é um efeito surpresinha que vai sumir ! acho isto ótimo.

Então sim estou muito feliz com todos os rumos que estamos tomando.

renatoelias:

Um ponto do Java 5 nao e retrocompativel com 1.4, então não entendi esta paranoia que o 8 ou 9 pode não funcionar com 6 e 7, isto já é uma verdade, começou em X versão vc pode subir a JVM, mas não pode descer.

De onde você tirou essa informação?

usa generics (1.5) e volta para 1.4

renatoelias:

http://en.wikipedia.org/wiki/Java_version_history#J2SE_1.4_.28February_6.2C_2002.29

usa generics (1.5) e volta para 1.4

Se você pegar coisa da versão nova e colocar na velha, não vai funcionar nunca… -_-’’

Fala sério né?

O x da questão é do 4 rodar na 5, da 5 na 6… e assim vai. Isso é o que não pode dar problema…

Tem previsão já de lançamento? :-o

Veja o cronograma de lançamento em:

http://openjdk.java.net/projects/jdk8/milestones

Previsto para 2013/09/09

Valeu, vou dar uma olhada… :shock:

Tem muita coisa que as outras linguagens possuem e o JAva tinha ficado pra trás, agora ele finalmente vem implementando e melhorando. Java 7 já avançou alguns pontos, agora o Java 8 vem com mais melhorias. E o roadmap do Java 9 promete muito.

Esse permgen é uma alternativa muito antiquada e já era hora de tirar. Boa parte do consumo excessivo de memória está aí. Os motores novos de javascript como o v8 fazem isso bem melhor que a jvm. Vai ser uma mudança muito boa e aguardada.

Estava olhando as notícias, vendo a palava PermGen, me chamou a atenção, pois a alguns dias atrás, uma aplicação funcionava em minha máquina, após passá-la para um colega, ocorreu erro ao executar, alegando que a memória PermGen havia sido esgotada, pesquisei o erro, e a solução que ofereciam deu certo, compilei o jar aumentando esta memória, com o comando java -jar -XX:MaxPermSize=256m mas confesso que não entendi o funcionamento esta memória, quando ela é utilizada e por que, sou certificado em java, e no livro que li, as diferenças mencionadas era heap e pilha, pelo que me lembre não havia citação desta memória, se puderem me esclarecer o por que ela existe?

Obrigado.

Essa área de memória (“Permanent Generation”) é característica da implementação da Sun da JVM, e é por isso que não entra na sua apostila de certificação, embora dê muita dor de cabeça na prática para quem roda application servers ou web containers como o Tomcat, Glassfish etc.

Como a Oracle, além de ter comprado a Sun, comprou uma empresa (BEA) que havia escrito uma JVM (JRockit) que não usa Permanent Generation, eles resolveram juntar progressivamente os produtos.

dudu795:

Estava olhando as notícias, vendo a palava PermGen, me chamou a atenção, pois a alguns dias atrás, uma aplicação funcionava em minha máquina, após passá-la para um colega, ocorreu erro ao executar, alegando que a memória PermGen havia sido esgotada, pesquisei o erro, e a solução que ofereciam deu certo, compilei o jar aumentando esta memória, com o comando java -jar -XX:MaxPermSize=256m mas confesso que não entendi o funcionamento esta memória, quando ela é utilizada e por que, sou certificado em java, e no livro que li, as diferenças mencionadas era heap e pilha, pelo que me lembre não havia citação desta memória, se puderem me esclarecer o por que ela existe?

Obrigado.

Permgen é uma memória que guarda objetos que estão referenciados no seu programa se não me engano em 3 níveis de geração. A geração mais nova é passível de ser coletada enquanto as mais profundas são objetos mais críticos para o funcionamento do programa. Alguns desses são reaproveitados, mas o programa fica gordo demais. Foi uma cagada que fizeram logo de início e está sendo corrigida.

Existe um parâmetro da VM que força o garbage colector na PermGen, cheguei a usá-lo em produção uma vez.

Só pra botar um pouco de lenha na fogueira, uma alteração na JDK pode mudar a forma como algumas otimizações de VM (Argumentos da VM) trabalham.

Quando se trabalha com a JVM rodando em todos os seus padrões, normalmente não há problemas de compatibilidade, mas o mesmo não é necessariamente uma verdade quando se passa argumentos para que a VM trabalhe de modo diferenciado do padrão.

Acredito e espero que essas mudanças causem pouco ou nenhum impacto.