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

51–60 of 92 posts

Re: Native Minecraft servers with GraalVM Native Image

#51

Post by pwagland »

fniephaus wrote: post #13
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.

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 zip files, from different threads.

Re: Native Minecraft servers with GraalVM Native Image

#52

Post by fniephaus »

das_keyboard wrote: post #50

> The native executable sometimes fails on startup. Restarting it a few times usually helps. How would this be possible for a static native executable?

It fails for some reason when reading user data from disk. The error also goes away if you nuke the user data but that's less convenient.

Re: Native Minecraft servers with GraalVM Native Image

#53

Post by rr888 »

The whole advantage of GraalVM is startup time, which is important for containers, Lambda jobs etc, because it doesn't have to compile bytecode on startup. It isn't supposed to be faster than regular JVM, which has the advantage of being able to analyze and recompile hotspots.

Re: Native Minecraft servers with GraalVM Native Image

#54

Post by operator-name »

the_gipsy wrote: post #7
fsiefken wrote: post #2

Can the same trick be used with the java client? My son runs minetest on the raspberry pi 400 as minecraft is to slow. I'll do everything for a bit more fps.

Minecraft Bedrock edition runs better. It has feature parity but is not compatible with java server, and requires a new purchase IIRC.

This is misleading, vanilla Bedrock edition allows for a bigger render distance but has a much smaller simulation distance. There's a whole miriad of differences that they're not at all in feature parity.

Re: Native Minecraft servers with GraalVM Native Image

#55

Post by cesarb »

Asraelite wrote: post #49
cesarb wrote: post #12

Earlier quoted context omitted.

> Minecraft Bedrock edition runs better. It has feature parity but is not compatible with java server, and requires a new purchase IIRC. That's no longer the case. If you have one, you can "purchase" the other for free. See https://www.minecraft.net/en-us/article/java---bedrock-editi... and https://help.minecraft.net/hc/en-us/articles/6657208607501 for details. Also, there are mods for the Java server which allow bot…

> Also, there are mods for the Java server which allow both Java and Bedrock clients to connect to the same server and play together. How exactly does that work? Afaik there are quite a few behavioral differences between the two, especially for technical things like redstone and pistons.

Most of these behavioral differences are in the server. So what happens, is that it behaves as if you were playing the Java edition, even when using a Bedrock client.

Re: Native Minecraft servers with GraalVM Native Image

#56

Post by bitcharmer »

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…

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.

Re: Native Minecraft servers with GraalVM Native Image

#57

Post by bitcharmer »

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.

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.

Re: Native Minecraft servers with GraalVM Native Image

#58

Post by bitcharmer »

CSDude wrote: post #44
kaba0 wrote: post #34

Earlier quoted context omitted.

The JVM can start up in less than 0.1 seconds. Depending on the amount of classes being loaded it is not an issue even for lambda and k8s jobs.

You clearly did not deploy enough classes on Lambda to have more than 10 seconds warmup on a trivial Java based Lambda function.

Warm-up is more a function of invocation count rather than time as you seem to be suggesting here

Re: Native Minecraft servers with GraalVM Native Image

#59

Post by spapas82 »

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 binaries from these jars? Is there some kind of tutorial describing the procedure?

Is this possible without a license/paying big money?

Finally, is this worth it? Will the apps become any faster?

Re: Native Minecraft servers with GraalVM Native Image

#60

Post by fesc »

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).

Post reply on HN