Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minecraft Java is switching from OpenGL to Vulkan

gamingonlinux.com

Post reply on HN
Print view View original

161–170 of 177 posts

Re: Minecraft Java is switching from OpenGL to Vulkan

#161

Post by pdpi »

cogman10 wrote: post #158
willis936 wrote: post #151

Earlier quoted context omitted.

>Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory? Of course. Because they would fail loudly and would have to be fixed in order to run. Garbage collection is a crutch which lets broken things appear not broken.

Memory leaks very often don't fail loudly. Especially if they are slower leaks which don't immediately break the application. A lot of the memory problems that you can see without a GC are hard to find and diagnose. Use after free, for example, is very often safe. It only crashes or causes problems sometimes. Same for double free. And they are hard to diagnose because the problems they do create are often observed at…

> A lot of the memory problems that you can see without a GC are hard to find and diagnose

The nastiest leak I've ever seen in a C++ production system happened inside the allocator. We had a really hostile allocation pattern that forced the book-keeping structures inside the allocator to grow over time.

Re: Minecraft Java is switching from OpenGL to Vulkan

#162

Post by pdpi »

Pay08 wrote: post #54
norman784 wrote: post #49

Earlier quoted context omitted.

TBH Mojang should have the resources to do that on his own, Minecraft is the best selling game of all times btw.

I imagine it's far from the best-earning, though. It's a one-time purchase.

You don't buy in-game money like GTA5, sure.

Then again, you'll never see a group of pre-schoolers wearing GTA5 hoodies and hats and backpacks, and you can't watch the GTA film in cinemas.

Re: Minecraft Java is switching from OpenGL to Vulkan

#163

Post by cogman10 »

pdpi wrote: post #161
cogman10 wrote: post #158

Earlier quoted context omitted.

Memory leaks very often don't fail loudly. Especially if they are slower leaks which don't immediately break the application. A lot of the memory problems that you can see without a GC are hard to find and diagnose. Use after free, for example, is very often safe. It only crashes or causes problems sometimes. Same for double free. And they are hard to diagnose because the problems they do create are often observed at…

> A lot of the memory problems that you can see without a GC are hard to find and diagnose The nastiest leak I've ever seen in a C++ production system happened inside the allocator. We had a really hostile allocation pattern that forced the book-keeping structures inside the allocator to grow over time.

To be fair, I've seen something similar with the JVM, though it recovers. G1GC when it was first introduced would create these massive bookkeeping structures in order to run collections. We are talking about off JVM heap memory allocations up to 20% of the JVM heap allocation.

It's since gotten a lot better with JVM updates, so much so that it's not a problem in Java 21 and 25.

Re: Minecraft Java is switching from OpenGL to Vulkan

#164

Post by Defletter »

cogman10 wrote: post #148
aleph_minus_one wrote: post #136

Earlier quoted context omitted.

> Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory? Garbage collection does not solve memory leak problems. For example - keeping a reference too long, - much more subtle: having a reference to some object inside some closure will also cause memory leaks in a garbage-collected language. The proper solution is to consider what you name "po…

> Garbage collection does not solve memory leak problems It solves a class of memory leak problems which are much harder to address without the GC. Memory lifetimes. It's true that you can still create an object that legitimately lives for the duration of the application, nothing solves that. But what you can't do is allocate something on the heap and forget to free it. Or double free it. Or free it before the actual…

I do wonder then how difficult it would be to mod games written in D

Re: Minecraft Java is switching from OpenGL to Vulkan

#165

Post by cogman10 »

Defletter wrote: post #164
cogman10 wrote: post #148

Earlier quoted context omitted.

> Garbage collection does not solve memory leak problems It solves a class of memory leak problems which are much harder to address without the GC. Memory lifetimes. It's true that you can still create an object that legitimately lives for the duration of the application, nothing solves that. But what you can't do is allocate something on the heap and forget to free it. Or double free it. Or free it before the actual…

I do wonder then how difficult it would be to mod games written in D

I don't think D has a "must use GC" mode, so probably easy to hit a footgun. It's the footguns that make things hard (IMO).

Re: Minecraft Java is switching from OpenGL to Vulkan

#166

Post by theandrewbailey »

jakogut wrote: post #142
theandrewbailey wrote: post #98

Earlier quoted context omitted.

I use Unigine Heaven to benchmark Linux systems. A colleague's friend has an epic spreadsheet of Heaven benchmarks across many configurations, and he submitted a few I've done. I ran it at home on my Linux desktop. For shits and giggles, I also downloaded the Windows version and ran it in Proton, and got a 30% performance boost! I suspect that a lot of that is due to the dxvk library that Proton uses, and the multith…

There's a "newer" (almost ten years old) Unigine benchmark available called Superposition you should check out. https://benchmark.unigine.com/superposition

I'm aware. I work in ewaste recycling, and most of the machines I come across are about 10 years old. I'm also a fan of JayzTwoCents. https://m.youtube.com/watch?v=ukb5tlT4IuQ

Re: Minecraft Java is switching from OpenGL to Vulkan

#167

Post by Defletter »

cogman10 wrote: post #165
Defletter wrote: post #164

Earlier quoted context omitted.

I do wonder then how difficult it would be to mod games written in D

I don't think D has a "must use GC" mode, so probably easy to hit a footgun. It's the footguns that make things hard (IMO).

There is no "must use GC" mode, as far as I'm aware, but the footguns you describe only exist if the programmers opt-out of the GC. It's somewhat similar to using JNI/FFM in Java: it's possible to escape the safety of the VM. Though it's much easier to do so in D.
Post reply on HN