Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native Minecraft servers with GraalVM Native Image

github.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Native Minecraft servers with GraalVM Native Image

#71

Post by doikor »

solarkraft wrote: post #25
fniephaus wrote: post #13

Earlier quoted context omitted.

Disclaimer: I work on the GraalVM team. The students "measured noticeable reductions in terms of memory footprint of up to 43%" [1] in some preliminary experiments. More from the accompanying blog post: "We also hope that the Minecraft community builds on our work and helps benchmark different configurations for native Minecraft servers in more detail and in larger settings." Please feel free to share any numbers on…

Why is this? I thought the JVM already did somewhat decent JIT compilation ... If I understand the article correctly, you're preempting all possibly unoptimized/expensive code paths (reflection) by attempting to literally execute all of them? While it's a cool experiment, isn't it a bit error-prone (besides being a lot of effort of course, but playing Minecraft on the side does sound pretty fun!)?

GraalVM does have a better optimizer in certain conditions than C2 in vanilla JDK which can can lead to better performance. Basically the only way to know if GraalVM will give you better performance or not is to try it and/or run benchmark your code.

https://www.graalvm.org/22.2/examples/java-performance-examp...

Re: Native Minecraft servers with GraalVM Native Image

#72

Post by xendo »

pwagland wrote: post #51
fniephaus wrote: post #13

Earlier quoted context omitted.

Disclaimer: I work on the GraalVM team. The students "measured noticeable reductions in terms of memory footprint of up to 43%" [1] in some preliminary experiments. More from the accompanying blog post: "We also hope that the Minecraft community builds on our work and helps benchmark different configurations for native Minecraft servers in more detail and in larger settings." Please feel free to share any numbers on…

Note that the memory usage _could_ potentially be significantly improved for the JVM by just using an alternative allocator, such as jemalloc. In our system, we saw, in some instances, native memory usage decrease by about 60%, and it also resolved a slow "leak" that we saw, since glibc was allocating memory, and not returning it to the OS. In our case it was because we were opening a lot of class loaders, and hence…

I can second what you wrote about jemalloc. Some internal services at Amazon are using it with solid outcomes. I also recommend trying out 5.3.0 version released earlier this year.

Re: Native Minecraft servers with GraalVM Native Image

#73

Post by xendo »

bitcharmer wrote: post #56
pwagland wrote: post #51

Earlier quoted context omitted.

Note that the memory usage _could_ potentially be significantly improved for the JVM by just using an alternative allocator, such as jemalloc. In our system, we saw, in some instances, native memory usage decrease by about 60%, and it also resolved a slow "leak" that we saw, since glibc was allocating memory, and not returning it to the OS. In our case it was because we were opening a lot of class loaders, and hence…

This is very interesting. Could you share more details on this particular issue in glibc? Jar files get mapped so I'm really interested where glibc failed to release memory.

No the OP, but we had similar issue — our service was leaking when allocating native memory using JNI. We onboarded Jemalloc as it has better debugging capabilities, but the leak dissapeared and performance improved. We never got around to root causing original leak.

Re: Native Minecraft servers with GraalVM Native Image

#74

Post by spapas82 »

nomercy400 wrote: post #65
spapas82 wrote: post #59

I've always had some questions about graalvm so I'd like to hijack this thread, forgive the out of topic comment please! I've got a number is spring web applications from which I create an uberjar (jar file with all dependencies) and run them in a Centos server using something like java -jar server.jar (it's a little more complex than this but you get the idea). Would I be able to use graalvm to create native binarie…

Spring Boot 3 is expected to support native/graal. There is a milestone release I think. There is a Graal Community Edition, which is free. Search for graal and spring pet clinic demo, you will likely find an article reducing startup time 100x (starting pet clinic in 15ms), and reducing memory 2-3x. I don't know about 'faster', but in my experience most spring applications are RAM bound, not CPU bound. So the native…

Startup time is the major problem I have with spring, it can be ~ 1 minute in some apps. I'll definitely check Quarkus thank ypu!

Re: Native Minecraft servers with GraalVM Native Image

#75

Post by spapas82 »

fesc wrote: post #60
spapas82 wrote: post #59

I've always had some questions about graalvm so I'd like to hijack this thread, forgive the out of topic comment please! I've got a number is spring web applications from which I create an uberjar (jar file with all dependencies) and run them in a Centos server using something like java -jar server.jar (it's a little more complex than this but you get the idea). Would I be able to use graalvm to create native binarie…

I think right now this Isn’t possible with “normal” Spring because Spring and various other libraries you’ll normally use make heavy use of reflection. Frameworks like Quarkus and Micronaut have been written with native in mind and I think Spring is also working on it (Spring Native).

Thank you for the suggestions I'll take a peek at them!

Re: Native Minecraft servers with GraalVM Native Image

#76

Post by spapas82 »

kaba0 wrote: post #61
spapas82 wrote: post #59

I've always had some questions about graalvm so I'd like to hijack this thread, forgive the out of topic comment please! I've got a number is spring web applications from which I create an uberjar (jar file with all dependencies) and run them in a Centos server using something like java -jar server.jar (it's a little more complex than this but you get the idea). Would I be able to use graalvm to create native binarie…

You would likely not be able to turn them to native binaries without a ton of work — spring uses reflection very heavily, so you would have to list every class that would get reflectively checked (including spring internals). There is spring native that will solve it for the most part, but I’m not sure how hard it is to change an existing spring web app to that. GraalVM has a community edition, which is free, I’m not…

Thank you for the information! Doing some research myself I found some things about the license and integration with spring here: https://www.graalvm.org/faq/ ; it seems that no license is needed for graalvm!

I'll also take a peek on spring native it seems to be available in beta: https://github.com/spring-projects-experimental/spring-nativ...

Re: Native Minecraft servers with GraalVM Native Image

#77

Post by cogman10 »

pwagland wrote: post #51
fniephaus wrote: post #13

Earlier quoted context omitted.

Disclaimer: I work on the GraalVM team. The students "measured noticeable reductions in terms of memory footprint of up to 43%" [1] in some preliminary experiments. More from the accompanying blog post: "We also hope that the Minecraft community builds on our work and helps benchmark different configurations for native Minecraft servers in more detail and in larger settings." Please feel free to share any numbers on…

Note that the memory usage _could_ potentially be significantly improved for the JVM by just using an alternative allocator, such as jemalloc. In our system, we saw, in some instances, native memory usage decrease by about 60%, and it also resolved a slow "leak" that we saw, since glibc was allocating memory, and not returning it to the OS. In our case it was because we were opening a lot of class loaders, and hence…

I was under the impression that most builds of the JVM used jemalloc by default.

Re: Native Minecraft servers with GraalVM Native Image

#78

Post by cogman10 »

fniephaus wrote: post #33
solarkraft wrote: post #25

Earlier quoted context omitted.

Why is this? I thought the JVM already did somewhat decent JIT compilation ... If I understand the article correctly, you're preempting all possibly unoptimized/expensive code paths (reflection) by attempting to literally execute all of them? While it's a cool experiment, isn't it a bit error-prone (besides being a lot of effort of course, but playing Minecraft on the side does sound pretty fun!)?

JIT compilation requires additional CPU and memory resources at run-time, which AOT compilation can avoid. This also means that for a native executable, the compilation work only needs to be done once at build-time and not per process.

Those are usually pretty trivial as they are judiciously handed out based on hot code paths by the JVM.

There are certainly pathological cases where it could cause major issues.

AOT suffers from not having runtime information, so anything involving dynamic dispatch (which is REALLY heavily used in java) will be a lot harder to optimize. JITs get to cheat because they know that the `void foo(Collection bar)` method is always or usually called with an `ArrayList`. PGO is the AOT world's answer to this problem, but it generally explodes build times and requires real world usage.

In java land, there's also the option of "AppCDS" which can cut down a large portion of that compilation time between processes.

Re: Native Minecraft servers with GraalVM Native Image

#80

Post by IntelMiner »

Shout out for Cuberite as an alternative Minecraft server project that desperately needs more volunteers

https://github.com/cuberite/cuberite

"Cuberite is a Minecraft-compatible multiplayer game server that is written in C++ and designed to be efficient with memory and CPU"

Cuberite has been demoed running on old ARM Android phones and hosting multiple players off it at once. Its performance absolutely annihilates the Java based 'vanilla' server

Post reply on HN