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

61–70 of 92 posts

Re: Native Minecraft servers with GraalVM Native Image

#61

Post by kaba0 »

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 sure about the license.

And it is likely not worth it, performance will likely be worth, but memory usage and startup speed will decrease. It can be worth it for command line apps or some tiny microservice that is mostly idle.

Re: Native Minecraft servers with GraalVM Native Image

#62

Post by vips7L »

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.

Re: Native Minecraft servers with GraalVM Native Image

#63

Post by vips7L »

kaba0 wrote: post #34
majidazimi wrote: post #10

Earlier quoted context omitted.

>Startup are a none issue Yes it is. Developing any short term job -- that runs multiple seconds and goes away -- like lambda or k8s jobs with Java is meaningless for exactly this reason. The startup time is longer than the run time.

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.

The VM starts up plenty fast. The slow part is when people use reflective dependency injection containers that take seconds to scan the class path before before executing.

Re: Native Minecraft servers with GraalVM Native Image

#64

Post by Asraelite »

cesarb wrote: post #55
Asraelite wrote: post #49

Earlier quoted context omitted.

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

That sounds like the best of both worlds. Features of Java but performance of Bedrock.

Re: Native Minecraft servers with GraalVM Native Image

#65

Post by nomercy400 »

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 binaries can result in scaling back to smaller and cheaper cloud instances, or smaller VMs. Imagine halving your monthly cloud instance bill, if you are looking for 'worth it'.

If you want to play with a framework where the native part works pretty okay, and still be able to use your dependent injection and dependencies, have a look at Quarkus. They even have some spring 'polyfills'.

Re: Native Minecraft servers with GraalVM Native Image

#66

Post by zamalek »

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…

Is there any benefit to simply running/JIT the client and server on GraalVM instead of JVM?

Re: Native Minecraft servers with GraalVM Native Image

#67

Post by curtainsforus »

terafo wrote: post #30
curtainsforus wrote: post #24

Earlier quoted context omitted.

The game servers don't restart after the end of a round, though, do they? I'd imagine they kick the players back to the lobby, reset the in-server game, and then tell the lobby to send the next batch of players.

You assume that load is constant, it isn't. And load varies not only with amount of players on minigames server, but with changes in distribution of players between minigames also.

There's usually more than one server per minigame. You could see it in the url you were redirected to; they had more servers running the more popular minigames. Each minigame has a player limit, so the maximum load on any given minigame server is known (within the bounds of the minecraft sub-superset that makes up that minigame- but usually the minigames are deliberately limited/bounded in how much computation they need, as opposed to vanilla Minecraft). Extra players get sent to the next available server. If there's consistent overflow, at that point you might turn on a whole new server, or change a server's gamemode (I don't know to what degree Hypixel actually did/does this, or how often it's actually necessary).

Re: Native Minecraft servers with GraalVM Native Image

#68

Post by imtringued »

vips7L wrote: post #63
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.

The VM starts up plenty fast. The slow part is when people use reflective dependency injection containers that take seconds to scan the class path before before executing.

This is why frameworks like Micronaut exist.

Re: Native Minecraft servers with GraalVM Native Image

#69

Post by imtringued »

LtdJorge wrote: post #39
KingOfCoders wrote: post #18

No need to go for the client, it's working fine on my machine, nearly 60fps with a 12-core, 32gb + RTX2080TI with Iris, Sodium, Phosphor and Lithium .

Nearly 60, lol. Also, fps are not the real problem for the client. I had a modpack with 16GB assigned crashing due to OOM errors. Forge is awesome, but modding the hell out of MC requires extreme specs.

I upgraded my computer to 32 GB RAM just to play Minecraft.

Re: Native Minecraft servers with GraalVM Native Image

#70

Post by vips7L »

imtringued wrote: post #68
vips7L wrote: post #63

Earlier quoted context omitted.

The VM starts up plenty fast. The slow part is when people use reflective dependency injection containers that take seconds to scan the class path before before executing.

This is why frameworks like Micronaut exist.

Micronaut, Quarkus, Avaje Inject, CDI Lite. Plenty of solutions if people would stop reaching for Spring.
Post reply on HN