opinali wrote:
Olá pessoal... o André Santi me chamou a atenção para este thread. Por sinal, é ótimo ver debates deste nível técnico por aqui; mesmo em sites de escopo mais global, 99% da turma só fala bobagem ou superficialidades sobre assuntos como GC.

(Claro que nesse cenário, salvo bug ou System.gc() explícito, o GC nem deveria acordar para começo de conversa.)

sobre a questão dos wrappers de tipos primitivos em collections. O Doug Lea é dos meus: sempre reclama que a plataforma Java dá um suporte de segunda classe a "tipos escalares"; mesmo com otimizações como o cache de wrappers do Java 5+ (que por sinal é limitado a uma estreita faixa de valores!), o custo dos wrappers, graças à collections "apagadas" onde após a compilação tudo acaba virando Object, é pavoroso. O Doug cita cenários de aplicações forkJoin que ficaram 16 vezes mais lentas (!), só devido ao overhead de wrappers como Integer, em comparação com uma versão usando classes especializadas nos tipos primitivos. Basicamente, a alocação desses wrappers estúpidos - mesmo com alocação e GC "quase grátis" - esculhamba com a eficiência dos caches e tb inúmeras otimizações do JIT, sendo que o efeito é ainda pior em arquiteturas multicore & SMP. E a otimização de Escape analysis, que espero estar mais avançada (com stack allocation) no Java 7, não resolve muita coisa... só serve para problemas triviais, como objetos Iterator usados em loops. Para problemas mais complexos, por exemplo um algoritmo que processa um int[] que em determinado momento tem que ser todo enfiado num Object[] de alguma collection, a tecnologia de escape analysis que existe hoje (mesmo em teoria) não dá pro gasto.

http://weblogs.java.net/blog/opinali/

saoj wrote:
Se vc baixar o openjdk e dar uma olhada no código do SelectorImpl e do EPollSelectorImpl vai ver que o primeiro leak iterator a cada interação e o segundo está explicitamente chamando new Integer(nextFD) também dentro do loop!!!

Uma observação que fiz aqui há alguns posts atrás é que como o loop do selector vai rodar algumas milhares de vezes, pode não demorar muito para termos bilhões de inteiros no cache, no caso de vc mudar para autoboxing e usar o pool de wrappers. Interessante essa sua observação de que esse pool é limitado. Um pool de 4 bilhões de inteiros provavelmente não seria legal...

E a questão de primitivos eu concordo com vc e com o Doug. Já que Java tem primitivos então ela poderia vir de fábrica com collections para primitivos. Aqui nós implementamos nossas próprias collections de primitivos. Parece que Jakarta Commons Collections tb tem algumas. Outra opção seria controlar vc mesmo o pool de Integers, mas para isso vc precisa de um integer mutátvel. Um int[] com tamanho 1 é basicamente isso.

Como falei antes tb, num ambiente single-threaded (NIO), essas estruturas de dados podem ser otimizadas ao extremo e sem qualquer sincronização. Um pool de objeto acaba virando uma simples LinkedList.

saoj wrote:
Vc é o Osvaldo Pinali ? Aquele que escreveu um artigo para a Java Magazine sobre as novas api concorrentes de Java ???

Cara, aquele artigo foi o mais impressionante que eu já li na minha vida, dada a qualidade técnica e a simplicidade com que vc descreveu e exemplificou um tema extremamente cabeludo.

Parabéns!!! Tenho aquela revista guardada até hoje...

Vc poderia aparecer mais vezes por aqui...

louds wrote:
Lazy sweeping não é difícil de se implementar, já que opera completamente com memória fora do alcance do mutator step. O problema é implementar compactação ou cópia de forma concorrente ou lazy, que é o motivo pelo qual essa etapa ser stop-the-world no HotSpot.

Marcio Duran wrote:

Daniel Quirino Oliveira wrote:


É desenvolvedor Java há 8 anos, trabalhando atualmente como analista de sistemas para a EDS do Brasil,já tendo participado de diversos projetos Java EE para o setor de transportes, financeiro, e-commerce e telecomunicações. Além disso é coordenador do GUJ ( www.guj.com.br ) e costuma compartilhar seus conhecimentos em seu blog ( http://nullability.org).

Bom, é isso.

[update]:

Duas coisas para se pensar:
- C++ não possui interfaces. Então seria C++ uma linguagem não-OO?
- Java é 100% OO. Seria possível fazer isso então:
int a = 2; int b = a.add(3); assertEquals(b, 5); ??

Bom o Daniel voltou ao assunto, e deu um exemplo de C++ em sua tese de JavaScript, tudo bem....
valeu a tentativa....

Ai vai a minha então sobre C++ e Java.

Algumas Linguagem (como C++)permitem que uma classe estenda mais do que uma classe.Essa capacidade é conhecida como "herança múltipla".A razão pela qual os criadores de java decidiram não permitir a herança múltipla é que pode acabar bagunçando o código.

Já ouviu falar no cenário conhecido como o "Diamante da Morte"

Em obserção peço que sinceramente,leia o Capítulo 2:Orientação a objetos.
kATHY SIERRA
BERT BATES

_rafael wrote:...

Marcio_Nogueira wrote:...