Qual o problema ? Poderia descrever vários… vamos para alguns:
ahhh , eu estava esquecendo… tem o problema da performance tambem 
OU vc acha que é “barato” simular o sistema de metodos dinamicos em uma linguagem estatica ?
[quote=chun]Qual o problema ? Poderia descrever vários… vamos para alguns:
ahhh , eu estava esquecendo… tem o problema da performance tambem
OU vc acha que é “barato” simular o sistema de metodos dinamicos em uma linguagem estatica ?[/quote]
que eu saiba o jit já resolveu esse problema que você se preocupou na primeira execução do programa. Além do mais, o ruby do java é mais rápido que o original.
Agora, seguinte, tudo que eu te posto posto também fontes. Você não me deu nem uma. Como pode passar credibilidade dessa maneira?
Sem falar que nossa conversa disvirtuou de open solaris para compiladores, execução de software ruby e python.
JIT não faz milagres…
A primeira previa com a clausula invoke_dynamic mostrou-se 25% mais rapido que os metodos tradicionais… e eu considero 25% a mais de velocidade algo paupavel.
E ser mais rapido que o original , no caso do ruby , nao eh grande coisa, afinal , todos sabem que a R.I. é uma droga.
Quanto a dirvirtuar , concordo, voltamos ao OpenSolaris…
Cade os 80% do codigo dele em java mesmo??
[quote=chun]JIT não faz milagres…
A primeira previa com a clausula invoke_dynamic mostrou-se 25% mais rapido que os metodos tradicionais… e eu considero 25% a mais de velocidade algo paupavel.
E ser mais rapido que o original , no caso do ruby , nao eh grande coisa, afinal , todos sabem que a R.I. é uma droga.
Quanto a dirvirtuar , concordo, voltamos ao OpenSolaris…
Cade os 80% do codigo dele em java mesmo??
[/quote]
faz milagre sim…
Pode até ser mais rápida, apesar de eu não ver nenhuma fonte postada que diga que ele mostrou-se 25% mais. Sem fontes não dá para ter credibilidade, além do mais, para linguagens de produção o fator desempenho não tem muita importância.
Sobre o opensolaris eu já te respondi logo acima, mas você não lê os artigos que eu te posto.
ok ok…
detalhe: Wikipedia para voce é fonte… eu chamaria de outra coisa
[quote=chun]ok ok…
detalhe: Wikipedia para voce é fonte… eu chamaria de outra coisa
[/quote]
No mestrado trabalhei com uma linguagem que chama Haskell, o compilador dela gera código C/C++ e depois compila esse código pra código nativo.
Funciona, mas o código gerado é bem menos eficiente do que um código nativo. Pra aplicações onde a produtividade do Haskell compensa e performance não é gargalo, está ok, mas se a meta é gerar código eficiente, é um ponto negativo.
Imagino que os compiladores pra JVM atuais sofram o mesmo problema.
Mas não consegui entender se o OpenSolaris consegue executar bytecodes diretamente do kernel como se fosse código nativo. Se for verdade, daria pra fazer device drivers em Java, sim. Pelo menos até onde eu entendo.
uma JVM dentro de um KERNEL de sistema operacional, da forma que JVM é concebida hoje , na minha opinião , é loucura e uma besteira tremenda…
O julio trata java como apenas um JIT da vida… existem milhares de outras implicações dentro de um device driver.
ps: o increvel é o cara realmente acreditar na wikipedia…
[quote=chun]uma JVM dentro de um KERNEL de sistema operacional, da forma que JVM é concebida hoje , na minha opinião , é loucura e uma besteira tremenda…
O julio trata java como apenas um JIT da vida… existem milhares de outras implicações dentro de um device driver.
ps: o increvel é o cara realmente acreditar na wikipedia…
[/quote]
De maneira alguma, e você novamente está distorcendo o que eu disse. Não existe mistério nenhum em um driver, que é somente um módulo( dll ou qualquer outro assembly do tipo com permissões extras no so) que é utilizado por um kernel. Essa vm é a mais simples de todas, e a menor delas, foi feita justamente pra isso.
Não existem milhares de implicações dentro de um driver, até porque eu trabalho com isso e sei como funciona.
Olha, esse livro é muito bom para aprender sobre.
http://www.xml.com/ldd/chapter/book/
Claro, até porque hoje a wiki está de igual pra igual com a britânica. Você está a mais de 5 anos desinformado.
[quote=marcosalex]No mestrado trabalhei com uma linguagem que chama Haskell, o compilador dela gera código C/C++ e depois compila esse código pra código nativo.
Funciona, mas o código gerado é bem menos eficiente do que um código nativo. Pra aplicações onde a produtividade do Haskell compensa e performance não é gargalo, está ok, mas se a meta é gerar código eficiente, é um ponto negativo.
Imagino que os compiladores pra JVM atuais sofram o mesmo problema.
Mas não consegui entender se o OpenSolaris consegue executar bytecodes diretamente do kernel como se fosse código nativo. Se for verdade, daria pra fazer device drivers em Java, sim. Pelo menos até onde eu entendo.
[/quote]
A squalk mapeia o kernel do open solaris. É como rodar uma aplicação java em qualquer máquina com vm, com a diferença que esta roda em uma vm de mais baixo nivel.
Detalhe é que essa idéia é tão boa, que a microsoft tem uma pesquisa chamada singularity, que é desenvolver um SO nesses moldes. É um microkernel com vm embarcada(CIL/C#). Nele, tudo(qualquer linguagem que seja compilada para CIL) pode ser executada, e inclusive os drivers podem ser desenvolvidos usando uma linguagem dessas qualquer.
Eu fico imaginando uma HEAP dentro de um espaço de kernel… ia ser algo bem interessante…
Quanto a sua empolgação referindo-se a microsoft… a mesma embarca em projetos mais do que furados a ANOS…
então ela considerar uma ideia fabulosa , não me causa empolgação nenhuma…
Repito , se fosse tão mágico , TODO MUNDO usaria , e o mundo inteiro estaria louco para implementar…
O problema é a tal “letrinha minuscula” no final…
ps: repito , Wikipedia como fonte confiavel de alguma coisa… tsc tsc… pergunte ao seu professor o que ele acha de vc colocar a wikipedia como FONTE de alguma coisa…
[quote=chun]Eu fico imaginando uma HEAP dentro de um espaço de kernel… ia ser algo bem interessante…
Quanto a sua empolgação referindo-se a microsoft… a mesma embarca em projetos mais do que furados a ANOS…
então ela considerar uma ideia fabulosa , não me causa empolgação nenhuma…
Repito , se fosse tão mágico , TODO MUNDO usaria , e o mundo inteiro estaria louco para implementar…
O problema é a tal “letrinha minuscula” no final…
ps: repito , Wikipedia como fonte confiavel de alguma coisa… tsc tsc… pergunte ao seu professor o que ele acha de vc sitar a wikipedia como FONTE de alguma coisa…
[/quote]
ok, mas dê uma lida no livro que eu postei acima, é muito bom.
[quote=juliocbq][quote=marcosalex]No mestrado trabalhei com uma linguagem que chama Haskell, o compilador dela gera código C/C++ e depois compila esse código pra código nativo.
Funciona, mas o código gerado é bem menos eficiente do que um código nativo. Pra aplicações onde a produtividade do Haskell compensa e performance não é gargalo, está ok, mas se a meta é gerar código eficiente, é um ponto negativo.
Imagino que os compiladores pra JVM atuais sofram o mesmo problema.
Mas não consegui entender se o OpenSolaris consegue executar bytecodes diretamente do kernel como se fosse código nativo. Se for verdade, daria pra fazer device drivers em Java, sim. Pelo menos até onde eu entendo.
[/quote]
A squalk mapeia o kernel do open solaris. É como rodar uma aplicação java em qualquer máquina com vm, com a diferença que esta roda em uma vm de mais baixo nivel.
Detalhe é que essa idéia é tão boa, que a microsoft tem uma pesquisa chamada singularity, que é desenvolver um SO nesses moldes. É um microkernel com vm embarcada(CIL/C#). Nele, tudo(qualquer linguagem que seja compilada para CIL) pode ser executada, e inclusive os drivers podem ser desenvolvidos usando uma linguagem dessas qualquer.
Interessante… valeu pela dica. 
Att.
Só uma coisa, stack ou heap, qulquer um é uma área de memória, e vai ser guardado na ram, não no kernel(que aliás, vai estar em outra área da ram também).
Detalhe , uma HEAP é algo bem mais singular que uma simples STACK… acho melhor voce não comparar as duas coisas.
Outra coisa , falei em “Espaco de Kernel” nao no “espaço do kernel” larga mão e lê direito.
[quote=chun]Detalhe , uma HEAP é algo bem mais singular que uma simples STACK… acho melhor voce não comparar as duas coisas.
Outra coisa , falei em “Espaco de Kernel” nao no “espaço do kernel” larga mão e lê direito.
[/quote]
sendo no ou de se entende pela mesmo coisa. Você pensava que a vm estaria na mesma área de memória que o kernel, o que não é verdade.
Pode comparar sim, as duas são simplesmente espaços reservados a guardar variáveis de programas(são estruturas de dados diferentes, mas possuem o mesmo intuito na arquitetura de um sistema operacional), com a diferença que uma stack no winxp tem espaço de 8mb, e é usada para guardar variáveis locais, enquanto uma heap guarda todas as instâncias.
http://wiki.answers.com/Q/What_is_difference_between_heap_memory_and_stack_memory
Olha, você pode não usar a wiki, mas pelo menos tente usar o google em suas pesquisas.
Uma HEAP é um simples espaço ? Hummmmm… ok entao.
O intuito da HEAP é servir de PILHA ? Hummmmmm… ok entao.
Só queria chamar atenção para duas coisas…
:arrow: chun, tenho a certeza que vc já viu como o bytecode funciona, e vc acha q o bytecode só pode ser revertido em Java? E para gerar um bytecode bom tem que gerar um código Java e depois compilar com a JVM? Ok, o JRuby pode fazer assim, eu no CajuScript fiz assim, mas estou mudando isto para usar o BCEL que só trás vantagens, até me custa a acreditar que o JRuby n gere o bytecode diretamente.
Por exemplo, um simples:
try {
System.out.println("try");
} catch (Exception e) {
System.out.println("catch");
System.out.println(e);
} finally {
System.out.println("finally");
}
O bytecode gerado por este bloco de código, poderá ser revertido apenas em Java!? Claro que não, que o bytecode n vai ter nada de Java, não dá para dizer que o bytecode é Java, bytecode é bytecode da JVM e nada de Java! Por isso não vejo por que a guerra ai, vc pega no bytecode deste try/catch e converte até num try/catch alá VB ou sei lá o que, que pouco tem no bytecode de sintaxe Java. Ou melhor não tem nada de sintaxe Java. Portanto uma vez em bytecode Java deixa de existir. A origem pode ter sido um código Java, como pode ter sido Scala, etc… dês que consiga converter a sintaxe de input num bytecode válido para a JVM. Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
:arrow: opensolaris já usei e gostei! pena o desenvolvimento ser lento e bugs demorarem para serem resolvidos como já tinha citado, mas é um sistema que teria muito futuro, até por que a barreira do hardware nem é tão grande assim, tem os drivers principais, até os drivers 3D, a meses instalei no notebook da minha empresa e funcionou tudo, até a webcam.
E para usar como um sistema de teste seria excelente. O opensolaris esta morrendo ou já esta com a morte garantida, mas o Solaris esta muito longe de estar morto, basta ver na área da banca, os sistemas da Reuters e por ai fora, e ter um sistema aberto para fazer testes e desenvolvimento é maravilhoso, pois só o ambiente de testes e desenvolvimento custa muito usando o Solaris e máquinas reais, com o opensolaris esta parte ficaria mais barata ainda podendo usar VMs. Ainda acho que haveria vantagens em ter o OpenSolaris vivo, mas para a Oracle é capaz de não ter vantagem.
Até para o desenvolvimento do Solaris, era bom ter uns cobaias onde poderiam lançar updates de testes que seria testados pelos usuários do OpenSolaris e depois ser portados para o Solaris com maior fiabilidade.
[quote=eduveks]Só queria chamar atenção para duas coisas…
:arrow: chun, tenho a certeza que vc já viu como o bytecode funciona, e vc acha q o bytecode só pode ser revertido em Java? E para gerar um bytecode bom tem que gerar um código Java e depois compilar com a JVM? Ok, o JRuby pode fazer assim, eu no CajuScript fiz assim, mas estou mudando isto para usar o BCEL que só trás vantagens, até me custa a acreditar que o JRuby n gere o bytecode diretamente.
Por exemplo, um simples:
try {
System.out.println("try");
} catch (Exception e) {
System.out.println("catch");
System.out.println(e);
} finally {
System.out.println("finally");
}
O bytecode gerado por este bloco de código, poderá ser revertido apenas em Java!? Claro que não, que o bytecode n vai ter nada de Java, não dá para dizer que o bytecode é Java, bytecode é bytecode da JVM e nada de Java! Por isso não vejo por que a guerra ai, vc pega no bytecode deste try/catch e converte até num try/catch alá VB ou sei lá o que, que pouco tem no bytecode de sintaxe Java. Ou melhor não tem nada de sintaxe Java. Portanto uma vez em bytecode Java deixa de existir. A origem pode ter sido um código Java, como pode ter sido Scala, etc… dês que consiga converter a sintaxe de input num bytecode válido para a JVM.
:arrow: opensolaris já usei e gostei! pena o desenvolvimento ser lento e bugs demorarem para serem resolvidos como já tinha citado, mas é um sistema que teria muito futuro, até por que a barreira do hardware nem é tão grande assim, tem os drivers principais, até os drivers 3D, e para usar como um sistema de teste seria excelente. O opensolaris esta morrendo ou já esta com a morte garantida, mas o Solaris esta muito longe de estar morto, basta ver na área da banca, os sistemas da Reuters e por ai fora, e ter um sistema aberto para fazer testes e desenvolvimento é maravilhoso, pois só o ambiente de testes e desenvolvimento custa muito usando o Solaris e máquinas reais, com o opensolaris esta parte ficaria mais barata ainda podendo usar VMs. Ainda acho que haveria vantagens em ter o OpenSolaris vivo, mas para a Oracle é capaz de não ter vantagem.
Até para o desenvolvimento do Solaris, era bom ter uns cobaias onde poderiam lançar updates de testes que seria testados pelos usuários do OpenSolaris e depois ser portados para o Solaris com maior fiabilidade.
[/quote]
E o que Bytecodes tem a ver com heap ? A JVM garante não só a execução de bytecodes, mas tambem um COMPORTAMENTE PADRAO… que deve ser seguido por qualquer COISA que um dia queira ser chamda de Java…
Logo… o comportamento deste “Driver” deve seguir o comportamento padrao de um JVM… resposta a thread identica , forma de isolamentos… e isso conta… vai impactar DIRETAMENTE na performance , e isso em um driver , é incocebivel em varios cenarios !
O PRECIOSO de JAVA está EXATAMENTE nisso… ele GARANTE o ambiente onde é executado… desde comportamente até mesmo “features”…
e isso REALMENTE é importante para WORE…
Opensolaris NUNCA teve futuro… nao apenas devido a essa quantidade de baboseiras descritas aqui… mas devido ao fato de ser um projeto FECHADO que foi ABERTO com a visao de eh OpenSource , entao tem futuro e é bom…
OpenSolaris nasceu morto.
Se a oracle for esperta , ela pelo menos libera os componentes dele sob GPL v2, assim podemos aproveitar o ZFS no kernel do linux como padrao.
Detalhe , fico imaginando esse teu driver 3d escrito em Java.
Essa mania de BALA DE PRATA que Fan Boys do java tem é algo que realmente irrita.