Compile as native image via GraalVM

elastic / elasticsearch

Free and Open Source, Distributed, RESTful Search Engine

https://www.elastic.co/products/elasticsearch

Other

1.22k stars 24.85k forks source link

Compile as native image via GraalVM #36983

Closed archenroot closed 5 years ago

archenroot commented 5 years ago

Describe the feature: I am interested in compilation into native image by using GraalVM, did anyone tried yet?

elasticmachine commented 5 years ago

Pinging @elastic/es-core-infra

original-brownbear commented 5 years ago

I don't think this is feasible (or will be feasible in the foreseeable future). If you look at https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md you can see a number of limitations with compiling Java to native using Graal that preclude compiling something as complex as ES (e.g. the incomplete reflection support, no finalizers will probably break Netty, no security manager would necessitate code changes and so on).

pauldraper commented 5 years ago

Unfortunate.:/

I was looking forward to being able to start ElasticSearch quickly for tests.

reitzig commented 4 years ago

preclude compiling something as complex as ES (e.g. the incomplete reflection support, no finalizers will probably break Netty, no security manager would necessitate code changes and so on)

With respect, the list you give seems to have little to do with "complexity". Use of reflection and finalizers is ... awkward in any circumstance, and often a smell.

Seems to me that especially complex, resource-hungry applications would profit from investing in native images. Of course, that endeavour may cause non-trivial refactorings.

Two4 commented 3 years ago

I don't think this is feasible (or will be feasible in the foreseeable future). If you look at https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md you can see a number of limitations with compiling Java to native using Graal that preclude compiling something as complex as ES (e.g. the incomplete reflection support, no finalizers will probably break Netty, no security manager would necessitate code changes and so on).

As the Helidon project demonstrates, Netty can work quite well with GraalVM, and a Graal image would be great for slimming down the frankly huge Docker image you guys publish, as well as allowing a switch back to Alpine as the base image. I also agree that heavy use of reflection and finalizers is indeed a code smell, especially since finalizers have been deprecated for quite some time (even as of 2018, when this issue was opened)

linghengqian commented 2 years ago

@archenroot

Can you point me to a possible form of submitting a PR in ElasticSearch's git? My understanding of GraalVM Native Image, it should look like the following in the Dockerfile.
```
FROM ghcr.io/graalvm/jdk:ol8-java17-22.2.0-b1 AS build
RUN gu install native-image
COPY app.jar /build/
RUN cd build && native-image --static -jar app.jar -H:Name=output
```

FROM scratch COPY --from=build /build/output /opt/output CMD ["/opt/output"]


- But I took a look at https://github.com/elastic/elasticsearch/blob/v8.4.1/distribution/src/bin/elasticsearch and https://github.com/elastic/elasticsearch/blob/v8.4.1/distribution/docker/src/docker/Dockerfile , I can't find a place where I can submit a PR to work on Graal Native Image.

sharkymcdongles commented 1 year ago

Graal and native support reflection now if you compile metadata at build time. I would suggest reopening and reexploring this with the new features 4 years later now.

@elasticmachine

stephanebastian commented 6 months ago

Could you please reopen this issue, as least to track the progress of supporting GraalVm native? As far as I now, most limitations of Graalvm in 2018 have been taking care-of. Therefore ES shouldn't be that far away from being available as a native image