5 ms·
One of the best parts about GC languages is they tend to have much more efficient allocation/freeing because the cost is much more lumped together so it shows u
by adgjlsfhk1 7mo ago
One of the best parts about GC languages is they tend to have much more efficient allocation/freeing because the cost is much more lumped together so it shows up better in a profile.
- pjmlp 7mo agoAgreed, however there is also a reason why the best ones also pack multiple GC algorithms, like in Java and .NET, because one approach doesn't fit all workloads.
- nevdka 7mo agoThen there’s perl, which doesn’t free at all.
- cermicelli 7mo agoFreedom is overrated... :P
- NooneAtAll3 7mo agodoesn't java also? I heard that was a common complaint for minecraft
- xxs 7mo agoWhat do you mean - if Java returns memory to the OS? Which one - Java heap of the malloc/free by the JVM?
- cogman10 7mo agoJava is pretty greedy with the memory it claims. Especially historically it was pretty hard to get the JVM to release memory back to the OS. To an outsider, that looks like the JVM heap just steadily growing, which is easy to mistake for a memory leak.
- xxs 7mo agoJava has a quite strict max heap setting, it's very uncommon to let it allocate up to 25% of the system memory (the default). It won't grow past that point, though. Baring bugs/native leaks - Java has a very predictable memory allocation.
- NooneAtAll3 7mo agowe aren't talking about allocation, tho we are talking about DEallocation
- xxs 7mo agoit's a reply to: "To an outsider, that looks like the JVM heap just steadily growing, which is easy to mistake for a memory leak." I cut the part that it's possible to make JVM return memory heap after compaction but usually it's not done, i.e. if something grew once, it's likely to do it again.
- k_roy 7mo ago> Especially historically it was pretty hard to get the JVM to release memory back to the OS. This feels like a huge understatement. I still have some PTSD around when I did Java professionally between like 2005 and 2014. The early part of that was particularly horrible.
- adgjlsfhk1 7mo agoThis only really ends up being a problem on windows. On systems with proper virtual memory setups, the cost of unused memory is very low (since the the OS can just page it out)
- snackbroken 7mo agoFor video games it is pretty bad, because reading back a page from disk containing "freed" (from the application perspective, but not returned to the OS) junk you don't care about is significantly slower than the OS just handing you a fresh one. A 10-20ms delay is a noticeable stutter and even on an SSD that's only a handful of round-trips.
- adgjlsfhk1 7mo agoMinecraft for somewhat silly reasons was largely stuck using Java8 for ~a decade longer than it should have which meant that it was using some fairly outdated GC algorithms.
- NooneAtAll3 7mo ago"silly reasons" being Java breaking backwards compatibility decade seems a usual timescale for that, considering f.e. python 2->3
- kbolino 7mo agoSo much software was stuck on Java 8 and for so long that some of the better GC algorithms got backported to it.
- hedora 7mo agoPerl frees memory. It uses refcounting, so you need to break heap cycles or it will leak. (99% of the time, I find this less problematic than Java’s approach, fwiw).
- wredcoll 7mo agoUnless this has changed recently, perl doesn't free memory to the kernel, only within its own process/vm.
- bluGill 7mo agoWhen it works. Many programs in GC language end up fighting the GC by allocating a large buffer and managing it by hand anyway because when performance counts you can't have allocation time in there at all. (you see this in C all the time as well)
- cogman10 7mo agoThat's generally a bad idea. Not always, but generally. It was a better idea when Java had the old mark and sweep collector. However, with the generational collectors (which are all Java collectors now. except for epsilon) it's more problematic. Reusing buffers and objects in those buffers will pretty much guarantees that buffer ends up in oldgen. That means to clear it out, the VM has to do more expensive collections. The actual allocation time for most of Java's collectors is almost 0, it's a capacity check and a pointer bump in most circumstances. Giving the JVM more memory will generally solve issues with memory pressure and GC times. That's (generally) a better solution to performance problems vs doing the large buffer. Now, that said, there certainly have been times where allocation pressure is a major problem and removing the allocation is the solution. In particular, I've found boxing to often be a major cause of performance problems.
- CyberDildonics 7mo agoIf people didn't need to do it, they wouldn't generally do it. Not always, but generally.
- cogman10 7mo agoPeople do stuff they shouldn't all the time. For example, some code I had to clean up pretty early on in my career was a dev, for unknown reasons, reinventing the `ArrayList` and then using that invention as a set (doing deduplication by iterating over the elements and checking for duplicates). It was done in the name of performance, but it was never a slow part of the code. I replaced the whole thing with a `HashSet` and saved ~300 loc as a result. This individual did that sort of stuff all over the code base.
- CyberDildonics 7mo agoAny extra throughput is far overshadowed by trying to control pauses and too much heap allocations happening because too much gets put on the heap. For anything interactive the options are usually fighting the gc or avoiding gc.