19 ms·
> GC’s SPECjbb 2015 throughput numbers are roughly comparable with the Parallel GC (which optimises for throughput) but with an average pause time of 1ms and a
by nicktelford 8y ago
> GC’s SPECjbb 2015 throughput numbers are roughly comparable with the Parallel GC (which optimises for throughput) but with an average pause time of 1ms and a max of 4ms. This is in contrast to G1 and Parallel who had average pause times in excess of 200ms.
Not bad! Looking forward to seeing how this performs with a diverse range of workloads as it matures.
- earenndil 8y agoI wonder if that would make java more suitable to game development since pauses need to be <8ms, ideally.
- mysterydip 8y agoFor a subset of developers, definitely. Overall I don't think it would lead to significantly more adoption, as the main draw (write once deploy everywhere) is already accomplished by engines like Unity.
- pjmlp 8y agoJava is already suitable for game development, specially with LibGDX. Not everyone needs to try to write the next Crisis in it. It certainly has higher performace than all those HTML 5 and Flash games. The biggest problem is that jMonkey is the only RAD tooling available and no match against any of engines that make use of C#.
- jlg23 8y ago> Java is already suitable for game development, specially with LibGDX. I think it is safe to assume that under "game development" most people understand rather high performance demands, not a solitaire clone (esp since the comment you responded to pointed out pause-times as crucial).
- gameswithgo 8y agoYou can also make a 3d game of large scale, and just let it have hiccups occasionally and still make a billion dollars. Of course those of us hosting servers for that particular game would have saved a ton of money and pain if they had not used Java, or used Java more cleverly.
- thomasz 8y agoAllocating every 3d coordinate on the heap probably wasn't a good idea.
- pjmlp 8y agoThe point is that they should have used Java more cleverly. One can make a game in C++ and make it just as bad.
- gameswithgo 8y agoThe lack of value types makes the code quite unwieldy to control memory layout vs C++, or C#, or Go, or Rust or anything
- pjmlp 8y agoAgain, not every game needs to be the next Crysis.
- sudhirj 8y agoWasn't Minecraft originally written in Java? Might still be.
- pjmlp 8y agoYes, but Microsoft ported it to C++ as means to have a common code base across mobile devices, game consoles and desktop computers.
- Cyph0n 8y agoYes. But I believe that Microsoft made an improved version written in C++ after the acquisition.
- freeone3000 8y ago"improved" is a matter of opinion. The Java version has mod support and the editions are kept at feature parity.
- imtringued 8y agoI remember when they promised a modding api... Not even the C++ has resulted in one... The fact that Notch went with Java might have been a blessing in disguise because it made the reverse engineering process semi automated.
- earenndil 8y agoMinecraft also has generally awful performance (although this is generally attributed to its being coded poorly, not java).
- pjmlp 8y agoThat is known AAA game development.
- nicktelford 8y agoI think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.
- shanxS 8y agoCan you please elaborate?
- pkulak 8y agoIt's just an object that lives on the stack, not the heap. In lots of languages when you create an object, it's pretty explicit where you're putting it. When Java was created, they wanted to get rid of that complexity, so primitives always go on the stack and objects always* go on the heap. * I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, it will go on the stack and won't add work for the garbage collector.
- chrisseaton 8y agoYou mention it in your footnote, but objects don't necessarily live on the heap - they can also live on the stack, or in registers, or in vector pipelines, or not at all. Also an interesting aside is that objects are never 'allocated on the stack'. As in you won't find the same layout of memory on the stack as you do on the heap. Instead objects are turned into data edges in the compiler's graph. It's much more abstract than literally doing an alloca.
- pgwhalen 8y agoFor further details on how objects are not exactly allocated on the stack: https://shipilev.net/jvm-anatomy-park/18-scalar-replacement/ https://shipilev.net/jvm-anatomy-park/18-scalar-replacement/
- electrum 8y agoIt's more about the memory layout than where the objects live. For example, consider a Point class with (x, y) members. If you have an array of these, each element in the array will be a reference/pointer to a separately allocated Point instance which can be anywhere in the heap. Accessing the array is expensive due to lack of locality (arbitrary memory access). Additionally, each instance has substantial object overhead (typically 8 or 16 bytes). There are various ways to deal with this. One way is to have separate arrays for x and y. Another way is to use a byte array and use Unsafe to read/write the integers. This is terrible from a developer standpoint and is only acceptable if it is a small part of your application. Value types solve this by giving you an efficient memory layout while still allowing you to code against them as normal. The slogan is "codes like a class, works like an int".
- HohPum1l 8y agoOn smaller heaps it was already possible to get 5-10ms pauses with the (now deprecated) CMS collector. Unlike Z it was a non-compacting collector though and had some ugly worst-case behaviors.
- ADefenestrator 8y agoYeah, CMS is great until it isn't, and then it ruins your whole day. A bit of a black art to get tuned well, too, and when your workload changes slightly your tuning is no longer effective and the world stops for 30+ seconds. Hopefully ZGC will be more like G1 in terms of "feed it some extra memory and set a latency target" being all the tuning you need most of the time.
- phakding 8y agoI worked for a company where we had a 100-150 microseconds order latency. We had to tune jvm to extremes. But it is very doable to optimize Java gc for low gc pause times.
- snaky 8y agoIf you used to tune JVM only, that might be interesting. Most often the Java code is what being tuned - to the point where there is no point to use Java - with (almost) no gc, off-the-heap memory allocations and all that jazz.
- dnomad 8y agoThis doesn't make much sense. Using object pools and and off-heap data structures doesn't warp the code that much, if at all. You still end up with pretty much all clean, simple Java code. I've seen (10+ years old) low-latency Java apps where people avoid using any OO (ie everything is static methods)... and even then the code was still often easier to maintain and understand than equivalent C++ applications. Nobody does this any more anyways.
- branchless 8y agoThere are more java developers you can educate to do this than good c++ dev. Plus the tooling is better in java.
- phakding 8y agoIt's not either/or. Everything needs to be tuned to achieve the final latency requirements. This includes tuning java code to eliminate creating "garbage", immutable string objects mostly, unnecessary object creation, creating short lived objects compared to long lived etc. The other part right sizing jvm generational partitions, using right gc algo etc. Next part would be to find out the code path with lowest latency requirement and making it hot/jitting. Even next part would be to tune OS for things like thread pinning etc etc. You can go further and tune the network layer. Every little thing counts. You can go even further and employ what's called mechanical sympathy (https://mechanical-sympathy.blogspot.com/ https://mechanical-sympathy.blogspot.com/) and write your code in a way that makes it easier for the processor to process faster. I've never worked with application that use off-heap allocations or no-gc requirements.
- VikingCoder 8y agoHrm, I would think that if you were developing a game in a GC environment, where GC timing turned out to be a problem, you would get rid of dynamic memory allocation, and try to do everything much more like embedded system programming with fixed memory blocks...? I suppose at the complexity of modern games that's simply not possible anymore...
- gameswithgo 8y agoYou can do that, and people do. However a GC language doesn't normally give you the flexibility of getting a block of memory and doing whatever you want inside it, instead you use things like object pools.
- pjmlp 8y agoSystem.Runtime.InteropServices.Marshal in C#'s case.
- louthy 8y agoAlso `fixed` in C# [1] Not used Span<T> and Memory<T> [2] in anger yet, but they also seem to be attacking the issue from the other end [1] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/fixed-statement https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... [2] https://blogs.msdn.microsoft.com/mazhou/2018/03/25/c-7-series-part-10-spant-and-universal-memory-management/ https://blogs.msdn.microsoft.com/mazhou/2018/03/25/c-7-serie...
- VikingCoder 8y agoI consider object pools to be well within that family of problem solving that I'm talking about.
- jakewins 8y agoYou can allocate a block of memory with `ByteBuffer.allocate()` or, if you want it outside the JVM heap, `ByteBuffer.allocateDirect()`. You lose all the object/memory management features, though there are some projects around to provide struct-like APIs: https://github.com/alaisi/nalloc https://github.com/alaisi/nalloc
- jblow 8y ago8ms? Where do you get that number from? If your player has a 144Hz monitor then your pause time, rounded to the nearest millisecond, has to be 0ms.
- vilhelm_s 8y agoWhere do you get your number from? 1/(144 Hz) is 7ms. 1/(60 Hz) is 17ms.
- jblow 8y agoI get my number from decades of professional game programming. In a 7ms frame, you are spending most of that frame doing the work of rendering the actual frame (unless your game is so trivial that the GC is going to be easy / fast anyway). An additional millisecond is going to cause you to miss your deadline and drop a frame. Dropped frames feel really bad.
- Scoping_dindus 8y agoI nearly spit my drink out from that dudes response, because I just happened to peek at your username as I was reading. It's a crazy place here on HN.
- gravypod 8y agoThis sort of stalling is only caused by extremely short lived objects. Pooling and provisioning your data ahead of time goes a long way to fixing these specific issues to the degree that they become unnoticeable. There's a lot of tooling built into LWJGL to support this along with their own vector classes which are easily reclaimed. Also has it really been a decade since Braid? Wow.
- jblow 8y agoThis is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable). Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!" That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. Once you are saying actually, GC won't do that for this class of application, then really what you are getting out of GC is memory safety (provided the rest of the language is memory-safe). On the one hand, hey, memory-safety is a benefit. On the other hand, I don't think very many people in game development would trade that much performance just for memory safety. (And in fact in game development we very often have to do unsafe memory things. So really what ends up being said is "much of the system has memory safety" which, really, does not sound very alluring.)
- deleted 8y ago[deleted]