ViniGodoy wrote:

juliocbq wrote:É verdade. Não havia lido corretamente a documentação. Mas é meio estranho sugerir, não!? As vezes, nós precisamos.

Estranhíssimo. Mas a sun nunca abriu mão do direito único e exclusivo que a VM tem de controlar o gc.
Já foram feitos pedidos para criar comandos que suspendam o gc, ou que forcem sua execução, mas implementações disso sempre foram negadas.

A próxima versão de garbage collector vai trazer modificações importantes, que a princípio o tornará apto a aplicações de tempo real. Mesmo nessa versão, será impossível forçar o gc a fazer qualquer coisa. Se quiser ler mais sobre ela:
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase

Cannot guarantee hard real-time behavior

juliocbq wrote:Mesmo com o g1, não é garantida a performance, como java realtime system.

ViniGodoy wrote:

juliocbq wrote:É verdade. Não havia lido corretamente a documentação. Mas é meio estranho sugerir, não!? As vezes, nós precisamos.

Estranhíssimo. Mas a sun nunca abriu mão do direito único e exclusivo que a VM tem de controlar o gc.
Já foram feitos pedidos para criar comandos que suspendam o gc, ou que forcem sua execução, mas implementações disso sempre foram negadas.

sergiotaborda wrote:Se tiver problemas de memoria com java o problema está na sua aplicação , nas API que usa ou na pouca memoria ram disponivel.
mandar o GC correr, não vai alterar a qualidade destas 3 coisas....

sergiotaborda wrote:O que é estranho é o método gc existir, e não que a sua implementação seja opcional (lembrar que o java é uma especificação).

juliocbq wrote:o grande problema é que o gc não é inteligente, como postado no link anteriormente. http://developers.sun.com/learning/javaoneonline/j...n=TS-5419&yr=2008&track=javase


Se a sun permitisse o controle dele, pelo desenvolvedor, estaria aumentando o poder do java.

ViniGodoy wrote:
Não acho estranho que esse método exista. Aliás, também acho que deveria ser obrigatória a execução do gc(). Isso não torna o ambiente não gerenciado, de forma alguma. Ninguém está falando aqui em não ter um garbage collector, ou deletar objetos diretamente.

juliocbq wrote:... como postado no link anteriormente. http://developers.sun.com/learning/javaoneonline/j...n=TS-5419&yr=2008&track=javase

gomesrod wrote:

juliocbq wrote:... como postado no link anteriormente. http://developers.sun.com/learning/javaoneonline/j...n=TS-5419&yr=2008&track=javase

Desculpem interromper a discussão*, mas esse link tá quebrado... alguém sabe se tem um outro que funcione?


* Muito interessante por sinal.

sergiotaborda wrote:

ViniGodoy wrote:
Não acho estranho que esse método exista. Aliás, também acho que deveria ser obrigatória a execução do gc(). Isso não torna o ambiente não gerenciado, de forma alguma. Ninguém está falando aqui em não ter um garbage collector, ou deletar objetos diretamente.

Mas indirectamente estão dizendo que querem controlar quando ( e possivelmente como) o CG roda. Isso é mesmo que o CG
não ser mais independente da aplicação.

Veja,Iterator.remove tem implementação opcional. Isto significa que vc pode mandar deletar e não vai acontecer. Inesperado talvez
mas a especificação tem que ser assim para dar conta de Arrays.asList().iterator().remove() que não pode remover os itens já que o proxy é imutável. O mesmo acontece com o CG. Porque ele é isolado e vc não o pode comandar (pode sugerir, não comandar) ele tem muita mais flexibilidade. É quase que o principio de hollywood ("don't call us, we will call you") so que "don't call us, we know what to do better than you". O CG precisa ser isolado (ou seja, náo pode existir forma de o comandar)