[quote=saoj][quote]
Vocês ai precisam de alguém que saiba pelo menos ler direito a documentação da Sun. Só isso já seria um bom começo.
[/quote]
Obrigado, Louds, mas o pessoal aqui sabe ler sim. Quando eu falo as coisas eu geralmente coloco o link e o conteúdo. Como eu disse antes, o GC sempre PAUSA as threads, mas SE E APENAS SE houver coisas para limpar. Se não houver nenhum objeto para limpar então essa pausa é praticamente zero. Se vc achar que não é isso, por favor poste aonde na documentação está escrito que o GC introduz latência mesmo quando não há nada para ele limpar.[/quote]
Primeiro, na implementação do HotSpot uma minor collection sempre causa pausas e estas envolvem todas as threads. Eu mostrei a conta do tempo que leva para pausar todas threads, independente do trabalho feito pelo GC. Se o GC simplesmente pausar e logo em seguida resumir todas threads, isso leva 8millis num box com 4 cores linux - e não fica melhor se tiver mais 60. Esse praticamente zero seu são 8millis, que é 8x mais que a necessidade de 1milli de precisão que você tanto enfatizou.
Segundo, minor collections são implementadas usando um CopyCollector, cujo tempo de execução é um fator do número de objetos visíveis na partição ativa. Um CC não processa os objetos "mortos".
Terceiro, você falou antes "…ele só precisa PAUSAR as demais threads da aplicação SE e ONLY SE ele tiver alguma memória para liberar. Caso contrário isso é feito em paralelo". Tem alguns problemas aqui. Paralelo significa usar vários processadores ao mesmo tempo. Sim, isso é perfeitamente possível com os HotSpot; porém não significa que é possível realizar uma minor collection concorrente com a execução de código gerenciado. Paralelo e Concorrente significam duas coisas quando se fala de garbage collection, taí sua confusão, avisei que precisava aprender a ler a documentação. A opção -UseParNewGC não torna o GC concorrente para minor collections.
Quarto, é obvio que um GC não irá realizar uma coleta de lixo se não existe necessidade de liberar memória. Porém escrever um programa em Java que não aloca memória é quase impossível e sem razão. Ou seja, mesmo otimizando seu código ao máximo só está adiando o inevitavel.
Links? Bom, a documentação em lugar algum fala que que é possível fazer coleta concorrente do Eden Space*. Uma busca no google por "concurrent eden space" só retorna resultados relativos ao mature space. Hmm, tem um artigo muito legal do David Bacon sobre real time garbage collection, sobre o metronome, no qual eles conseguem uma latência de 6millisegundos em um ambiente com 1 processador e 50% de CPU em uso.
*Eden Space é o nome da geração mais nova do GC do Hot Spot, onde a maioria dos objetos novos são alocados.
Sérgio, porém para substanciar minhas palavras vou exemplificá-las com código. O código pode ser meu, mas não irá soar tão prepotente quanto seu autor. 
Vamos lá, quero provar que uma thread produzindo lixo atrapalha a vida de outras mesmo na presença de vários cores. Para isso vou deixar uma calculando a diferença entre duas chamadas de System.nanoTime(), que não é mais que alguns poucos micro-segundos; e vou deixar uma segunda thread alocando objetos adoidado. Claro que isso não acontece no mundo real, mas serve para acelerar o experimento e mostrar que o efeito existe mesmo com uma mortalidade de quase 100% - tornando a minor collection super rápida.
O código é o seguinte:
public class Driver {
public static void main(String[] args) throws Exception {
new Thread(new Runnable() {
public void run () {
while (true) { new Object(); }
}
}).start();
while(true) {
//new Object();
long a = System.nanoTime();
long b = (System.nanoTime() - a) / 1000l;
if (b > 900) //0.9 mili
System.out.println (b);
}
}
}
Ele vai imprimir no console o delta em micro segundos sempre que levar mais de 0.9milli entre duas chamadas System.nanoTime().
Executando o código em uma máquina com 4 cores, o que significa nenhum thread switch, vemos valores próximos de 10milli, apesar da maioria ficar na faixa do 1-4 milli. O que é compreensível já que não tem mais nada rodando e somente 2 threads precisam de sinalização. Bem abaixo daqueles 8millis que eu alardei, porém aqui temos o melhor cenário possível. Se rodarmos com -verbose:gc dá para ver que cada minor collection leva em média 0.5millis e o resto todo do tempo é o overhead de pausar/resumir todas threads.
Sérgio, essa é minha última resposta sobre o assunto, pois realmente parece que vocês precisam contratar um especialista no assunto e eu não quero dar consultoria de graça. 
