JVM e máquinas mono e multi-processadas

“boone”:

Tem como saber qual é implementação de Threads (Green ou Native) na JVM 1.4 para Windows ?

Simples, quando voce tem um processador apenas, todas threads vão utilizar o mesmo processador, usando green threads a JVM evita o custo de um scheduler em kernel space, que é mais lento que um em user space.
Com mais de uma CPU usando Native threads o SO pode colocar qualquer thread para executar em processador que tenha ficado ocioso, com GT é muito dificil fazer isso sem colaboração do SO. A sun fez isso pro Solaris 9, implementando o modelo M:N de threading.

Implementações de green threads em java são boas até, dado q todo IO passa pela mão da JVM então usar um modelo assincrono passa a ser mais facil.

“boone”:

Sempre pensei que implementações nativas fossem mais rápidas do que emular isto, como é o caso das greens.

Se esta JVM implementa as 2 versões, qual o critério que ela usa para usar uma ou outra e como influenciar isto para o uso que se quer ?

Dentro da aplicação tem como saber que a máquina tem mais de um processador, para se não, avisar o usuário ou tomar alguma outra atitude ?
obrigado.

Na verdade não existe veredito final de qual modelo de threading é mais rápido, uma implementação 100% user-space (green) só é escalavel para um processador apenas, para java a performance é superior que nativo. Quando existem mais de uma CPU, a coisa complicada pacas, via de regra, se o teu SO não der suporte explicito a um modelo M:N, nativas apenas é a melhor opção.

Via de regra, a JVM usando Native Thread é mais performática e escalável que usando Green Thread, pois ela fica mais aderente á forma como o SO escalona e controla as Threads.

Pode aconter, devido á otimizações, em alguns raríssimos casos o inverso.

[]´s

Isso nao eh de todo verdade. Existem uma serie de aplicacoes que usar o sistema de Green Threads pode ser mais vantajoso. Pessoalmente, fiquei indignado com a retirada da opcao de green threads das JVM 1.4 em diante.
Realizei a algum tempo analise sobre os dois modelos para uma aplicacao de chat, e achei que o modelo Green THreads se comportava de maneira muito melhor que o sistema de threads nativos, principalmente em ambiente linux. Isso se deve em primeiro lugar ao fato do linux ter um sistema de thread um tanto ruim (isso esta mudando com os novos kernels, e o NPTL). E outro problema eh o uso de recursos, pois cada thread nativa tende a ter descritores dentro do kernel e outro descritor na propria JVM (pois tanto o kernel do SO como o java precisam conhecer as threads em questao), ocupando muitos recursos e memoria (uso da pilha, por exemplo). Em contrapartida, o uso do Green Threads implica na existencia do descritor do java somente, ja que todo o escalonamento eh feito na propria JVM.
Eh claro que desta forma nao existe aproveitamento de multiprocessamento, mas para aplicacoes puramente IO , como eh o caso de um chat, isso nao eh um problema serio.

“tanque”:

Eh claro que desta forma nao existe aproveitamento de multiprocessamento, mas para aplicacoes puramente IO , como eh o caso de um chat, isso nao eh um problema serio.

Em aplicações com muito IO voce não vai querer usar toneladas de threads e sim NIO com channels não-blocantes e multiplexação, é muito mais escalavel e performático.

Me preocupo com isto pois quero rodar minha aplicação e uma máquina multi-processada e não gostaria que a JVM fizesse uso das green threads, visto elas não enxergarem mais de uma CPU…

Eu quero Native…

Sim, uso de IO nao bloqueante tende ser a mais performatico nesse tipo de aplicacao. Bem, o green thread eh exatamente isso, heheeh. O green thread, por implementar um escalonador proprio, era obrigado a traduzir todas as chamadas de IO do SO para modo nao bloqueante, senao ele nao atingiria seus objetivos (simular multithread). Se o green nao usasse io nao bloquante, no primeiro accept ou read que desse num socket, o SO jogaria o processo na fila de dormentes e soh iria voltar com a chegada do pacote de dados.

Era isso que eu adorava no green thread, voce via threads, mas por baixo era tudo feito por IO nao bloqueante.

Nao ha duvidas, que usar esses recursos diretamente eh extremamente poderoso (via java.nio). A biblioteca eh muito promissora e nao a duvida que um programa de CHAT teria muitos beneficios com o seu uso. Basta citar que o sistema de IRC, que muitos conhecem usa esse conceito, de io nao bloqueante e selects para monitorar os sockets.

Complementando um pouco o assunto, ouvi comentarios que a JVM JRockit, agora de propriedade da BEA, permite configurar quantas threads do SO voce quer utilizar, com isso e possivel startar a mesma quantidade de threads do SO quantas forem as CPU existentes. As demais threads serao entao escalonadas usando um sistema equivalente ao green thread em cima dessas threads da CPU. A vantagem disso eh menos carga ao SO, menos troca de contexto, visto que as threads do java nunca saem da CPU, a troca de contexto fica sendo feita em proprio espaco de usuario, sem recorrer a rotinas do SO. Afinal , eh isso que eu desejo de SO: que ele nao rode, que quem rode seja a minha aplicacao.

Atualmente, as JVM 1.4.X distribuidas pela JavaSoft, são todas Native Threads.

[]´s

Mas configuramos a quantidade de threads de acordo com a quantidade de processadores em uma máquinas… Exemplo:

Imaginemos um RedHat rodando com Jrockit e 16 processadores… a quantidade de threads será de no máximo 16

o mesmo para uma máquina virtual baseado em sun java com 16 processadores… ?

Como é o gerenciamento e a configuração da quantidade de threads… ?

Olá

gustcol:

Mas configuramos a quantidade de threads de acordo com a quantidade de processadores em uma máquinas… Exemplo:

Imaginemos um RedHat rodando com Jrockit e 16 processadores… a quantidade de threads será de no máximo 16

o mesmo para uma máquina virtual baseado em sun java com 16 processadores… ?

Como é o gerenciamento e a configuração da quantidade de threads… ?

1. O número de threads não tem nada a ver com o número de processadores. Um programinha bobo pode usar mais de 100 threads em uma máquina mono processada. Mesmo que só existam threads nativas, o programa pode usar muito mais threads que simplesmente ficarão em wait. Os antigos sistemas operacionais chamados de time sharing só usavam uma CPU. Cada aplicação tinha uma fatia da CPU por uma fração do tempo mas a impressão era a de que vários programas rodavam ao mesmo tempo. O mesmo se passam com as threads nativas ou greens. A diferença entre nativas ou greens está apenas entre quem controla as threads se é no nível baixo do S.O. ou na linguagem de alto nível.

2. Há casos em que se podem avisar ao programa para usar determinado número de processadores da CPU como por exemplo no Java da IBM no AIX. Mas lembre-se que a memória é uma só e que nem tudo pode ser paralelizado. Repito: este conceito não tem nada a ver com o conceito de threads. Aliás vou mais longe: mesmo que você estivesse falando em fork de processos como no caso do Apache, não precisaria de vários processadores para funcionar.

[]s
Luca

Instalando uma JVM da SUN em uma máquina com mais de 1 processador, essa VM vai utilizar toda a capacidade de processamento da máquina por padrão ou não? Tenho que iniciar VM com algum parâmetro a mais? Depende do S.O.? Estou falando de processamento e não de memória.