A distribuidora de OODB, GemStone, está trabalhando na Ruby VM chamada "MagLev". O InfoQ conversou com Bob Walker, gerente do projeto MagLev para obter os detalhes por trás do projeto e com Avi Bryant que também está envolvido com o projeto. Nossa conversa foi primeiro Bob Walker.
InfoQ: Qual é o relacionamento entre Gemstone/S e MagLev em um nível de VM?
MagLev e Gemstone/S certamente compartilham muito código e capacidades, incluindo em nível de VM, mas eles são produtos distintos. Um número de bytecodes e algoritmos usados pela MagLev VM são específicos para Ruby. Contudo, isso mantém a habilidade de executar código Smalltalk.
InfoQ: Quantas pessoas estão trabalhando no projeto? Qual seu plano de tempo atual?
Há aproximadamente 8 pessoas que estão trabalhando no Maglev pelo menos parte do tempo. Eu realmente não posso discutir cronogramas nesse momento, mas teremos algo a dizer sobre isto na RailsConf.
InfoQ: O que está escrito na MagLev? Trata-se de 'Tartarugas todo o caminho a baixo?
Nossos objetivos são semelhantes a aqueles do projeto Rubinius: ter todos os métodos na biblioteca padrão implementados em Ruby, exceto alguns primitivos um pouco sensíveis a performance. A VM está escrita em C.
InfoQ: Vocês geram bytecodes para a VM ou como fazem Ruby chegar a VM?
Sim, nós produzimos bytecodes para a VM, o qual pode opcionalmente produzir código nativo para várias arquiteturas.
InfoQ: O que vocês usam para fazer parsing de Ruby? (O ruby_parser puro Ruby ou algo proprietário?)
Temos a habilidade de traduzir a partir de diversos parsers para uma representação interna a qual usamos para compilação. Ainda não decidimos com qual parser o produto final será lançado.
InfoQ: Vocês usam alguma coisa do projeto Rubinius (além do Ruby Spec?)
Eu usei os scripts e testes do Rubinius bm para coletar números de performance para as diversas implementações de Ruby. Eu também olhei a implementação MSpec, scripts e testes para ver qual poderia nos ajudar a garantir o nível de compatibilidade da API da MagLev com os padrões Ruby envolvidos. Dito isto, eu também estou examinando as mesmas partes em várias outras implementações de Ruby.
Esperamos eventualmente compartilhar o código da biblioteca padrão tanto quanto possível com Rubinius.
InfoQ: Que tipo de performance vocês tem como alvo para 1.0?
Estamos muito mais focados em escala do que em performance bruta. Apesar de acreditarmos que nossos resultados serão muito favoravelmente comparados com outras implementações, acreditamos que nossa escalável arquitetura de persistência será o diferencial mais interessante.
InfoQ: Qual é a história de threading para a MagLev? Threads nativas 1:1, um modelo m:n ou threads userspace simples?
Cada VM individual tem threads userspace simples. Contudo, múltiplas VMs podem ter acesso transacional concorrente para os mesmos objetos, então, você acaba com alguma coisa semelhante a um modelo m:n.
InfoQ: Considerando que vocês estarão na RailsConf, é seguro dizer que vocês tem como alvo compatibilidade com Rails? Ou alguma outra coisa primeiro (como Merb)?
Esta é uma pergunta muito interessante em que estamos colocando uma grande dose de pensamento. Definitivamente planejamos que MagLev seja capaz/compatível com Rails. Não é uma coisa simples de realizar, uma vez que existe um enorme número de potenciais (e verdadeiros) pontos positivos que sabemos que vamos executar ao longo do caminho. O caminho que vejo é que devemos estar capacitados a executar completamente Ruby antes de acolher Rails. Também estamos vendo as alternativas, e provavelmente seremos capazes de suportar qualquer coisa que esteja escrita em Rails. Priorizar o que fazer e em que ordem, depende, de um modo geral, do feedback e interesse que recebermos da Comunidade Ruby.
InfoQ: Vocês vão fazer ActiveRecord funcionar com o OODB ou os usuários vão querer ou ter que usar APIs especificas com MagLev?
Fazer ActiveRecord funcionar com o MagLev DB é um objetivo altamente desejável, embora existam partes da API ActiveRecord que assumam que o estado do objeto seja armazenado em um SQL baseado em RDB. Isso poderia ficar difícil. Em todo caso, qualquer API que tenhamos abaixo do ActiveRecord provavelmente estaria disponível para aqueles que não queiram usar ActiveRecord. Para mim, é realmente muito cedo para falar muito mais sobre esse assunto e espero que a comunidade nos deixe saber que tipo de abordagem mais benéficas eles encontrariam.
InfoQ: Vocês estão planejando existir na MagLev uma substituição drop-in comum para Ruby ou usarão algum tipo de deployment baseado em imagem ao estilo Smalltalk?
Será absolutamente possível para MagLev ser usada como uma substituição drop-in. Para aqueles que preferirem uma abordagem baseada em imagem, haverá suporte para isso, bem como, ninguém será forçado a usá-lo.
InfoQ: O código Ruby será capaz de persistir o processo para uma imagem a la Smalltalk?
Em breve, sim. Por exemplo, atualmente o produto GLASS nos permite salvar processos que encontramos erros para o repositório, e trazê-los mais tarde a um local da VM para debugging. Não há razões para que não pudéssemos fazer o mesmo com Ruby.
InfoQ: Vocês usarão um modelo de licenciamento semelhante aos seus produtos GLASS?
Estamos olhando diversos modelos diferentes. Eu posso dizer (mas não posso garantir) que faremos alguma coisa semelhante à MagLev.
InfoQ: Vocês ainda têm algo a dizer sobre ferramentas para MagLev? Vocês estão buscando suporte em IDEs Ruby como frontend (GUIs para depuração, etc)?
Bem, é claro que teremos um IRB shell, e um comando Ruby-like para executar código na MagLev. Gostaríamos de ver plugins para IDE, mas não podemos arriscar um palpite em quando ferramentas GUI podem se tornar uma realidade.
Gostaria de mencionar que o time da MagLev planeja conseguir apoio e suporte da comunidade Ruby, e nossa esperança é que membros da comunidade vejam alguma forte razão para contribuir para MagLev. Nossa competência essencial aqui na GemStone gira em torno de linguagens dinâmicas, máquinas virtuais escaláveis e persistência de objetos nativos da linguagem – há muitos outros lá fora e melhores nas ferramentas e UI’s, e nós adoraríamos apoiar seus esforços na MagLev.
InfoQ: Alguma chance de utilizar código Ruby na MagLev para interagir com código ou objetos Smalltalk?
A MagLev VM é, além de entender Ruby, perfeitamente capaz de entender Smalltalk. Eu diria que as chances de ser capaz de fazer isto são bastante elevadas, mas nós iríamos querer ver se estas funcionalidades desejáveis seriam úteis para a comunidade antes de ir muito longe nesse caminho.
Gemstone tem trabalhado com tecnologias Open Source há um tempo – por exemplo, fornecendo uma solução para a execução do framework web Seaside na Gemstone/S. Isto tem sido disponibilizado como GLASS - GemStone, Linux, Apache, Seaside, e Smalltalk. GLASS é gratuita com base de dados até 4 GB de tamanho, bem como outras licenças disponíveis.
Seaside é a criação de Avi Bryant um dos promotores da idéia de reutilizar VMs Smalltalk para Ruby (veja também seu artigo "Tartarugas todo o caminho a baixo" no mesmo tópico). Em uma entrevista em vídeo (em breve estará liberada aqui na InfoQ), Avi Brayant dá algumas informações sobre seu trabalho no Seaside e DabbleDB, bem como seu envolvimento com GemStone e MagLev. Avi disse sobre o projeto:
Eu tenho tentado influenciar os distribuidores de Smalltalk por anos a aplicar suas tecnologias e know-how no Ruby, e é muito emocionante ver isso finalmente acontecer. Estamos há menos de três meses na implementação da MagLev, mas estou extremamente motivado pelos resultados até aqui, e teremos algumas grandes demonstrações para apresentar na RailsConf. Estou com medo, eu não posso entrar em especificidades até então, assim venha ver nossa apresentação para saber mais.
Em um post recente em seu blog, Avi deu uma introdução sobre os benefícios dos OODBs como os Gemstone's pela comparação de suas soluções com as construídas em projetos Rails com memcachedb e tecnologias semelhantes:
uanto a Gemstone? Como acontece, a arquitetura é exatamente a mesma: há um único engine de armazenamento (chamado "stone"), um cache em memória em cada servidor (a "página de cache compartilhada"), e algum número de processos Smalltalk VM trabalhando ("gems"). Os gems capturam os pedidos e executam o código, e eles armazenam objetos na pagina de cache para velocidade e na stone para persistência. A diferença é, no Gemstone, estes foram todos projetados desde baixo para trabalhar em conjunto, tão rápido quanto possível e sem problemas.
Nota: este post em seu blog vai muito além em profundidade e dá um overview completo das diferentes abordagens e soluções.
GemStone apresentará muito mais detalhes sobre MagLev na RailsConf 2008 em Maio.