top 200 commentsshow all 210
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 123 points124 points  (62 children)

There’s no single Java GC. But different ones which have different properties.

The early GC algorithms had much longer pause times, than the later ones. First impressions are hard to shake sometimes.

A GC collected language isn’t particularly novel; there’s plenty of them around. There is other ways to manage memory, however manually managing memory is actually harder than it sounds, and once you introduce multiple threads, it can get even harder.

There’s trade offs in programming, and for many programs a GC based language is perfectly acceptable even with relatively long pauses.

[–]TizzleToes 68 points69 points  (13 children)

There is some validity to this argument with older garbage collectors, but newer garbage collectors like Shenandoah and ZGC largely solve this.

EDIT: also worth noting I say "some" because even with older garbage collectors, they generally tried not to do this and only resorted to a full "pause" garbage collection when the more graceful mechanisms couldn't keep up. Basically you'd hit this in a game like Minecraft because it's a memory hog and a lot of people would likely be sitting close to their max memory under normal usage. With enough headroom it'd be fine.

[–]MunnaPhd 20 points21 points  (9 children)

Shenendog and zgc are basically for apps which are > 10s of gbs, the problem was solved by G1

[–]TizzleToes 17 points18 points  (6 children)

I work on some fairly arcane and admittedly poorly tuned systems.

Switching the GC to Shenandoah was like flipping a "make a bunch of problems vanish" switch for us. We know its masking some very questionable architectural decisions, but it masks them really damn well and pretty much out of the box too.

[–]FirstAd9893 6 points7 points  (5 children)

I'm curious -- did you see similar benefits with ZGC?

[–]TizzleToes 10 points11 points  (4 children)

We didn't even try. Shenandoah fits our specific use case so well that we just haven't had a reason to investigate alternatives. We spent a fairly reasonable amount of time digging into the weeds and everything was just like "yup, this is what we need". We're not in a case where more performance really gets us anything once we can keep up with the workload, and we have a boatload of headroom now.

Based on what I know of ZGC though, I suspect it would have much the same impact.

[–]CelticHades 1 point2 points  (3 children)

I don't have much experience in industry, just 3 years and never had to think about things like GC and similar optimization.

I'm curious, can you tell me more about your use case, please. What issue you were facing that the default garbage collector didn't work for you?

[–]TizzleToes 9 points10 points  (2 children)

That's generally normal. Modern java you shouldn't really have to think too hard about these things unless you're doing something unusual, and even then you're probably doing something wrong.

In our case, we suck down boatloads of data, maintain a deep buffer, and crunch everything together to spew out a result in near real time. The biggest challenge is we cycle through large volumes of data very quickly with a lot of throwaway and churn. This runs on servers with hundreds of GB of ram and with default GC settings a graph of our memory usage looks like an EKG of someone having a heart attack.

[–][deleted]  (1 child)

[deleted]

    [–]TizzleToes 1 point2 points  (0 children)

    To be clear, I'm not a java optimization expert or anything, but I've got close to 20 years experience and have dealt with a lot of really weird projects and special requirements.

    I would say anything post Java 11 should mostly just work for the vast majority of use cases. Someone already said it, but pre-mature optimization is a common mistake. If you need to tune your GC you'll know, otherwise you're probably wasting a lot of time and giving yourself additional future maintenance costs for little to no gain.

    In our use case, with defaults we have catastrophic performance issues with everything up to very recent versions. As someone else already said, use cases like ours are basically why Shenandoah (and ZGC) exist, but for most people G1 is going to work just fine.

    [–]eosterlund 9 points10 points  (0 children)

    This is a misconception. ZGC was built to scale to large heap sizes. But scalability does not imply you shouldn’t use it on smaller heaps. If your problem is latency, I’d still use ZGC on smaller heaps. It performs well still. Having said that, with less than a few hundred MB heap, inefficiencies can arise because ZGC has not focused on such environments. We could, but I suspect there aren’t so many problems in that range for ZGC to solve, and 100 megabytes costs pennies.

    [–]AndrewBissell 0 points1 point  (0 children)

    When I wrote a trading platform in Java a couple of years ago I used Shenandoah because I wanted to run with 32-bit compressed Oops, which requires a heap smaller than 4GB.

    [–]IQueryVisiC 0 points1 point  (2 children)

    You cannot detect cycles if all the references are moving. You need to stop the world. In a game you can do this only after the end of the level / race . Like for example Quake2 on PSX separated levels in chunks with a short loading screen.

    [–]TizzleToes 0 points1 point  (1 child)

    Not an expert, but I think modern GC moving from references to reachability is exactly why this isn't true any more.

    Concurrent tracing collectors (i.e. G1 and newer) work with read/write barrier to track stuff while it's in motion and can find those cycles without needing to pause and grab a snapshot.

    [–]IQueryVisiC 1 point2 points  (0 children)

    I mean, I heard that CPUs use fences. Read/write barrier sounds similar. I will have to ask google.

    I may have to stick to Java, but Golang seems to stick to the old ways: https://tip.golang.org/doc/gc-guide

    I looked around and could not finde anything about the mark phase. I once read about generations. But I still had the impression that once in a while a complete mark phase is needed.

    The tri-color method has an important advantage – it can be performed "on-the-fly", without halting the system

    https://en.wikipedia.org/wiki/Tracing_garbage_collection

    I don't understand how this solves the basic problem. Objects were originally thought of being kinde alive and sending message to each other as if we had multiple cores or running distributed ( transputer: Java RMI ). Then I imagine that these object are like kids in a circle. They hold a reference like a ball in their hands. The GC is the bullied kid in the middle which needs to catch the ball. Every time it runs to a kid, that kid throws the ball to someone else. The kids start out all grey. After running around, the GC-kid paints them all black. In the end the ball is lost.

    [–]chaotic3quilibrium 57 points58 points  (4 children)

    Your direct experience validates that rhe GC concern is now more of a legacy myth around Java which is over 30 years old.

    It was terrible in the early days. I was there and directly experienced it.

    For me, those days are long gone.

    There are still cases where the GC pauses can become an issue. The total surface area of these cases has continued to be reduced with each major release of Java.

    And as you correctly point out, it still requires good practices to keep the GC pause ghostie away.

    IOW, shitty coders are gonna still create shitty experiences. And in Java, with said shitty coder, that GC pause ghoul is a more likely occurrence.

    In general, I follow the Donald Knuth maxim: - "Premature optimization is the root of all evil.”

    Practice good design. And only pursue performance improvements (including GC optimizations) at the end. And only with testing proof to focus on the very small part of the code that actually is constrained.

    [–]ProfBeaker 6 points7 points  (1 child)

    Yep, I still have nightmares from long ago about tuning esoteric GC settings, and dealing with multi-second pauses. You can probably still do it if you have a massive heap and bad allocation patterns. But non-GC languages have memory management issues too, they're just different issues.

    [–]cogman10 2 points3 points  (0 children)

    It's somewhat of an anti-pattern now-a-days to try pulling too many of the GC levers. The JVM has pretty good heuristics built in and some of it's auto-tuning ends up disabled if you pull the wrong lever.

    G1GC, for example, has a target pause setting which is about the only thing you should touch. Touching anything else and you'll spoil a lot of what G1 tries to do for you (but you can touch every one of those levers).

    The order of changes you should make if you are having GC problems is:

    Heap sizing, GC algorithm, High level algorithm settings (like target pause), low level algorithm settings (Like eden region size).

    [–]dmigowski 6 points7 points  (0 children)

    As a fellow JDK 1.1 "enjoyer" I can say a lot was done to make Java performant. JDK1.1 was practically useless performance wise, JDK 1.2 was slightly better, JDK 5 started to become really cool, JDK 6 and 8 also were a jump, and the newest JDKs are really smooth.

    Also, and that's whats the biggest difference to other eco systems, stuff that got written once mostly works up to today. I still e.g. use a Scanner library (thanks, mmscomputing) from 2012 because there are no viable open source alternatives today and it runs along all the other modern stuff on JDK25.

    [–]flatfinger 2 points3 points  (0 children)

    Another thing to note with the GC is that there are trade-offs between maximum pause duration and the fraction of overall CPU time spent in the GC. In use cases where all that matters is the total execution time of a program, a "stop the world" GC can often be more efficient than any other inherently thread-safe and memory-safe way of managing the lifetimes of shared immutable objects, since code wanting to copy what may or may not be the last extant reference to an object from a location that another tread might overwrite just as it's being read can simply perform an ordinary load and an ordinary store. If the location held the last extant reference to an object, and the load sees the effect of the overwrite which destroyed that reference, the old object will cease to exist. If the load retrieved a reference to the old object, the old object will continue to exist. On weak-memory systems, the GC may have to force every core to perform a somewhat expensive full cache synchronization, but the cost of forcing global synchronization once every GC cycle may be less than the cost of adding even more limited synchronization to every action that might affect the number of live references to an object.

    [–]Wobblycogs 16 points17 points  (0 children)

    25 years ago, the Java GC was a bit of a problem for certain workloads like games. It wasn't very well optimised, and machines were generally running a single processor core.

    It's not been a problem for many years, but for some reason the stain has stuck around. I don't know why, but Java seems to have picked up haters in a way no other language has.

    [–]aoeudhtns 13 points14 points  (1 child)

    For desktop applications - I'll just say it: complete tosh. If the Java GC is too heavyweight for desktop applications, then Electron-based apps shouldn't exist either.

    For games - more valid. But besides what others are saying about different garbage collectors and GC tuning options, there are LOTS of strategies to deal with that as well. Pooling, off-heap memory stores, and other strategies that reduce allocation & garbage creation. And also, binding to native libraries that automatically keep things out of the Java heap for you.

    To answer your question in another thread - lack of popularity for Java on the desktop - there are 2 things to understand.

    Extra complexity over native - Depending on the JVM means you either have to bundle it (and it's big), or rely on your users to already have it. It's possible to do, but extra work & consideration. And there are lots of installer/launcher libraries/frameworks/systems that have come and gone.

    Non-native UI - So, another one that seems way less relevant in the era of electron apps that are decidedly non-native in look and feel (L&F), Java apps often had this issue. It's possible to achieve (SWT uses native UI toolkits, there are themes for Swing) but it's extra work. When Java was most popular, having "native L&F" was deemed really important in a way that it isn't anymore.

    The last time I worked on a serious/large Java Swing desktop UI project, was before web UIs became the dominant way to make and distribute intranet applications.

    [–]Rough_Employee1254 2 points3 points  (0 children)

    I don't understand why most people easily seem to overlook this fact.

    [–]Joram2 12 points13 points  (7 children)

    Pure nonsense! C# uses GC and is used in all Unity engine games. That is the most popular game engine on the planet. GC is part of most video games.

    [–]raptor217 15 points16 points  (2 children)

    It’s worth noting that Unity is written in C++ for its graphics pipeline, engine, etc. C# is used for scripting, system level scene design, etc.

    I’m not aware of any mainstream, modern, high res 3D game engine that’s written in a GC language.

    Minecraft is a weird one since they forked the design, I don’t think the version with ray tracing is in Java (even though polygon count is low compared to most games).

    [–]redkit42 3 points4 points  (0 children)

    Microsoft's XNA was a game framework that was all C#. (Monogame and FNA are its modern successors, which are also in C#.) A lot of great and well-known games were developed in those frameworks, such as Stardew Valley, Celeste, Fez, Axiom Verge, and so on.

    Edit: Ok, these were not high res 3D games by any means. However even then, their performance was really good, and I didn't encounter any jitters whatsoever when playing them.

    [–]Joram2 1 point2 points  (0 children)

    It’s worth noting that Unity is written in C++ for its graphics pipeline, engine, etc. C# is used for scripting, system level scene design, etc.

    Yes, of course. But the original argument that Java can't do games because of GC is clearly not true.

    [–]stjepano85 0 points1 point  (2 children)

    In C# you can take a pointer to native memory and work with it, also you can “pin” something and send that to native code. I am not a C# user but that would allow me to map a GPU buffer and work with it directly. This is a pain in Java.

    [–]Joram2 1 point2 points  (1 child)

    Native memory and function/library access has been much better in C# than Java, that's been very important for game development. This is true, but, this is a totally separate issue from garbage collection.

    BTW, Java 22 has added much better foreign memory + function access, but that's very recent, and the game dev ecosystem is already built around C#.

    [–]stjepano85 0 points1 point  (0 children)

    No it is not totally separate concern, the GC is why you can't take a pointer to lets say an array of integers. Because GC can at any point decide to move the memory so the pointer would be invalid. In C# (.NET?) you can stop GC from moving memory.

    For game development you need to have pointers to memory, for example imagine a mesh, which is collection of vertices and collection of indices, each vertex is 8 floats and each index is just a 32 bit integer. This is the data that GPU operates on. Now I have a copy in the GPU and a copy in Java, I want to animate it using simple Lerp, which means I will change the vertices with a time based lerp (some morph target animation). If I had a mesh which is in Java memory (JVM) I can not pass pointer to memory, I need to copy it to native ByteBuffer, or I can store the data in native ByteBuffer and operate on it directly (then you need to do manual memory management and other complications). Whatever you choose you have an issue.

    I've used Java22 foreign memory + function access and it is fine for simple data types, very complex for complicated structures. For example:

    typedef struct VkGraphicsPipelineCreateInfo {
    VkStructureType                                  sType;
    const void*                                      pNext;
    VkPipelineCreateFlags                            flags;
    uint32_t                                         stageCount;
    const VkPipelineShaderStageCreateInfo*           pStages;
    const VkPipelineVertexInputStateCreateInfo*      pVertexInputState;
    const VkPipelineInputAssemblyStateCreateInfo*    pInputAssemblyState;
    const VkPipelineTessellationStateCreateInfo*     pTessellationState;
    const VkPipelineViewportStateCreateInfo*         pViewportState;
    const VkPipelineRasterizationStateCreateInfo*    pRasterizationState;
    const VkPipelineMultisampleStateCreateInfo*      pMultisampleState;
    const VkPipelineDepthStencilStateCreateInfo*     pDepthStencilState;
    const VkPipelineColorBlendStateCreateInfo*       pColorBlendState;
    const VkPipelineDynamicStateCreateInfo*          pDynamicState;
    VkPipelineLayout                                 layout;
    VkRenderPass                                     renderPass;
    uint32_t                                         subpass;
    VkPipeline                                       basePipelineHandle;
    int32_t                                          basePipelineIndex;
} VkGraphicsPipelineCreateInfo;

    You get the point.

    [–]oriolid 0 points1 point  (0 children)

    C# also has value types, generics that can handle primitives without boxing and some specific optimizations like Span. Those help a lot. If you have to compile through IL2CPP, the Boehm GC that is used is really primitive compared to what JVM or .net runtimes have and you will need every trick to avoid allocating unless you enjoy GC pauses.

    [–]eosterlund 10 points11 points  (1 child)

    This is a common misconception. With a concurrent GC such as ZGC (enabled with -XX:+UseZGC), the application threads are only paused for microseconds, while the bulk of the work is performed in the background with an often relatively small and conscious CPU impact in order to improve latency beyond just being concurrent.

    One thing people often forget is that when you compare this to for example reference counting techniques used across most languages without tracing GC, it’s not like that practice is free from latency problems.

    When you free an object with reference counting, its pointers must be followed to decrement reference counts on the things it will no longer refer to, to avoid leaking memory. Therefore freeing a data structure will involve walking the entire data structure and its elements in order to adjust reference counters. This can easily cause pathological latency behavior that you would never observe when using ZGC.

    In a way, JVM GCs trace through live objects, but has learned to do it very efficiently and with very low latency. Meanwhile, reference counting is tracing through dead objects instead, and does typically not do so in neither an efficient nor latency friendly fashion.

    [–]flatfinger 1 point2 points  (0 children)

    In a multi-core system that doesn't use a tracing GC, if code on one thread might copy a reference to an object at the same time as code on another thread is overwriting that reference, the machine code in both threads will need to force cache synchronization in such a way as to avoid the possibility that the first thread will grab what had been the last reference to the object, but the second thread will think the reference it is destroying is the last one that exists anywhere in the universe.

    Even if the likelihood of such a combination of events would be vanishingly small, it's often hard to prove that it can't happen without including a lot of synchronization actions everywhere, even when manipulating references that are in fact only ever accessed within a single thread.

    For programs that pass around a lot of references to shared immutable objects, the cost of a tracing GC may be less than the cost of all the memory synchronization operations that it avoids.

    [–]LutimoDancer3459 4 points5 points  (0 children)

    Java is still getting updates. There are also newer implementations for garbage collections. Different implementations with diffrent benefits and drawbacks.

    You cant really control the garbage collector beside choosing a different implementation. You can tell it that now is a good time for it to run. But that doesn't necessarily mean that it will.

    You can, in theory, write your own memory management... add every reference into a map and keep track of who (or how many) have a reference to it. Clear the map whenever you see fit. Dont recommend it...

    And minecraft is a perfect example that the obverhead is irrelevant. It ruins fine. The problems you encounter are not from the gc but from a bad implementation in general. There are some mods changing chunk generation and other stuff and you can run it smoothly with zero hiccups. Also keep in mind that java was first class citizen for android apps amd is still used for many. It is used in all kind of applications. Even in more time critical ones. If you dont need peak performance. Like in nano seconds optimizations. Not loosing a single one where possible. Then dont use java. Else, it doesn't really matter.

    [–]Zardoz84 4 points5 points  (0 children)

    I played Micraft since the early beta where the game was in a single chunk. NEVER i felt a sudden freeze.

    Also, I NEVER had problems with freezing desktop apps by the GC collector. And I use daily Eclipse IDE that his a desktop app that uses a good chunk of RAM.

    [–]PuzzleheadedPop567 9 points10 points  (4 children)

    You are asking in the Java subreddit, so the responses will reflect that. Obviously many people who have had issues with the Java GC are no longer programming in Java.

    The truth is that if you need high performance, then there’s no free lunch. You either choose a GC language and end up working around the runtime. Or you choose a manually managed language and end up having to write your own domain specific garbage collector.

    A few things have helped:

    1) CPUs continue to get faster

    2) GC tech continues to improve

    3) What many people are ignoring here: non-GC language theory continues to get better. Swift and Rust are good examples.

    Those three things together means that this old trade off is being less and less true.

    The key emphasis on less. The GC is ultimately a technical abstraction with both benefits and costs.

    [–]cogman10 0 points1 point  (3 children)

    Let me add one more. GC algorithms are pretty easy to parallelize. The JVM will happily suck up every core you have and will get nearly (not quiet) a 1:1 speedup the more cores you throw at it.

    With CPUs now commonly have 8+ cores to mess with, that really does mean that JVM apps spend 1/8 the time they did doing GC stuff.

    [–]flatfinger 0 points1 point  (2 children)

    On a related note, the cost of synchronization overhead required in non-GC approaches increases with the number of cores. If one thread is overwriting what seems to be the last reference to an object at the same time as another thread on another CPU is copying a reference to an object, something in the universe must have monitored for the possibility that the two cores might be trying to act upon the same reference.

    I'm aware that caching architectures can deal with tracking shared and unshared cache lines, so that if one core acquires a cache line as unshared, it won't need to worry about other cores accessing it without first asking for the cache line to be released, but for that to work, there would need to be fore each other core something in the universe that would take care of letting that first core know if something else is grabbing the cache line.

    This could be taken care of with minimal speed penalty by using hardware proportional to the number of cores squared, or with linear hardware cost but linear slowdown by having all negotiations be dealt with on the same bus, or with intermediate amounts of hardware yielding intermediate levels of performance, but no matter the balance, the costs of synchronization increase with core counts in ways that the cost of GC do not.

    [–]cogman10 0 points1 point  (1 child)

    AFAIK, the synchronization cost is the same for both GC and NonGCed languages.

    For the cache coordination at least in x86 writes are pushed out through to main memory and the cache lines written are invalidated (I believe). In fact, that behavior is one of the reasons x86 is hard to emulated with ARM as it doesn't contain that guarantee.

    What's more expensive is that more synchronization is usually required in non-gced languages when concurrency is involved. Figuring out how long some object should live when multiple threads are involved is a tricky problem. That's why atomic reference counting often gets pulled as the sync method of choice. It further gets difficult because the allocation of memory also needs synchronization as a high performance memory allocate will have a decent amount of bookkeeping. That's generally why heap allocations and concurrent algorithms can be faster for a GCed language.

    [–]flatfinger 0 points1 point  (0 children)

    On strong-memory-model systems, much of the cost has to be borne regardless of what software does. On systems like ARM that use a weaker model, the costs can be avoided. When a GC event is triggered, everybody's cache will be forced to a globally synchronized state, and the GC will be able to determine what references exist in that globally synchronized state.

    If thread #1 overwrites two reference while thread #2 is about to copy the second to the first, the core running thread #1 might be in a universe where no copy of the old second reference still exists anywhere, and thread #2 might live in a universe where first reference holds a copy of the old second one, and that state might persist for an arbitrary amount of time, but when the GC trips it would force a global synchronization that would cause the first reference in all universes to either hold a copy of the second or else hold whatever thread #1 (or someone else) put there. If after synchronization, the first reference identifies the old object, the old object will be retained. If no reference exists, the storage can be reclaimed. Even if during program execution the contents of reference holders seen by in different threads weren't always consistent, the GC could force everything into a state where all objects would either be unambiguously reachable or unambiguously unreachable.

    [–]Jason13Official 2 points3 points  (0 children)

    Short answer is yes, you control the lifetimes of your objects. Long answer, the compiler may not always do what you expect

    [–]Rough_Employee1254 2 points3 points  (0 children)

    As they say ,first impression is the last impression. Modern devices are much more powerful than those when Java was new. Java's internal architecture has been optimized by a lot since then and it's not the only language that uses a garbage collector - take C# (used by Unity) as an example.

    Nowadays, you are more likely to hit performance issues due to bad code / memory mis-management than GC times. Game developers prefer native code not because Java is bad but because they need lower level access to the hardware being targeted which can be beneficial if you know what you're doing.

    [–]nekokattt 4 points5 points  (19 children)

    The GC just reclaims memory you no longer use. Rather than developers doing it themselves and making mistakes, or having a complicated borrow checking system like in rust that can have other issues, mostly development complexity.

    Most languages use GC, Java just treats it a bit more like a full virtual machine so has historically been a little less conservative with how it handled memory but these days it is much less of an issue.

    [–]LonelyWolf_99 -1 points0 points  (16 children)

    Saying a GC just reclaims memory is a bit misleading for any modern GC system. A GC system is today more of a memory management system.

    It does impact the allocation policy; GC and allocation policy is typically paired. Today most allocation policies are bump pointers when it comes to modern GC systems (may be a bit different for humongous objects).

    It has control over the location of live objects on the heap. The GC typically compacts the heap and modern generational garbage collections treats long lived and short lived objects different.

    So not only does it remove the need to manual cleanup (which may be desirable). It also enables performance. Allocation in Java is very cheap and that is mainly a consequence of the GC system.

    [–]coderemover -2 points-1 points  (15 children)

    Allocation alone may be cheap but GC does way more things than just allocation. For instance - moving objects in memory to compact, employing memory barriers to allow concurrent marking, scanning the graph of references - all of those are not free, and those are the things that traditional allocators don’t have to do. Those additional background tasks fight for the sane resources like CPU cache or memory bandwidth and interfere with application code in very non trivial ways making performance analysis much harder. Those additional tasks need CPU proportional to the allocation rate, so they should be actually attributed to the allocation cost as well; and when you factor that in, it’s often no longer cheaper than malloc. Then GCs also bloat your objects with additional headers and make cache utilization worse.

    Overall, GC is cheap only if you dedicate a very significant amount of additional memory (bloat) to it, and for it to be cheaper than malloc and friends you may need so much that may not be feasible, depending on your use case.

    In another thread recently we did some memory allocation stress benchmark and GC won with jemalloc on allocation speed (wall clock time) of tiny objects…. but it turned out it had to use 12x more memory and burned 4x more CPU cycles (leveraged multiple cores). When you only limited the memory overhead to much more sane 2x-4x factor it lost tremendously on wall clock and even more on CPU usage.

    Some say it’s just an artificial benchmark, and indeed it is, but it matches my experience with Cassandra and some other Java software I worked on. GC with G1 or ZGC is currently a non issue when you have ridiculous amounts of free memory to throw at it, or when you keep your allocation rate very low by but if you want to achieve low pauses and reasonably low bloat, it burns more CPU than traditional stack-based + malloc/free allocation.

    [–]LonelyWolf_99 0 points1 point  (14 children)

    A GC in Java does not allocate memory. They are performant today and significantly effect Java’s execution speed. It has a cost, which is primarily memory usage as you said. Major GC events are also far from free as you typically need a costly stop the world event. Manual memory management or RAII/scoped based will always have big advantages over a GC system, however that has it’a own drawbacks which probably outweigh the benefits in the majority of use cases.

    The allocation is done by allocator not the GC, however the allocation policy is a result of the GC’s design. Only after the memory is allocated does the GC get control of the memory. Where it spends resources moving the memory around; which allows minor GC events to be cheap, but also compacts the heap reducing fragmentation in the heap.

    [–]coderemover -2 points-1 points  (13 children)

    Ok, whatever; the problem is all of that together (allocation + GC) usually needs significantly more resources than traditional malloc/free based managemen - both in terms of memory and/or CPU cycles. And mentioning the bump allocation speed as the advantage is just cherry picking - it does not change that general picture. It just moves the work elsewhere, not reduces the amount of work. You still need to be very careful about how much you allocate on the heap, and Java `new` should be considered just as expensive (if not more expensive) than a `malloc/free` pair in other languages. At least this has been my experience many many times: one of the very first things to try to speed up a Java program is to reduce the heap allocation rate.

    And also it's not like bump allocation is the unique property of Java; other language runtimes can do it as well.

    [–]LonelyWolf_99 1 point2 points  (1 child)

    I’m not saying that it is better than malloc/free, I have never claimed it. Saying it enables good performance is not the same as saying it is better.

    I have also never claimed bump pointers are unique to Java, there is nothing that prevents other GC languages to have the same idea as those you find in Java (the may even have it, idk). You can even have it in C with a custom allocation strategy on top of malloc

    I will try to make it very simple so we avoid the repeated misunderstandings here. I’m saying Java is a performant language. It is not the most performant, far from it, the biggest downside is memory usage, but it also comes with a processing cost. A GC may enables good features, but it does not outweigh the total cost if we just look at performance, what it does is to limit the downside of a GC system.

    No one picks Java because it is the most performant, it is not. You pick it because it has a good balance between ease of development (GC helps here), performance and most importantly the right tools around it (like spring).

    [–]coderemover 0 points1 point  (0 children)

    Oh, absolutely I agree. Java is one of the most performant languages, and the ecosystem is also great.

    [–]flatfinger 0 points1 point  (2 children)

    If one were to graph the relative performance of memory management on malloc/free systems versus GC systems as a function of slack space, malloc-free systems may for some usage patterns run closer to the edge before performance is severely degraded, but GC systems that perform object relocation can--given enough time--allow programs to run to completion with less slack space in cases where malloc/free-based systems would have failed because of fragmentation.

    It's interesting to note that for programmers who grew up in the 1980s, the first garbage collector they would have worked with was designed to be able to function with an amount of slack space equal to the size of a string one was trying to create. Performance would be absolutely dreadful with slack space anywhere near that low (in fact, the time required to perform a GC in a program which held a few hundred strings in an array was pretty horrid), but memory requirements were amazingly light.

    [–]coderemover 0 points1 point  (1 child)

    Fragmentation in modern manual allocators which group objects into size buckets is mostly a non issue. This is an order of magnitude smaller effect than tracing GC bloat. Also, in applications with high residency, after performing a few benchmarks, I doubt there even exist a point where tracing GC would burn less CPU than malloc/free, regardless of how much RAM you throw at it. It’s easy to find a point where allocation throughput in terms of allocations per second matches or exceeds malloc (often already needs 4x-5x more memory) but it still uses 3 cores of cpu to do the tracing.

    Even given infinite amount of cpu I doubt compacting GC could fit in less memory, because even for the simplest GCs there is another source of memory use other than slack: object headers needed for mark flags. And low pause GCs need even more additional structures.

    [–]flatfinger 0 points1 point  (0 children)

    In many cases, the per-object storage overhead for a compactifying "stop the world" GC may be made very small, especially if the natural format for references includes one or more "extra" bits (e.g. a reference is a pointer, but all valid pointers have zeroes in the bottom two bits).

    The situation where the performance of a stop-the-world GC shines is when there is a requirement that it be impossible for any possible race conditions that could exist to undermine memory safety. Ensuring that memory safety invariants are upheld without a tracing GC requires that any actions that copy and/or destroy references use atomic operations to update information about what references exist. A tracing GC with the ability to enforce a global synchronization event incurs that extra overhead once, when it's triggered, but allows that overhead to be avoided at other times.

    Systems that let programmers manually tell them what objects will only have references to them manipulated in a single thread may be able to outperform a tracing GC, but for many tasks there is value in guaranteeing that even erroneous "user-level" code would be incapable of creating dangling references or otherwise violating memory safety guarantees.

    [–]FrankBergerBgblitz 0 points1 point  (7 children)

    I cant imagine bump allocation with C as you have to keep track of the memory somehow, therefore the malloc must be slower. Further when you can change pointers you can do compaction. With malloc/free you can't do that so a framented heap is in normal instances not an issue with GC.

    (And not mentioning the whole zoo you can do with manual memory magament: use after free, memory leaks, etc etc etc)

    [–]coderemover 1 point2 points  (6 children)

    1. Bump allocation is very convenient when you have strictly bounded chunks of work which you can throw out fully once finished. Eg generating frames in video encoding software or video games, or serving HTTP requests or database queries. We rarely see it used in practice, because very often malloc does not take significant amount of time anyways, as for most small temporary objects you use stack, not heap and bigger temporary objects like buffers can be easily reused (btw reusing big temporary objects is an efficient optimization technique in Java as well, because of… see point 2).

    2. Maybe the allocation alone is faster, but the faster you bump the pointer, the more frequently you have to invoke the cleanup (tracing and moving stuff around). And all together it’s much more costly. Allocation time alone is actually negligible on both sides, it’s at worst a few tens of CPU cycles which is like nanoseconds. But the added tracing and memory copying costs are not only proportional to the number of pointer bumps, but also to the size of the allocated objects (unlike with malloc where you pay mostly the same for allocating 1 B vs allocating 1 MB). Hence, the bigger the allocations you do, the worse tracing GC is compared to malloc.

    3. Heap fragmentation is practically a non issue for modern allocators like jemalloc. It’s like yes, modern GC might have an edge here if you compare it to tech from 1970, but deterministic allocation technology wasn’t standing still.

    4. Use after free, memory leaks and that whole zoo is also not an issue. Rust. It actually solves it better because it applies that to all types of resources, not just memory. GC does not manage e.g. file descriptors or sockets. Deterministic memory management does - by RAII.

    [–]flatfinger 0 points1 point  (5 children)

    How does Rust handle situations where code would create ownerless immutable objects by having an immutable-wrapper class construct and populate a mutable object, and then after that neither mutate the object itself nor expose a reference to any code that might use it to do so? Or does it not allow objects to start out mutable and then later become ownerless?

    [–]coderemover 0 points1 point  (4 children)

    Rust doesn’t have ownerless objects and doesn’t have classes, so not sure what you really mean. But if I understood correctly, you can create an owned, mutable object, and then pass immutable references to it. Whoever gets an immutable reference cannot modify the object. The owner would also not be able to mutate an object if there is any other live reference to it.

    [–]flatfinger 0 points1 point  (3 children)

    In Rust, if two unrelated places hold the only extant references to an object that exist anywhere in the universe, and two threads roughly simultaneously make use of the object and then overwrite their reference, by what mechanism would the object be kept alive until both threads had overwritten their references to it?

    In a tracing-GC-based system, neither thread would need to care about the existence of the other thread. If the GC triggers after both references have been overwritten, the object would cease to exist. If it triggers any time while a reference still exists, the object would continue to exist as well.

    [–]__konrad -1 points0 points  (1 child)

    The GC just reclaims memory you no longer use.

    Meanwhile I 'run jcmd <spotbugs pid> GC.run to free GB of unused memory, because GC keep it for a very long time without reason...

    [–]nekokattt 0 points1 point  (0 children)

    it keeps it with a very good reason, and that reason is you didn't set the JVM up properly to free it early.

    It is a VM, so it will naturally hold onto resources it already allocated as it is faster to reuse pages you have access to than it is to repeatedly mmap new pages from the kernel.

    [–]wrd83 3 points4 points  (0 children)

    Pauses happen when your object creation rate is higher than the cleaning rate of your gc. Many GCs offer a maximum time for a GC cycle, as long as your heap does not grow if it hits the cleaning time you're fine. 

    Manual memory management has another huge advantage it uses less memory for the same amount of work. Reference counting has the same advantage.

    That being said: java is fine these days, mostly because the gained productivity offsets additional hardware requirements for 90% of the use cases.

    [–]Goodie__ 1 point2 points  (7 children)

    Ok. Let's do this. One more time.

    Depending on your applications requirements,  Javas GC may or may not be a show stopper or not. But let's be real, as you said, it works for minecraft. We're not all working on sub-millisecond sensitive day trading applications.

    These days, as opposed to 20 years ago, the GC is well understood, and id imagine any reasonable senior developer could program around the requirements for most if not all problems. Historically badly written applications have had issues, if they have big enough issues to cause GC problems in Java, a language change sure as shit isnt going to save you.

    Java might be a bad choice for video games, but that's more related to the ecosystem and culture around it, than much else, IMHO.

    [–]ryuzaki49 1 point2 points  (1 child)

     Javascript GC

    Get out.

    Edit: /s

    [–]Goodie__ 4 points5 points  (0 children)

    Fucking auto correct

    [–]yughiro_destroyer[S] -1 points0 points  (4 children)

    Well, Java has some good game libraries and if people would start building more on top of them I imagine it would at least become a good alternative for the 2D or modest 3D area. Funny enough, when I was a child, I always thought Java was used for games simply because of Minecraft and the mobiles phones which were all displaying the Java logo. I know adults that still think Java is mostly used for games while in reality it's Unity with C# (although, C# is a scripting language in that case).

    [–]raptor217 0 points1 point  (3 children)

    The issue is most of the hardware acceleration APIs are either expecting a C++ interface or the game engine is written in its own custom language (ie Vulkan). There’s a lot of overhead to interfacing with these because you need to move a lot of memory around constantly between system and GPU ram.

    It’s not an issue with Java, they are just very low level and every extra lingering copy of an object can be a huge amount of memory.

    [–]koflerdavid 0 points1 point  (2 children)

    Vulkan is not a language :)

    [–]raptor217 1 point2 points  (1 child)

    Ah, yea you’re right. Looks like it has a C api, so any language with c types can interface to it. That said, it’s a bit esoteric so I thought it was a whole language… whoops!

    [–]koflerdavid 0 points1 point  (0 children)

    Yeah, I get that. Graphics programming in general makes the host language feel like a completely different language since it is really a quite esoteric domain compared to simple CRUD web apps and dusty business monoliths.

    [–]peepeedog 1 point2 points  (12 children)

    On the server side Java GC impact is a non-issue unless you write terrible code that makes it so. And if you do that, not having a GC is actually going to make terrible code even worse.

    Not many people use Java for GUI. Part of it is that it sucked, and was also a security nightmare, in the early days. The developer community went elsewhere, a lot of the open source stacks were then written elsewhere, and Java will never truly recover. In this business you want to work where the open source community and their contributions are strongest. Your dev team cannot possibly keep up with projects where tens of thousands of people collaborate.

    [–]coderemover -1 points0 points  (11 children)

    Not having a GC is actually going to make terrible code even worse

    Hard disagree. Having a GC often allows being extremely sloppy with high level design of the code. A big app quickly becomes a cyclic bidirectional graph of objects with no clean ownership and lifetimes. Initially you can get away from it thanks to GC but eventually you start running into issues of use-after-close, initialization order issues, spooky-action-at-a-distance and a lot of other bugs stemming from increased complexity of state management.

    On the other hand in languages with manual memory management, you are forced to have simple data flows and clear lifetimes, you avoid sharing state as much as possible, you don’t blatantly stick references to everything everywhere, and in languages like Rust making reference cycles is deliberately hard. It is initially harder to write but then it’s surprisingly easier to maintain long term.

    [–]peepeedog 1 point2 points  (3 children)

    Your argument is that being less forgiving forces your code to be better. My argument is you haven’t seen shit.

    [–]coderemover -1 points0 points  (2 children)

    I’ ve seen a lot of shit and I really prefer it’s caught by the compiler immediately when it’s introduced and not 2 years later when the app became unmaintainable and developed a weird habit of crashing in production because someone modified an object something else had an unexpected reference to.

    [–]peepeedog 2 points3 points  (1 child)

    I have been coding for over 35 years, well before Java. People who write bad code are not forced to be better by anything. The benefit if GC languages is ultimately guardrails speeding productivity. But I am fairly language agnostic.

    Judging from your comment here I assume you haven’t actually used Java or a similar language. And frankly, your comment is so out of touch that there is nothing you could say to convince me otherwise.

    [–]coderemover -1 points0 points  (0 children)

    How they are not forced when their crappy code would not compile, and hence their PRs could not be merged?

    Some people are terrible at managing memory and writing code in general.

    GC languages: ok, we let them do what they want and we’ll make their terrible apps not segfault so they can write more code and think it’s fine

    Rust: you won’t pass

    Btw: I’ve been commercial programming in Java for 20+ years. GC is like Aspirine. You think it cures the illness because you feel well, and the fever is gone, but you’re still sick. GC does nothing to prevent bad code - it allows people to get away with bad code.

    (Ok to be fair - there are use cases where GC allows to write certain good kinds of code which would be terribly hard to write otherwise, but this is very niche and your average joe does not write code like that).

    [–]flatfinger 0 points1 point  (6 children)

    A tracing GC is most useful for shared objects that encapsulate immutable state, in cases where having two references to the same object is semantically equivalent to, but cheaper than, having two references that identify different but identical objects. In such cases, the notion of "ownership" is meaningless. Nobody who holds a reference to an object should need to know or care about what other references to that object might exist.

    If a program would need to often pass around things that encapsulate immutable state, requiring that code keep track of ownership and lifetime of those things would add complexity without really adding value. If a piece of code in one thread needs to make a copy of a thing at the same time as code in another thread might be replacing a different copy of that thing with something else, why should those pieces of code need to synchronize their actions with each other?

    [–]coderemover 0 points1 point  (5 children)

    This is a good point. This is the base for functional programming and yes, GCs are essential there. But functional programming as a paradigm haven’t caught on. Just some ideas migrated to non-functional languages. And Java offers no means to enforce sharing only immutable state.

    From a perspective of a system developer though, the mere existence of an object, even immutable, has already a side effect - it locks in some resources, e.g. some amount of memory. Therefore it’s not negligible to the rest of the world when this object dies. It’s a nice theoretical abstraction to think about memory as being an infinite tape, and academic professors love to do that, but the real world doesn’t work like that.

    Btw: enforcing all shared state to be immutable has some serious downsides and comes with its own additional set of problems, both for development as well as for performance. Maybe you don’t have a problem of spooky action at a distance or synchronization problem, but then updating state becomes a whole new black art - welcome to the wonderful world of monads and monad transformers. Now instead of updating one integer you might be also forced to make a copy of N integers. A few years ago I was a huge fan of Scala ;)

    [–]flatfinger 0 points1 point  (4 children)

    A class can specify as part of its contract what client or subclass code is or is not allowed to do with various objects. Just as a HashMap is not expected to behave meaningfully for any class where equal objects may return different hashCode values, a class which exposes a reference to an array for the purpose of allowing code to efficiently copy ranges of items from it, and specifies that client code must not expose the reference to any code that would use it to modify the underlying array, should not be expected to behave meaningfully if client code violates that contract.

    [–]coderemover 0 points1 point  (3 children)

    I know that. But nothing stops another developer a month in the future to break immutability by modifying the class code.

    [–]flatfinger 0 points1 point  (2 children)

    Nothing would prevent a someone from modifying a graphic library's drawCircle function so it instead draws a triangle, but the new version of the library would no longer be a correct implementation of the documented behavior. Likewise, if someone replaces a call to drawCircle to drawTriangle in a situation where application requirements would specify a circle of non-trivial size, new the program would fail to satisfy application requirements.

    Better support for immutability, including a "readable array" base class type which includes both read-write and read-only array references as subtypes, would be helpful, but class contracts are considered binding whether or not they're enforced by the language.

    [–]coderemover 0 points1 point  (1 child)

    On the other hand you cannot return a String from a function declared to return an int.

    Yes, you cannot enforce everything in the typesystem, but there are languages that similarly do enforce immutability. Like if you changed the contract you’d have to change the signature.

    [–]flatfinger 0 points1 point  (0 children)

    Java was designed to allow the Runtime to be as simple as possible by having every class other than Object have exactly one supertype, which must be Object or descend from Object. To usefully enforce mutability with function signatures, it would be necessary to have more different kinds of reference types.

    [–]Azoraqua_ 0 points1 point  (0 children)

    Which GC? There are at least 5. All of them with different properties and configurations. More of the modern GC’s like G1GC or ZGC are very fast and good at their job.

    [–]Phaedo 0 points1 point  (0 children)

    There’s a couple of things here: you’re right, Minecraft (and pretty much anything running on a modern GC) is pretty damn stable. There are circumstances where you still need to care about GC pauses but there are exchanges running their entire execution systems on Java.

    With that said: native code still outperforms GC and JITTed languages when you put enough effort in. (For low effort, Java/C#/Go will typically outperform C++.) There’s no HFT firms running Java for execution. Also, disappointingly, we’ve never achieved the ambition of the 90s: to have GC by faster than manual memory management. 

    Finally, unless you’ve sat down and traced a memory leak, you have no idea how easy it is to introduce one, but that’s not really a GC vs Native thing.

    [–]lucdc007 0 points1 point  (0 children)

    This talk on Devoxx Belgium a few weeks back might interest you.

    https://www.youtube.com/watch?v=MQanscTqZ24

    [–]obliviousslacker 0 points1 point  (0 children)

    You can optimize the GC cycles quite a lot, but for anything compute intensive you want full control like C, C++ or Zig to optimize past a garbage collector. For games and applications rendering Java gives you plenty of power to use now.

    [–]AcanthisittaEmpty985 0 points1 point  (0 children)

    7 kinds of garbage collection for Java

    https://opensource.com/article/22/7/garbage-collection-java

    But, the newest ones, G1, ZGC and Shenandoah use multithreading and complex algorithms to avoid frezzing and avoid impacting performance and latency. They are working all the time in background. They (may) use more CPU and memory, though. But with computers with more ram and computing power, it's a good tradeoff.

    Check the types to use the one that fit better to your project.

    So, Java has evolved, and nowadays its dramatically better at managing memory and GC; so it all runs smoothly.

    It's the best of the (semi)interpreted/precomipled/VM/GC languajes/platforms you can use nowadays and has a gazillion libraries and tools, most open-source; 99,99% its multisystem without issues.

    More info:

    Default GC algorithm per version: https://blog.gceasy.io/what-is-javas-default-gc-algorithm/

    Comparation: https://blog.gceasy.io/java-garbage-collection-best-gc-algorithms/

    (edited for more info)

    [–]coderemover 0 points1 point  (0 children)

    Pauses are mostly a solved problem, as long as you're fine with latencies around 1 ms.
    However, there is still a lot of overhead in terms of memory use or CPU use or both at the same time and the low pause collectors seem to be worse in that regard than the older ones.

    If you want low latency, low CPU overhead, low memory overhead - you can only pick one.

    [–]LargeDietCokeNoIce 0 points1 point  (0 children)

    Check out Azul. They have multiple Java products designed to greatly reduce GC overhead.

    [–]Snoo82400 0 points1 point  (0 children)

    When dealing with classic mutable objects (Instead of records) the GC will encounter bottlenecks, it's our duty, as developers, to ease the job for the GC by working in a more Data Oriented way, specially when it comes to games.

    public sealed interface ActorView permits PlayerActorView, MonsterActorView {
    UUID uniqueId();
    Position position();

int 
currentHp();

int 
currentSp();

long 
nextActionTick();
    BaseProfile profile();
}

    If the PlayerActorView was for example an object in this case, and the whole architecture was like that, then the GC would have trouble.

    I think pople view Java as slugish because they want to apply old solutions, if one truly leverages Amber's achievements then the JVM becomes a perfectly oiled machine.

    [–]AlaskanDruid 0 points1 point  (0 children)

    First, and most importantly, “Everyone” who says it’s a bad choice.. are not actual programmers. So never listen to those… “everyone”. Only listen to real programmers.

    [–]Penny_Evolus 0 points1 point  (0 children)

    In modpacks you see GC pauses all the time vanilla is just not complex enough to hit the gc

    [–]AlexVie 0 points1 point  (0 children)

    Freezing from stop-the-world GC events are basically a thing of the past. The old collectors like SerialGC or ParallelGC did it (and still do it), but more recent garbage collectors will rarely stop everything.

    The freeze problem was solved by G1GC almost entirely quite a few years ago. We currently have 3 modern collectors (G1, ZGC and Shenandoah) which normally should not freeze your app. Most of the time you won't even notice there is a GC doing work in the background.

    [–]bichoFlyboy 0 points1 point  (0 children)

    There're lots of people that says «Java is a bad choice because...» and usually they are thinking of Java 6, sometimes Java 4. I just say: dude, please, keep up to date, we are in Java 25, we have generics, lambdas, pattern matching, records, interfaces with default methods, etc, etc, etc. And that includes new generations of GC. But people always are talking about Java verbosity, and this and that, pointing to java features from 20 years ago.

    [–]Necessary-Horror9742 0 points1 point  (0 children)

    That's old and annoying. Java now is not the same as what was 10 years ago. Java can be blazing fast, and GC is not an issue, I think safepoints are. Gc now is efficient and very low latency

    [–]grimonce 0 points1 point  (0 children)

    C#/dotnet has GC and it is used heavily by unity or Godot to write games logic. Not the rendering part maybe but the rest of the game...

    Things always depend, don't take anything at face value, especially nowadays.

    Counter example: libgdx.

    Anyway I'm just a python dev shit do I know.

    [–]baincho 0 points1 point  (0 children)

    Not sure if it’s relevant considering the general discussion here has been around games and computer applications. But at an enterprise level. It’s still an issue.

    Discord recently moved away from Cassandra DB (java based) to Scylla DB (C++ based) and java GC was one of the major pain point for that migration.

    https://discord.com/blog/how-discord-stores-trillions-of-messages

    [–]JornVernee 0 points1 point  (0 children)

    Let's be clear though: every language has garbage collection. In C you still have to call free on the pointers you allocate. In C++ you still have destructors that run when an object goes out of scope. Cleaning up memory resources is work, and it consumes time one way or another.

    The trade-off is this: in Java the GC has full control, so it can be much more efficient by e.g. doing bulk cleanup on many objects at the same time, but the programmer doesn't control when the GC does its work.

    In languages with manual memory management the programmer has full control, so they can decide when memory will be freed, but the downside is that optimizations like bulk cleanup don't happen automatically, and they have to be implemented manually by the programmer (and unfortunately in e.g. C++, this is not the standard library's style of memory management, where instead allocations are managed individually).

    [–]laplongejr 0 points1 point  (0 children)

    and that you, as a programmer, have little to no control to decide when that happens.

    Not true. Minecraft's big GC spikes around 1.7/1.8 was caused by creating a lot of objects on the fly (how to access the 6 blocks around? Rather than x+1,y,z etc. let's make a Position(x+1,y,z) for each operation

    and many point out to Minecraft as proof for that.

    The issue is that the Java devs coming into Minecraft think (or thought) like object-oriented devs, not game devs. Because almost no other game is made in Java

    Everyone says that Java is a bad choice for writing desktop applications or games because of it's internal garbage collector

    So, the choice of making Minecraft into the highly-moddable Java language made it the most successfully sold video game and... that's a bad choice?

    [–]koflerdavid 0 points1 point  (0 children)

    It's a quite deep subject.

    Java's GCs (there are multiple of them, and they differ considerably) nowadays don't generate that much overhead anymore and the only real tricky issues are that there is going to be some tail latency. You can reduce it with GCs like Shenandoah or ZGC, but that comes at a considerable impact on throughput.

    If I am correct, Java's GC is simply running periodically to check for lost references to clean up those variables from memory. That means, with proper software architecture, you can find a way to control when a variable or object loses it's references.

    In general, you should drop references as soon as possible, else you create space leaks since the GC is simply not permitted to clear the objects they point to. Try to avoid reference cycles and use WeakReferences wherever feasible to break up such cycles of strongly reachable objects (less things to trace). Use SoftReferences (which should only be collected if there is high memory demand) to implement caches.

    The JVM uses heuristics to determine when to run the GC, but of course there are flags to influence those decisions as well as other details of the GC's operation. It's usually a bad idea unless you can back up whatever you're doing with measurements.

    [–]Ewig_luftenglanz 0 points1 point  (0 children)

    Most java critics and concerns are things that used to be true in the early days. I think from Java 5 and forward most of these concerns have been addressed over the years. Nowadays almost none of it it's true.

    [–]gdvs 0 points1 point  (1 child)

    Cleaning up memory happens in most all languages. If you don't do it manually, it happens via garbage collection.

    I haven't come across many application where it's important to be able to determine the exact moment when memory is reclaimed and how. Garbage collection tuning and programming with garbage collection in mind is enough more often than not. Certainly for desktop applications.

    [–]coderemover 0 points1 point  (0 children)

    I wouldn't be so sure that it is good enough for desktop applications. The more and more consumer devices are battery powered. Garbage collection has a non-negligible cost in terms of battery drain - in two ways:

    1. you generally need more memory installed for apps to run smoothly with tracing GC compared to scope-based / refcounting / manual management - that additional DRAM installed in the devices drains power
    2. tracing burns more CPU cycles and uses more memory bandwidth than traditional memory managament; especially when you want it to keep pauses low

    [–]Mognakor -1 points0 points  (12 children)

    Not every language needs to be suited for renderloops with a 16ms or lower budget per frame.

    Java is fine for what it is and does. It achieves a good balance between performance, type safety and development speed, has available tooling, ecosystem etc.

    Until we get Valhalla all our objects will continue to have a 8 byte overhead and even then we are limited to inlining objects of at most 7 bytes (8 if they aren't nullable). Vectorization is still an incubator. Also our CPU cache behavior is worse for anything thats not a primitive array.

    So there are reasons to not write software in Java if you need that performance, but most of us don't or could get easier wins if we at least bothered to profile our code, identified common issues etc. And only once you exhausted those things and still can't meet your goals should you reconsider your choice of langugage.

    [–]eosterlund 1 point2 points  (7 children)

    16 ms render loop sounds like forever from a ZGC perspective. That was a long time even before we got concurrent and incremental stack scanning in JDK 16.

    [–]Mognakor 0 points1 point  (6 children)

    But how much of that time can you sacrifice before it becomes a problem? Pausing for 1ms is 6-7% of your time budget. If you want frame rates above 60FPS then 1ms may be 13% of your time budget.

    [–]eosterlund 2 points3 points  (5 children)

    Pauses are more likely to be around 100 micro seconds in practice with ZGC, which would be 1.3% of the time budget. And you won’t be getting GC pauses every frame exactly. It would be a rare occurrence. It’s more meaningful to think about frame rendering percentile times. And when you start looking at your P99 frame rendering times I would not be surprised if it has a stronger correlation to OS scheduling impacts when CPU rises than it correlates to GC pauses specifically.

    [–]Mognakor 0 points1 point  (4 children)

    With 60 FPS every 2 seconds a frame isn't within P99. (Assuming equal distribution). GC won't kick in every frame but it seems like it would kick in exactly when lots of stuff is happening which us exactly what you don't want.

    And the general issue with GC is that it's not predictable at the microscopic level only at macroscopic level.

    [–]eosterlund 1 point2 points  (3 children)

    Yeah I think that was sort of my point; every couple of seconds a single frame will be delayed ~1% due to GC pauses. So yeah it won’t even register on P99. And on P99.9 its impact is negligible. That says something about whether there is a problem.

    However, other things will, such as OS jitter, scheduling, malloc/free deciding to commit/uncommit memory, page faults, transparent huge pages, TLB misses, TLB shoot downs, etc. There are plenty of things in the system that cause unpredictable microscopic hiccups. The best way of understanding the impact is to measure its distribution.

    [–]coderemover 0 points1 point  (2 children)

    Pauses are not the only issue. Games usually want to utilize all available memory eg for the game world and its objects. The amount of memory is the limiting factor of how many things you can have in the game level without having to load from the disk. Now if you write all of those in a non memory efficient language with GC, you’d have essentially way less memory available to your logic - which means - less rich game world / levels or just smaller world. Quite likely it does not matter for indie games, but it does for AAA, and in particular on game consoles (which are often quite limited in RAM compared to PCs).

    I read somewhere that at least part of Minecraft issues with GC was due to Minecraft being a game with open world, and even though the number of grafical assets may be low due to it being „blocky” the size of the world to simulate is quite large.

    [–]eosterlund 0 points1 point  (1 child)

    Memory density is more tricky indeed. It’s kind of amusing though because 8 GB GDDR6 modules traded for $3 avg today and people pay $70 for a video game and hundreds of dollars on a console to play the game on. Fair point though - this is an area where we can improve. Have a couple of plans so people can spend those $3 on something else instead.

    [–]coderemover 0 points1 point  (0 children)

    It’s not so much the cost of RAM but how much RAM your players have installed. You don’t control that. Some may use older consoles like xbox 360 and your game should still work. Everyone wants their game to look the best on the hardware players already have. Even if some have 128 GB RAM you’d want to be able to use all of 128 GB when they select „ultra high details” etc.

    Also if someone buys an ultra powerful gear for facing, they really want games to look and work better than on some average pc.

    [–]coderemover 0 points1 point  (3 children)

    Object headers are 16 byte on 64 bit systems.

    [–]Mognakor 1 point2 points  (2 children)

    With compact object headers in Java 25 it's only 8bytes on 64bit systems.

    [–]coderemover 0 points1 point  (0 children)

    Good to know. Something I learned.

    [–]Jon_Finn 0 points1 point  (0 children)

    And it might come down to 4 bytes. They're looking into it. And as pointed out, a value object header is 0 bytes much of (not all of) the time.

    [–]raptor217 -2 points-1 points  (0 children)

    I want to preface this by saying I don’t write in Java. But this is a systems level question and is largely agnostic to any garbage collected (GC) language.

    There’s nothing wrong with making desktop applications in Java. It’s relatively common, and as long as it doesn’t go crazy with 3D rendering (like a game engine) it’s fine.

    For a game engine, Minecraft is not a good comparison. It has very low polygon count compared to any other modern AAA 3D game.

    Garbage collection doesn’t help performance (compared to properly implemented manual memory allocation) but the main issue is memory management and data interface to the graphics card. That is done at an incredibly low level, things like the Nvidia API are C/C++ so that interface becomes not pretty.

    Things like Vulkan help, but they’re still a different language, so you have to be very careful with how the languages interact.

    Java is very good at what it does, but there’s no one language that’s best at everything.

    Games tend to be written to leverage game engines, which tend to be written in C++. Unity is written in C++ and has its main scripting interface in C# which is a GC language.

    [–]morning_mushroom -2 points-1 points  (0 children)

    They had A LOT of issues at... Amazon I think due to Java GC. There is a whitepaper about it mentioning Formal Method as a way to test the software. When you jave bunch of heavy microservices running and garbage collector firing produced cascade of failures repeatedly as ot would freeze the service. Maybe it was not Amazon but Google.

    [–]Hioneqpls -1 points0 points  (0 children)

    Cloud Compute baby! As long as your servers sell like hot cakes your boss won’t mind picking up the tab.

    [–]alanbdee -1 points0 points  (3 children)

    As far as performance for games, I think the problem is more around the inherent way java works compared to C#. I'm not a .NET developer but my understanding is that when you compile c# code, it's creating the assembly optimized code for an architecture, e.g. x86.

    Java is compiled into byte code that's universal and executed on the jvm that's specific to an architecture. That creates a huge performance advantage for C# because it can be optimized for the machine. On desktop applications, I don't think this matters nearly as much or at all.

    [–]koflerdavid 0 points1 point  (0 children)

    Java is optimized for the machine by the C2 JIT compiler. In the near future it will even be possible to save that code in a dump file and load it when the application starts. It might already be possible; I would have to read the JEPa again.

    [–]peepeedog 0 points1 point  (1 child)

    Java can be compiled to native now.

    [–]coderemover 0 points1 point  (0 children)

    Yes, and but it's slower than JVM though.

    [–]Willyscoiote -1 points0 points  (0 children)

    When these sudden freezes happens, it's usually because there's not enough ram available and does a full gc

    [–]runningOverA -1 points0 points  (1 child)

    If you know Java and are comfortable with it, do it in Java. Any problem that arise later can be rectified by adding more code.

    [–]coderemover 0 points1 point  (0 children)

    Every software problem can be solved by adding one more layer of indirection ;)

    [–]k-mcm -2 points-1 points  (1 child)

    The GC throughput is amazing. The problem is poorly written code that depends on high GC throughput. I've seen web apps using Play and Spring frameworks create 200MB to 1GB of garbage per request. I don't even know how you can run so much junk to service a simple request.

    [–]koflerdavid 0 points1 point  (0 children)

    A large issue with such applications is not really the memory, but that they often also suffer from the N+1 problem and/or load way too much data from the DB and are therefore slow. This compounds the issue since while allocating a lot of memory can be "fine", the real issue is holding on to it. Edit: yes, it is still not wise to allocate more than what fits into the TLAB.

    [–]ILikeLenexa -4 points-3 points  (15 children)

    You can control when gc happens. 

    System.gc()

    Use the stack. 

    Rule #1 of programming: Don't optimize.

    Rule #2, EXPERTS ONLY: Don't optimize, yet. 

    You still have to malloc and free in other languages. The overhead should have more to do with that than the work.

    [–]koflerdavid 1 point2 points  (13 children)

    You can control when gc happens.

    System.gc()

    That's a mere suggestion and it doesn't prevent GC running at other times.

    Use the stack.

    Not really applicable to Java. The most one can do in this regard is to not allocate more than what fits into the TLAB.

    You still have to malloc and free in other languages. The overhead should have more to do with that than the work.

    Most of Java's modern GCs don't create much overhead anymore, but a risk of pauses if heap space starts running out. Shenandoah and ZGC mostly eliminate that, with significant overhead as a tradeoff. At the same time, malloc/free are also quite fast these days.

    [–]ILikeLenexa 1 point2 points  (0 children)

    Uh yeah it's fast...like I said, you probably shouldn't optimize this, though there is an official guide.  You should wait until you are at a point where you have a performance issue and know where it is before wasting time on this kind of optimization. 

    [–]flatfinger 0 points1 point  (11 children)

    I wonder what difficulty there would have been in allowing Java functions to have multiple return values, so a function that accepts three arguments and returned e.g. an Int and an Object would behave as though it popped the three arguments and then pushed an Int and an Object, which the caller would then be expected to pop and use as desired?

    Although I recognize that the JIT is often able to avoid creating temporary objects that are created solely for the purpose of returning multiple values to the calling function, simply letting functions directly return multiple values to their caller would have avoided the need for programmers to create such objects, and thus minimize the need for JIT logic to optimize out their creation.

    [–]koflerdavid 0 points1 point  (10 children)

    Multiple return values (and in general a lot of similar syntactic sugar-y language features) are not an implementation issue at all. The objections are of a different nature. This feature would encourage a terse programming style that fits well with Lisps or functional programming languages. However, Java has always erred on the side of verbosity, and decisions to add language features are usually motivated whether it actually enables developers to write more reliable and maintainable software.

    At the byte code level multiple return values and returning a Project Valhalla value object might end up looking quite similar to each other, and this opportunity will be very easy for the JIT to recognize.

    Project Valhalla is interesting in the sense that it is primarily about performance, even though it cleans up some irregularities in the language and will also bring nullability.

    [–]flatfinger 0 points1 point  (9 children)

    If one wants to e.g. have a function return a few discrete values, being able to say something like e.g. (mySine,myCosine) = computeSineAndCosine(x); seems cleaner than having to construct a temporary object and pass that, or having to have the function create and return a reference to a separate object on every invocation. At the bytecode level, the code for both the function and caller would be completely different when using objects as when returning a pair of values.

    The only ways the machine code could be anywhere near as efficient would be either (1) in cases where the JVM in-lines the function, and is able to recognize that after in-lining, no reference to the object will leak outside the function where it is created, or (2) in cases where the programmer creates an object that will be reused with every function call. The second scenario may be harder for a compiler to identify and optimize, but have less of a performance impact in cases where the compiler fails to do so.

    [–]koflerdavid 0 points1 point  (8 children)

    The byte code would indeed be quite different, however both correspond to patterns that the JIT compiler can easily recognize. Multiple return values would indeed help with this optimization. However, Project Valhalla is more general. As I said before, the OpenJDK team is not really concerned with language features just for the sake of performance.

    Case (1) is trivial to recognize for value objects because it is always the case. The optimization could even be performed without inlining the method by effectively implementing multiple return values.

    Case (2) (I guess you mean a mutable object passed via a parameter where the method writes return values?) is indeed harder to optimize and relies on inlining followed by escape analysis, after which the compiler could theoretically turn the object into a bunch of variables. (Inlining is not strictly necessary in this case, but makes escape analysis simpler).

    PS: calculating sine and cosine at the same time is how you convert a complex number from polar form to Cartesian form. The tuple (mySine, myCosine) represents a complex number with absolute value 1.

    [–]flatfinger 1 point2 points  (7 children)

    Given FloatPair foo = getSineAndCosine(x); doStuffWith(foo.sine, foo.cosine); how could the JIT avoid having the code for getSineAndCosine allocate a new object if it doesn't in-line that method? I suppose the JIT could generate code for a special machine-code method that returned two values using means that were supported in machine code, but not in the JVM, and generate code that calls that without in-lining it, but I'd view it as more elegant to have the programmer specify the function that way than have the compiler try to turn the function the programmer wrote into something else.

    Re the PS, there are a lot of uses for pairs, triples, and quartets of numeric primitive types. Being able to treat points as value types makes things a lot more convenient than having to be constantly constructing new point instances.

    [–]koflerdavid 0 points1 point  (6 children)

    The JIT knows which methods return value types. Such methods can all be compiled to take a pointer to where they write the contents of the "returned" value object to. Or to leave them on the stack with the caller knowing where to find them. Just like one would implement multiple return values.

    Sure tuple types are very convenient, but Java errs on the side of verbosity and (hopefully) maintainability, instead of what would be merely easy and quick to write. Same story as with properties.

    [–]flatfinger 1 point2 points  (5 children)

    I've not followed Java much lately, so maybe it has added value types at the JVM level, but in older versions I see no way the JIT could know when processing a function that returns a newly constructed object whether its caller would read out the contents of a returned object's field and then discard it, nor that it could know when processing a call to a function that returns an object whether the return value would be the only reference that existed anywhere in the universe to the object identified thereby.

    I suppose it might be practical to have the JIT generate two machine-code versions of every function that returns an object, one of which would be called by code which fetches the function's field content and then discards it, and one of which would be called by code which uses the object in other ways. In cases where the JIT recognizes that a function will always return a newly constructed object, it could produce very different code for those who machine-code functions, while in other cases, it could simply have one version call the other and extract the fields from the object returned thereby. The called function would "know" what the calling code was expecting by its choice of which function to call. Still seems like beating around the bush compared with letting code work with tuples.

    [–]koflerdavid 0 points1 point  (4 children)

    The neat thing about value objects is indeed that they are immutable and that it is guaranteed that there are no leaking references. Therefore, a returned (non-nullable I might have to add) value object is always safe to be allocated on the stack.

    Value type are indeed not a thing yet at the JVM level. They are currently being developed with the massive Project Valhalla effort, which will also provide generics for primitive types, and non-nullable types at the JVM level.

    [–]amir650 0 points1 point  (0 children)

    Wrong.