Vamos lá a ver uma coisa, devo tar falando spranglish…
incovar System.gc() não dá garantia de chamada do CG. Pensemos que temos duas implementações de GC , A e B.
A acata a chamada a gc () como a da sun. B, não. simplesmente ignora.
Agora vc desenvolve um sistema usando a jvm com o cg A. Vc descobre que tem problemas de memoria /performance. Vc então decide chamar system.gc() e descobre que isso resolve o seu problema. Pronto, a sua aplicação está pronta.
Vc manda a aplicação para o cliente que usa uma jvm que corre um cg do tipo B. A sua aplicação continua apresentando o mesmo problema de performance que antes pois a chamada a .gc() não faz nada. A portabilidade da sua aplicação foi pró espaço.
Das duas uma : ou vc estabelece “esta aplicação só funciona na jvm com cg do tipo A” e deixa o cliente se virar para arranjar uma, ou
vc altera a sua aplicação para não precisar invocar o .gc().
É óbvio que .gc() estabelece uma dependencia da JVM. E , como se lembrarão, a jvm da sun não é a única do mundo.
Este cenário é ainda pior em ambiente embarcado. Aqui a chance de usar uma jvm sun é pequena e a chance de estar usando uma jvm tipo B é grande. No cenário embarcado é ainda mais importante a portabilidade e amarrar a performace ao tipo de GC usado por baixo dos panos não é bom. Claro que aqui tb vale a opção “aplicação homologada para o aparelho,X,Y,Z,…”
Existe um outro mundo, e tlv seja esse em que o vini e o julio vivem, em que uma aplicação é feita e otimizada para um certo ambiente. Isso é real e funciona. Até que o ambiente muda e começa tudo de novo. Isso não é mais profiling da aplicação, mas sim do stack inteiro. Isso é tudo muito bom, mas não é o espirito de uma app java. Se vc vive nesse mundo tlv outras plataformas sejam melhores. Java ainda não é para coisa realtime.
O ponto é o seguinte : vc pode informar o gc que agora seria uma boa hora para corre-lo ? sim. isso se chama educação.
A performance da sua aplicação pode depender de chamar ou não o gc ? Não. Isso é uma amarração perigosa. É como usar uma API que só funciona no windows. Deve ser feito ? Não. Pode ser feito ? Pode, mas a custo da aplicação não ser mais portável.
Se a aplicação não é mais portável não ha porque fazê-la em java. Use alguma plataforma nativa ao OS (.NET no windows, C++ no linux , Objetive-C no mac, etc…)
Ok, mesmo sabendo isso ainda prefere java devido a outras facilidades ? Ok. Mas não espere que a especificação da JVM mude para acomodar esse tipo de aplicação que vai contra o costume e os bons princípios da plataforma.
[size=9]
E só um adendo, não de pode dizer que a JVM delega o tratamento de threads para o OS. Não está especificado o que ela faz em relação a isso.
No windows e no linux e na jvm da sun até pode ser que seja assim, mas não podemos partir disse principio ( o que aliás não adiantaria de nada).
Em alguns OS (como no Palm) onde não ha thredas nativas nem processos, a jvm tem que usar green threads. A área de threads é uma das que menos garantias tem. Básicamente vc sabe que run() será chamado. Não sabe como,quando nem por quem.[/size]
