http://www.freebsdfoundation.org/press/20030825-java131.shtm
Legal pra quem usa o :twisted:
Corrijam-me se eu estiver errado, mas a Blackdown cria VMs para BSD também, não?
Pelo que eu vi no site não, pois logo no titulo ja esta escrito “Java Linux” :o
[]s
Se não me engano os binários compilados em Linux rodam no FreeBSD sem muitas dores de cabeça. Além disso, neste artigo (http://www.volano.com/report/index.html) a VM da Blackdown é usada em, tada!!, um FreeBSD :twisted: .
Binarios do Linux podem ser usados em FreeBSD numa boa, usando uma camada de compatibilidade. Mas, como acontece com toda camada dessas, a performance e consumo de memoria nunca sao iguais ao que se conseguiria com um binario nativo 
Mesmo não sendo um grande fã de BSD, o pessoal do FreeBSD mandou muuito no suporte a binarios linux.
De fato, quase não existe emulação, somente suporte as diferenças dos binarios e o pouco que existe é para suportar API`s únicas ao linux ou funções que são implementadas diferentes entre os 2 SO’s. Ou seja, a diferença entre usar o mesmo programa compilado para FreeBSD e Linux é negligenciavel.
O porem de usar FreeBSD seria perder todas vantagens que o linux oferece sobre ele.
A Sun se comprometeu a também suportar java nessa plataforma um pouco depois que a MS anunciou que estava terminando de portar o .net para ela.
Primeiro gostaria de salientar que o suporte a java do FreeBSD nao eh nenhuma novidade, a algum tempo existem programadores fazendo o port e o que mudou foi um reconhecimento da SUN que esse porte existe .
O problema eh que os ports , com algumas excessoes, se baseiam no codigo de referencia da SUN, tanto da blackdown quanto o do freebsd, que nao possui licensa GNU ou BSD, e sim uma licensa da SUN que nao eh totalmente opensource, tem uma serie de restricoes. Para se ter ideia, os binarios gerados por esses codigos nao podem ser disponibilizados sem o aval da sun.
Foi exatamente isso que mudou, agora a freebsdfoundation pode disponibilizar esses binarios para a comunidade. Antes era necessario compilar do zero, agora basta baixar o pacote e instalar.
Ocorreu tambem uma discussao sobre a viabilidade de usar JVM’s maquinas do linux no FreeBSD. Funciona e funciona muito bem. A camada de compatibilidade que existe nao onera praticamente nada no sistema operacional, sendo a performance, na teoria, identica a de rodar num ambiente linux. Na verdade, nos quisitos em que o freebsd eh melhor, as aplicacoes, mesmo que sejam em binarios linux, tendem a rodar melhor no FreeBSD que no proprio linux. Nao vou ficar aqui citando no que o FreeBSD eh melhor que o linux ou o contrario para nao gerar flames, e espero que os leitores desse forum tambem nao o facam. Se quiserem ver no que um eh melhor que outro procurem listas de discussoes apropriadas.
Mas vou citar um ponto ambos pecam, atualmente. THREADS. O suporte a thread de ambos os sistemas eh patetico.
Ambos estao melhorando. A serie 5.x do FreeBSD esta intrudizindo uma tecnologia de Kernel Schedule Entities, e o linux esta introduzindo a NPTL para melhorar esse quisito.
Soh para se ter ideia, hoje cada thread java no linux ocupa uma entrada na tabela de processos. Num programinha, que vai abrir , digamos, mais de 1000 threads, vai encontrar muito problema, pois o numero maximo de processos padrao de muitas distribuicoes eh 1024 (pode ser alterada recompilando o kernel), isso demonsta a imaturidade do codigo de thread do linux. Ja com o NPTL, do kernel 2.6.x cada programa java ocupara somente uma entrada na tabela de processos.
tanque, preciso ai te corrigir em vários aspectos quanto a threading no linux.
Primeiro, o linux não possui limite hardcoded no número de processos, esse limite é definido pelo volume de memoria disponível no sistema; com kernel da séria 2.4 o número de processos é limitado para metade de (memoria_total / tamanho do struct proc), oque resulta em dezenas de milhares de processos em uma máquina com 2 gigas de ram (aqui em casa, com 512 eu consigo criar mais de 1000 thread simultaneas com sucesso)
Segundo, é a confusão que existe sobre o fato de cada thread ocupar 1 entrada na tabela de processos. Na 2.4 ocorre que o kernel trata cada thread como um processo, ou quase, pq leva em conta que cada uma pertencem a um processo na hora de realizar o escalonamento.
O grande problema que todos vem é pelo fato das ferramentas comuns listarem as várias threads como sendo processos distintos, isso é, na verdade, um desleixo dos desenvolvedores que, ate então, não tinham se preocupado em agrupar as threads logicamente por processo na hora de exportar para userland esse tipo de informação.
Oque ocorre dentro do kernel é um pouco mais complexo, dado que a distinção real entre processos e threads é somente a separação da VMA que existem entre processos.
Ahh, provavelmente vc tirou a informação do limite de processos existente do linux pq ele existia em versões anteriores dele. Acho que ate a 2.2 ele ainda existia, se não tou enganado.
Realmente nao queria levandar esse tipo de discussao, loud. Realmente desconheco se o tamanho da tabela de processos eh dinamico (ou dependente de memoria) ou nao no linux da serie 2.4. Isso nao vem ao caso. O fato de ter uma tabela grande de processos dificulta o trabalho ate para o kernel, eh uma lista muito grande para o escalonador percorrer. O ideal seria realmente um escalonador em dois estagios, o primeiro escolhe processo, e o segundo escolhe a thread desse processo.
A sua argumentacao sobre ferramentas comuns faz sentido. Mas acho um absurdo ter que reescrever o ps para “agrupar” processos que sao na verdade thread iria deixar o ps mais lento que ele ja eh. E essa nao eh a funcao do ps tb, ele nao foi feito para mostrar threads. Devo ressaltar que o ps (uma ferramenta da GNU, no caso das maiorias das distribuicoes linux) eh compartilhado por outros sistemas unix tambem, como por exemplo o HURD. Seria injusto “reescrever” o ps por uma peculiaridade do linux, sendo que o ps da GNU tende a ser usado por uma gama maior de unix’es
E tem outra. Se as threads do linux fossem tao boas , eles nao estariam mudando para NPTL. Estou usando o NPTL num RedHat 9 e realmente parece muito bom.
Quando eu me referia a ser desleixo dos desenvolvedores, me referia aos do kernel.
Nenhum algoritmo de escalonamento real precisa percorrer todos processos para escolher, quando muito, são alguns poucos. No 2.6, por sinal, o número de processos que precisam ser analisados pelo escalonador independe do total, seja ele 10, 100 ou 50.000…
Sem falar que a maioria dos SOs fazem os escalonadores enxergar as threads sendo parecidades como processos por uma questão de simplicidade, oque muda é que o uso e a disponibilidade de cpu, das threads é contabilizado por processo. Isso ocorre em windows, linux, solaris, aix, etc…
Como eu tinha falado, no linux, por folga do pessoal do kernel, as threads são vistas como sendo simplesmente processo.