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

81–90 of 92 posts

Re: Native Minecraft servers with GraalVM Native Image

#81

Post by OniBait »

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…

Last I did benchmarking, a vast majority of memory allocations were strings that were typically all dereferenced right away and cleaned up in GEN1 GC. I had contemplated whether string pooling would be useful or not but never got around to it. Would be interesting to see if you could get reduced memory usage and potentially better performance by decreasing pressure on the GC during the GEN1 phase.

(Side note: this was when I was co-maintaining MCPC so was typically with mods installed and they heavily use NBT which I suspect is where a lot of that string allocation was happening.)

Re: Native Minecraft servers with GraalVM Native Image

#82

Post by hocuspocus »

notme1234 wrote: post #15

Is Graal VM a silver bullet? Ignoring startup times, will Graal VM out perform classic JVM (IBM/Oracle etc'). I guess the optimization of the classic JVM are hard to beat. Also, cross compile is not working with Graal VM (which makes it harder to deploy than a good old Jar file).

Anecdotally I found that recent releases of OpenJDK with Hotspot were a bit faster. Both on my machine and for web services. If you don't need native images or truffle, the huge installation size isn't really justified.

There are multiple benchmarks that show marginal gains using GraalVM CE for big data workloads; it might make sense if you're still stuck on Java 8 or 11. The enterprise edition shows more significant gains.

Re: Native Minecraft servers with GraalVM Native Image

#83

Post by 10000truths »

IntelMiner wrote: post #80

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 th…

In a similar vein, there is also a Rust-based Minecraft server implementation:

https://github.com/feather-rs/feather

Re: Native Minecraft servers with GraalVM Native Image

#84

Post by spullara »

Thaxll wrote: post #6

"As such, it is supposed to require fewer CPU and memory resources, provide better startup times, and be easier and cheaper to deploy." So we don't even know if it actually makes things faster? Startup are a none issue, CPU / memory is but you need proof for that. Graal does not support ZGC or Shenandoah so it's hard to say if the G1 version from Graal is up to speed.

It is much worse than this because the free version of graalvm only supports the serial garbage collector. Minecraft servers and clients should be using ZGC to get rid of garbage collection pauses.

Re: Native Minecraft servers with GraalVM Native Image

#85

Post by Kukumber »

Thaxll wrote: post #6

"As such, it is supposed to require fewer CPU and memory resources, provide better startup times, and be easier and cheaper to deploy." So we don't even know if it actually makes things faster? Startup are a none issue, CPU / memory is but you need proof for that. Graal does not support ZGC or Shenandoah so it's hard to say if the G1 version from Graal is up to speed.

startup time is SUPER important

lets you spawn new game instances on the fly, reduce time spent loading the chunks and game data

you save a lot of money when you scale, and you improve latency, people don't complain with huge loading time and stutters for fresh servers

ask anybody working on the industry

fun fact, that's the first thing Riot did when they acquired Hytale

They rewrote their C# client to C++ for portability

And they rewrote their Java server to C++ for performance (and cost saving)

Tech Change: https://hytale.com/news/2022/7/summer-2022-development-updat...

Re: Native Minecraft servers with GraalVM Native Image

#86

Post by salmo »

bitcharmer wrote: post #57
fniephaus wrote: post #33

Earlier quoted context omitted.

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.

This is the first time I see someone bring up extra cpu and memory usage as a downside of JIT. It might matter in the embedded world but it's Java we're talking about so the cost is minuscule compared to what you're getting for it.

You’re not wrong, but it is funny how we got here from Gosling’s Oak addressing set top boxes.

The thing was built to address the burgeoning embedded w/ a little horsepower market with its variety of hardware and OSes.

Now it runs Enterprise server software… and Minecraft.

Re: Native Minecraft servers with GraalVM Native Image

#87

Post by Birch-san »

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.

For performance reasons, glibc may not return freed memory to the OS. You can increase the incentive for it to do so, by reducing MALLOC_ARENA_MAX to 2. https://github.com/prestodb/presto/issues/8993

Re: Native Minecraft servers with GraalVM Native Image

#88

Post by Birch-san »

xendo wrote: post #73
bitcharmer wrote: post #56

Earlier quoted context omitted.

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.

It's probably the same thing prestodb encountered: https://github.com/prestodb/presto/issues/8993

Re: Native Minecraft servers with GraalVM Native Image

#89

Post by fniephaus »

vips7L wrote: post #62
Thaxll wrote: post #6

"As such, it is supposed to require fewer CPU and memory resources, provide better startup times, and be easier and cheaper to deploy." So we don't even know if it actually makes things faster? Startup are a none issue, CPU / memory is but you need proof for that. Graal does not support ZGC or Shenandoah so it's hard to say if the G1 version from Graal is up to speed.

Are they using Graal enterprise? Last I checked Community Edition of native image uses the serial collector not G1.

The students used both, the community and enterprise editions of GraalVM. Indeed, G1 is an enterprise feature: https://www.graalvm.org/22.2/reference-manual/native-image/o...

Re: Native Minecraft servers with GraalVM Native Image

#90

Post by kaba0 »

salmo wrote: post #86
bitcharmer wrote: post #57

Earlier quoted context omitted.

This is the first time I see someone bring up extra cpu and memory usage as a downside of JIT. It might matter in the embedded world but it's Java we're talking about so the cost is minuscule compared to what you're getting for it.

You’re not wrong, but it is funny how we got here from Gosling’s Oak addressing set top boxes. The thing was built to address the burgeoning embedded w/ a little horsepower market with its variety of hardware and OSes. Now it runs Enterprise server software… and Minecraft.

Well, it does make sense - a controlled runtime failure is much better than a segfault, or worse, a silent failure corrupting heap. Pair it with decent performance even back than, increased developer productivity and the best observability tools, which is again helped by the VM-semantics.
Post reply on HN