Taverna /dev/All

GraalVM - realmente vale à pena?

image

Ano passado a Oracle lançou o projeto GraalVM: a ideia consiste em aumentar o desempenho (principalmente o de inicialização pelo que pude ver) de aplicações escritas em diversas outras plataformas, tais como Node, Java, Python, Ruby, R (e outras) a partir da disponibilização de uma VM, similar à ideia que temos no Java com sua JVM.

Dentre as promessas pelo que pude ver está inclusive a redução do consumo de memória. Vou começar algumas experiências com esta tecnologia (o que com certeza gerará artigos para a Revista do /dev/All), porém, em paralelo, gostaria de saber das experiências de vocês.

Alguém aqui já experimentou? O que acharam? Valeu à pena? Cumpriu o que prometeu mesmo?

Aos interessados, segue o link para o projeto: https://www.graalvm.org/

1 Curtida

Eu usei na minha ide e não vi nenhuma diferença .
Mais tem um palestra do Elder Moraes sobre isso :

pode ser que ajude a entender melhor para quem não conhece .

1 Curtida

uma bela apresentação, valeu!

Pra mim os grandes ganhos são comunicação nativa com o SO e a quantidade de linguagens que suporta.

mas você já experimentou estes ganhos?

Sim, fiz testes utilizando um programinha para leitura de XML’s! No meu programinha o tempo de inicialização foi menor (não que ele demorasse para iniciar) e o consumo de memória também, mas nada absurdo.

Acredito que pra contextos em que qualquer tempo que se ganhe é importante irá valer a pena, só acho que ainda não está pronto para produção.

1 Curtida

O tópico é bem antigo, mas, como o assunto anda em relevância no momento, acho pertinente lançar o poder da fênix aqui :slight_smile:

O lance da GraalVM é basicamente o tipo do seu workload. Workloads curtos são uma ótima pedida pra usar a GraalVM, como FaaS. Aplicações “tradicionais”, que tem tempo de vida determinado somente pelo tempo antes de falharem, vão se beneficiar da JVM tradicional. Basicamente o Garbage Collector da JVM consegue se sair melhor no longo prazo.

O interessante foi que, em cima da GraalVM, houve um esforço muito legal pra criar um framework que tira proveito disso: o Quarkus. Ele consegue lidar com o trabalho super massivo e tedioso que é configurar a GraalVM e ainda coloca mais algumas cerejas no bolo que podem ser usadas com a JVM também.

Onde se tira muito proveito da GraalVM é em escalabilidade pra nuvem, já que você vai ter containers com footprint e bootstrap muito menores, o que irá fazer sua app escalar assustadoramente mais rápido. O preço que você vai pagar por isso é na compilação: compilar com a GraalVM é assustadoramente demorado e consome muitos recursos, então você precisa preparar uma estrutura pra builds.

O problema vem quando você faz muitos builds, mas escala pouco a aplicação: ter vários builds e poucos containers te darão mais dores de cabeça do que se você tiver poucos builds e muitos containers (mais um motivo pro workload curto se encaixar melhor na GraalVM).

Atualmente eu não faço mais nada que não esteja com Quarkus, e em alguns casos uso a GraalVM (principalmente em ferramentas de linha de comando, como um gerador de payload que eu fiz ano passado). O fato da GraalVM não aceitar muita “magia negra” (aka: Reflection) te faz precisar de ahead of time compilation, deixando estruturas caras já prontas no início da aplicação (como a resolução das dependências do CDI, por exemplo). O Quarkus já faz isso com um monte de frameworks, mesmo se você usar a JVM. Caso opte pela GraalVM, o Quarkus também pode serializar um bloco estático de processamento e deserializar ele no início da aplicação, dando um fôlego extra de desempenho (mais um motivo do processo de compilação ser mais demorado).

Bom, é um tema super interessante e que depois de muito tempo apanhando com os prós e contras eu uso a seguinte regra:

  • Workload de curta duração: GraalVM
  • Workload de longa duração: JVM

Até agora tá dando super certo :smiley:

1 Curtida

Do caralho!

E o consumo de memória, como fica? O que tem observado @ataxexe ?

No início é até assustador. Um código que consumia em torno de 200MB foi pra 60MB com Quarkus na GraalVM e ficava em uns 100MB na JVM.

O lance é que depois de um tempo, a GraalVM se equiparava a JVM em consumo de memória. Não cheguei a contar o tempo exatamente, mas era coisa de meia hora mais ou menos.

O que me pegou em cheio foi a compilação, com 4 CPUs e 8GB de RAM alocados, o processo chegava a levar 8 minutos. É possível você trabalhar com a JVM local e usar a GraalVM nos outros ambientes, mas como você precisa fazer algumas configurações pra GraalVM e algumas coisas podem também não funcionar, você chega em pontos onde rodava local mas no teste não funciona… de volta ao “funciona na minha máquina”.

Meu único ponto com Quarkus é que se não me engano ele só funciona com no max java 11 deixando você preso em versões X do java e com as limitações que você falou sobre features avançadas.

Saiu o beta do spring native

Tenho bastante expectativa neste projeto.

também to bem animado com este projeto aí

Entendo perfeitamente seu ponto. Vendo pelo lado que estou sentado, consigo entender o motivo do time do Quarkus estar “preso” ao Java 11: LTS (Long Term Support). É um pouco complicado suportar toda a cadeira de releases não-LTS do Java, que tem uma vida curta demais pra justificar o suporte. Sem contar que o Quarkus foi criado pela Red Hat, então é mais natural ter o foco em suporte do Java pra versões LTS, que estão alinhadas com o suporte da Red Hat.

A versão 11 do Java é a mais recente que tem o LTS. A próxima vai ser a 17 e deve chegar ainda neste ano e muito provavelmente vai ser suportada pelo Quarkus:

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

itexto