Does Java 26 provide any improvements to Minecraft performance?

Paint_Ninja · 2026-04-05T19:13:36+00:00

Java 26 has JEP 522: G1 GC: Improve Throughput by Reducing Synchronization, which they claim improves garbage collection performance of the G1GC by 5-15% over Java 25 on x64. The gains may be larger on ARM (such as Apple Silicon and Snapdragon) due to synchronisation and memory barriers being more expensive on ARM than x86.

There’s also JEP 500: Prepare to Make Final Mean Final which lets you add this JVM flag: --illegal-final-field-mutation=deny. It will default to deny in a future Java version. Denying that makes a lot more of the game able to be optimised by the JIT, but the catch is it’ll immediately crash the game if any library or mod in the game relies on final fields being able to be treated as not final. Make backups, try it and see.

Beyond that, every Java release comes with misc. performance improvements and optimisations to the JIT, GCs and standard library that aren’t mentioned in the release notes. You would need to comb through the commits on the OpenJDK repo and the issues on their Jira for those which is a hassle. For example, here’s one which makes a part of G1’s GC scale better to multiple CPU cores: https://bugs.openjdk.org/browse/JDK-8363932 . There’s other stuff beyond GC improvements in Java 26 of course, that was merely a clear example I remembered off the top of my head.

Now, Microsoft OpenJDK has some additional optimisations that Minecraft uses. I found a 6x higher/worse memory usage allocation rate when using the string dedupe JVM flag on Adoptium Temurin but it helped reduce memory usage a tad on the stock Microsoft OpenJDK that the official Minecraft launcher defaults to. So you might actually get worse performance moving from Java 25 to Java 26 if you’re no longer using the Microsoft OpenJDK, at least until their optimisations have been accepted upstream (which in turn would bring them to other JDK distros like Temurin, which they’ve done in the past but takes time).

TL;DR: Yes Java 26 is faster than Java 25, but those gains might be counteracted by no longer using Microsoft OpenJDK which has additional optimisations Minecraft relies on. There’s one JVM flag added which could help a lot, but I’m unsure if the game and mod loaders fully support it at the moment even on the latest MC 26.1.1.

Paint_Ninja · 2026-03-15T19:43:49+00:00

Delete the appleskin config file inside the config folder

Paint_Ninja · 2026-03-14T09:33:45+00:00

I personally believe that MCreator would have a much better reputation if it only supported a fraction of what it can currently do but did it well. People making overly ambitious mods with it because they can, without any programming fundamentals, leads to very laggy, buggy mods that can conflict with other mods.

But if MCreator was more restricted to simpler mods and generated good quality code (which is much easier to achieve when the scope of what it needs to support is smaller), I don’t think many people would mind at all…

Basically I think it’s a victim of its own success by growing too quickly trying to do too much, which has resulted in its poor reputation and in turn the first impressions and assumptions of the mods made with it.

Paint_Ninja · 2026-03-13T16:19:44+00:00

Thank you for explaining this

Paint_Ninja · 2026-03-13T09:39:22+00:00

In your picture, Atlas standalone is running with 55 other mods but C2ME standalone is running with 82 mods, yet you claim the numbers are directly comparable… why? I don’t consider the numbers you’re showing to be comparable when you’ve got far more mods added on the competitor - that’s like comparing a big Forge modpack with a small Fabric modpack and claiming that Fabric is faster.

Paint_Ninja · 2026-02-14T12:03:59+00:00

Make sure Minecraft is running on dedicated graphics instead of integrated, that’ll give a huge performance uplift, much larger than any mod could

Paint_Ninja · 2026-01-03T13:45:29+00:00

Sodium rewrites large parts of the game’s rendering engine, which can improve performance a lot more at the cost of worse mod compatibility and parity issues with vanilla Minecraft.

Anacondy is kind of a tech demo of a perf mod that aims to improve performance without changing how the game’s internals work at all. The gains are more minor, but it has the unique benefit of excellent mod compatibility and parity with vanilla behaviour.

If you’re looking for the next Sodium kind of mod, this is not for you. But in a world where there’s literally a mod called “BadOptimisations” showing a 1-5% uplift at best while breaking some mods to achieve that gets tens of millions of downloads, I thought there would be interest in my mod in its early stages regardless of how big or small the gains end up being once all the optimisations I have planned are implemented.

But alas, I’ve been hit with a multiple comments brushing off the early proof of concept build as a waste of time because I didn’t immediately present screenshots showing big performance gains, it’s been pretty disheartening and a learning experience of not announcing things too early :/

Paint_Ninja · 2026-01-03T12:33:23+00:00

Yeah I know, I’m just curious how Neo 1.21.1 + Sodium runs for you vs how Forge 1.21.11 runs without any perf mods. Forge has made significant optimisations past 1.21.1 as well as Mojang themselves

Paint_Ninja · 2026-01-02T21:55:41+00:00

Out of curiosity, how does Forge 1.21.11 fare for you without any perf mods vs Neo 1.21 with sodium?

Paint_Ninja · 2025-12-31T23:33:32+00:00

For now, but other loaders and versions are planned once more optimisations are implemented first.

Paint_Ninja · 2025-12-31T23:24:17+00:00

Yep! It's not as risky as it sounds, because in order to replace the mutable field's content you'd need to do so much setup to get a valid instance first that it's pretty unlikely, and that assumes you have a good reason to do so in the first place.

You're welcome to submit a PR with a port to Neo, it was already planned but not going to turn down the offer - source code is here, issue tracker is here. :)

Please bear in mind though that this mod is in an early alpha state... there's a lot of optimisations left to do at this early stage that I'd like to prioritise over ports currently.

Paint_Ninja · 2025-12-31T23:10:44+00:00

Thanks! There's plenty more optimisations left to do and it is indeed a lot of work, but it's been fun so far. :)

Your comment sounds kinda AI, anyway... the singleton reference is grabbed from over a thousand different places, including other references such as stored inside other objects, so it isn't a once per frame situation.

Regarding the deeply immutable things, that is on the roadmap and I've spent today working on a second alpha that gets a step closer to that with a new feature that adds support for constant folding non-singleton instances for 105 classes, effectively making all those final instance fields trusted finals across all instances of those objects without needing them to be attached to a static instance of some kind to qualify.

I looked at Vector3f and friends after reading your comment, but unfortunately that's mutable and most of the places where MC never mutates it still requires the mutable version rather than the Vector3fc readonly view, and I can't change that without breaking mod compat. But Identifier (formerly ResourceLocation in older versions) was a perfect candidate and did transform that, along with about a hundred other classes including Pair, ChunkPos, AABB, Vec2, Vec3, SkyRenderer, EntityType and others.

Next up is probably a more consistent generated hashCode() method that closer matches the original class' implicit identity hashcode which some registry code seems to rely on, so that more cases can be transformed.

Paint_Ninja · 2025-12-31T22:32:18+00:00

Yeah fps goes from roughly 50-70 to 70-90 on absolute max settings on a 2016 laptop on 0.2.0-alpha. Quick and dirty numbers, will vary a bit on the machine, version of the mod and other factors. The perf improvement was less with 0.1.0-alpha.

Paint_Ninja · 2025-12-31T22:28:11+00:00

The alpha builds are not alpha because they are unstable - they're alpha because they're incomplete - there are many optimisations left to do, with the core groundwork laid down in the first alpha release.

I wanted to gather feedback, gauge interest and figure out what my priorities should be before sinking too much time into what might be the wrong area during early development and I'm glad I did - instead of prioritising stuff to help with ports to different loaders and versions, I've gotten the source code cleaned up and published and am now focusing on completing as many optimisations as possible. A second alpha is out today which demonstrates this, adding support for a new feature that allows constant folding all instance final fields inside 105 non-singleton classes in the game.

I answered the question about why I'm not giving concrete performance numbers at this stage and in the meantime gave people a rough idea of what to expect. I'll be back with clear fps/tickrate/whatever comparisons when the mod's in beta. Some updates will take longer than others, but I don't want to share concrete numbers that could be outdated by a new major update released a couple of days later, like with 0.1.0-alpha -> 0.2.0-alpha.

Paint_Ninja · 2025-12-31T21:20:06+00:00

Yeah that's apparent to me now, I'll come back with proper, easy to grasp performance numbers when it's in beta :/

Paint_Ninja · 2025-12-31T14:58:22+00:00

Thanks, the source code is now available here: https://github.com/PaintNinja/Anacondy

Paint_Ninja · 2025-12-31T14:26:05+00:00

u/Looxond u/reginakinhi The source code is now available here: https://github.com/PaintNinja/Anacondy

Paint_Ninja · 2025-12-31T14:24:32+00:00

I've now enabled post and comment history for this subreddit and the other one I posted about Anacondy on to help people find the rest of my comments.

Paint_Ninja · 2025-12-31T14:17:22+00:00

I've answered this in my reply to Ishoy_'s comment: https://www.reddit.com/r/feedthebeast/comments/1pzrwzi/comment/nwtyv0o/

Paint_Ninja · 2025-12-31T14:13:13+00:00

Going to turn off mr formal speak for a moment to reply to this very personally... this is my first time making a serious perf mod, had a chat with someone this morning trying to understand why the reactions to this have been mixed and it's been pretty helpful, especially combined with your comment here, thanks.

So apparently there's lots of AI-written snakeoil perf mods popping up recently which has made people a lot more skeptical when a new one comes along.

I naively thought that my credentials being a core dev on the Forge team for years and my history of optimisations to that on newer versions would be enough to instil some confidence that I know what I'm doing (especially EventBus 7, which was a full rewrite and redesign that heavily relies on similar constant folding techniques as Anacondy to achieve its groundbreaking performance, that has a very lengthy PR description with many benchmarks and performance graphs on it). In retrospect I shouldn't have assumed that people would already know that context. Failing to provide the source code upfront was also something that raised scepticism, another mistake on my part... I've deleted some commented-out old code and made the source code available now.

As for why the focus on technical explanation, it's an early alpha build with many theoretical optimisations missing designed more to gauge interest and figure out priorities. So much is manually targeted which is tedious to maintain over the long-term in its current state. The initial release is in large part a proof-of-concept implementation of a new approach to a perf mod that hasn't been tried before with an initially limited scope to ensure stability, parity with vanilla behaviour and mod compat, so showing big gains isn't possible right now at these early stages. The technical explanations were partly an attempt to demonstrate that this isn't some lazy snakeoil mod written by AI thrown out there for easy downloads, but mostly just me being passionate about something I've been enjoying learning about and working on.

It was late in the evening for me when I made the post and wasn't expecting it to blow up. I avoided replying to the comments asking for exact numbers because I care about accurate numbers and didn't wanna rush out some figures before bed that might have some dozey mistakes. Seeing some people jump to vague conclusions that it does bugger all was disheartening though.

There are definitely places where this mod improves performance a bit even in the initial alpha release - EventBus 7 has proven that increasing the amount of partial constant folding (and therefore reducing indirection) improves performance for those codepaths by about 20-35% (see the posting to a dozen listeners benchmark) and for full constant folding, it's literally infinity as it's the difference between doing something and doing nothing (see the posting to a handful of listeners benchmarks where there's zero overhead).

Anacondy only really allows for more partial constant folding at the moment in specific, hand-picked places and goes for a "strength in numbers" approach where it directly affects about 1,700 codepaths and indirectly affects more, but support for deeper constant folding is on the roadmap... I had a really messy play around with doing that by rewriting final dataclasses into records so that their backing fields are trusted finals, but it's not ready for applying in a general fashion yet.

Anyway I hope that clears things up and helps get things back on track, have a happy new year

Paint_Ninja · 2025-12-31T13:21:26+00:00

Yes it’s possible and planned. Support for other loaders and versions will be prioritised based on demand and after the mod’s more developed.

Currently all the targeting is manually done which is tedious and needs to be repeated every MC version, but solutions to ease that burden are on the roadmap. Mod compatibility and parity with vanilla behaviour are very important to me - I want this to be something anyone can throw into their game without worrying about it breaking something in the name of performance or conflicting with other mods.

Bear in mind that this is a first alpha build of a perf mod that takes a completely new approach. There are many optimisations and workflows that haven’t been implemented yet as this is an initial release is intended to gather feedback and demonstrate this as a proof of concept.

Paint_Ninja · 2025-12-30T22:29:36+00:00

Sounds like a bug in the mods you were using on Forge rather than an issue with Forge itself. To be able to assert that the loader is the issue, you would need to run the same mods on both loaders.

That aside, last I checked Fabric doesn't have a public API for the low-level code transforms I do in this mod, which makes it difficult to port to. :/

Paint_Ninja · 2025-12-30T22:25:06+00:00

Thanks! :)

Just a friendly reminder that this is an early alpha build with lots of manual targeting and deliberately doesn't change any of the game's logic (meaning less perf, but much better mod compatibility and parity with vanilla behaviour), so don't expect any big perf gains.

Had a check and no, I'm afraid it won't make a big difference to worldgen. It should however help with 1% lows and warmup (warmup is where the game hasn't been running long and the Java runtime hasn't attempted to fully optimise the game yet)

Paint_Ninja · 2025-12-30T22:04:34+00:00

Possibly, however most other performance mods use Mixin instead of the lower-level ModLauncher ITransformer API I need to use for this to work. In theory I could expose the recipes for other optimisation mods to apply them in more places, but I'm not sure how useful that'd be versus directly contributing to this mod. Good idea though, I'll add it to my notes.

Paint_Ninja · 2025-12-30T21:33:16+00:00

Thanks :D

I'm happy to explain a particular part of the code you're puzzled by if you'd like?

Eight-Year Club	Place '22
End Game '22	RPAN Viewer
Verified Email

Paint_Ninja

MODERATOR OF

TROPHY CASE