Hacker News Reader

Comment by Thaxll | Hacker News Reader

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

View on HN

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 CPU/memory usage with us!

[1] https://medium.com/graalvm/native-minecraft-servers-with-gra...

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!)?

The JVM is likely to beat AOT compiled java code in almost all cases - but due to Graal having a closed-world assumption (e.g. no unknown class can be loaded, so a non-final class knows that it won’t be overridden allowing for better optimizations, limited reflection allows for storing less metadata on classes, etc) it does allow for significant memory reduction. Also, escape analysis is easier in an offline manner.

can't that all be done speculatively with de-optimization /s

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.

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.

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.

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

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.

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

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

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.

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

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

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

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.

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

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

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

A Minecraft server is not a short term job.

I guess it can be in a specific case: minigames servers (such as Hypixel), which are just a bunch of servers "connected" together. Players start into a "lobby" server, where they can choose a minigame, and are then sent to another server where they spend a few minutes.

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.

This is fairly certainly how it used to be done. Besides, you can have the server idle a good bit before actually letting players in.

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

This is a Minecraft server, so it's going to be running 24/7.

I see you aren't familiar with modern state of Minecraft servers. Due to Minecraft being limited to a one core big servers actually aren't a single instance. They use proxy servers(such as BungeeCord and it's forks) which distributes load between several lobby servers and from there people join one of custom gamemodes(Skyblock, Bedwars, etc). This allows for tens of thousands of people to play simultaneously, but not in the single world, while SMP(Survival Multiplayer) servers can run couple of hundreds at most. These giant servers are heavily containerized and automatically scale under load, so spinning up and shutting down servers is a pretty normal thing. And there have been some attempts to make Minecraft to run a single world on multiple instances(MultiPaper and some private ones), so even for usual SMP server it can be a commonplace soon as player join and leave.

> And there have been some attempts to make Minecraft to run a single world on multiple instances(MultiPaper and some private ones)

First time I hear about MultiPaper, another idea I had which I din't know someone was already working on LOL. It's a pretty promising idea considering the current performance problems of the game. This could possibly allow thousands of players in the same server which would be AMAZING, almost a completely different game. Imagine if MultiPaper was compiled to native using GraalVM.

I encourage my competitors to keep thinking this.

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

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.

Reply on news.ycombinator.com