6 ms·
Bending pause times to your will with Generational ZGC
- WJW 3y agoI find it incredible how much design room there is in GC research and how much is as yet unexplored. In my opinion, GC (and relatedly, event loop scheduling) are often way too integrated in a language runtime. I would love seeing this become more configurable, and am glad to see developments in this direction like the fiber schedulers in modern Ruby and custom allocators in Zig. I once inquired about making the Haskell IO manager configurable at runtime but the GHC maintainer team was extremely apprehensive about it because they feared that they would be on the hook for any bugs introduced by third-party IO managers. As it is, Java gets all the GC research love while most other languages make do with very basic GC algorithms. It doesn't have to be like this.
- rbranson 3y agoThe reason is that runtime design forms the constraints of the GC design. Java allows relocating objects, Go does not. Go allows interior pointers, Java does not. These decisions have deep impact on GC design. Something this performance critical needs to be tailored to the runtime.
- felixge 3y agoAFAIK Go’s spec allows relocating objects. The door towards a moving GC is kept open.
- _old_dude_ 3y agoThere are so many packages that only work with GODEBUG=cgocheck=0 that practically that door is closed
- memco 3y agoIn that same vein of thought Nim recently launched version 2 of the language which makes the ORC GC the default with options to use a few others. I don’t know if there’s new ones on the horizon but there’s already plumbing in case that’s an interest for you to explore further.
- pjmlp 3y agoWhich is a reason why randomly talking about programming language capabilities with automatic memory management is nonsense, without actually looking into the details. Unfortunately that is exactly what the manual memory management crowd does.
- mynameisnoone 3y agoErlang enters the chat to brag about efficient HiPE GC by tying objects to processes. Pony enters the chat to brag about ORCA. Rust enters the chat to brag about precise memory management without GC per se. Those bastards!
- pjmlp 3y agoYour Erlang and Pony examples use automatic memory management and only reinforce my remarks. Additionally, linear and affine type systems isn't the same as manual memory management.
- exabrial 3y agoWhat sort of heap sizes does g1 vs zgc really start to make a difference?
- jeffbee 3y agoYou can try to explain to people that enabling Transparent Hugepages is going to win them 5-20% CPU throughput and they just won't believe you.
- ladberg 3y agoSome articles explaining huge pages for anyone curious (and hopefully people will trust that a high frequency trading firm has enough money on the line to get this right): https://www.hudsonrivertrading.com/hrtbeat/low-latency-optimization-part-1/ https://www.hudsonrivertrading.com/hrtbeat/low-latency-optim... https://www.hudsonrivertrading.com/hrtbeat/low-latency-optimization-part-2/ https://www.hudsonrivertrading.com/hrtbeat/low-latency-optim...
- dataflow 3y agoDoesn't this depend on your usage pattern?
- crotchfire 3y agoSoftware people desperately want to believe that MMUs come at no cost whatsoever. A few of them accept that they have a cost, but insist that it is totally predictable and deterministic. You can't talk them out of these beliefs. I have tried. They just get very angry at you.
- mynameisnoone 3y agoEveryone knows 4 KiB memory pages just magically appear in the page table and OS kernel data structures with exactly the same computational and storage complexity as 1 GiB ones. /s in case it wasn't transparent. It's stupid egotists who get emotional and defend their "alternative facts".
- onetimeuse92304 3y agoThat is unfortunately my reality working with other Java developers. I mean, it would be if it actually wasn't even worse than that. They are constantly pushing to create more "microservices" which is just just a misguided trend to spread your functionality over as many machines as possible and have your user wait until a graph of a hundred network calls finishes to get any simplest thing done. Then they spend huge amount of time trying to resolve performance issues and call me, a "performance expert", to try to help find ways to improve the situation. Then dismiss my calls to maybe modularize their applications using regular programming language mechanisms like interfaces and packages. Anyway... it's been quite long since I met a Java dev who even knows what MMU and TLB is. It's a rare candidate who knows what is a virtual memory in the first place.
- KingOfCoders 3y agoJava has been pushing out new and better GC constantly the last decades. I wish Go would invest in GC the same way Java does.
- zigzag312 3y agoSame for C#. It's a little weird that it's used in games, but doesn't have a low latency GC.
- neonsunset 3y agoC# needs GC less desperately so than Java because of structs, stack allocated buffers, heavy use of all manners of object pooling and easy access to malloc and free (which Unity uses in the form of NativeArray). You can achieve drastically lower allocation rate in C# (or no allocations at all if you really need to).
- indolering 3y agoThere are similar strategies employed by high frequency traders using Java. Not as ergonomic as in C# (which I believe had this as a forethought) but interesting all the same.
- pjmlp 3y ago.NET has been designed since the beginning to handle C++, C# already had some of the features but not all of them, in some cases it was needed to emit MSIL, or use Managed C++ on .NET 1.0, or C++/CLI since .NET 2.0. The improvements on C# 7 and later are exactly to avoid emiting MSIL manually, and also cut the dependency on C++/CLI, as it is Windows only.
- rwmj 3y agoDon't forget third parties like Azul. At one point they even had hardware assisted Java GC.
- mynameisnoone 3y agoWondering if anyone here runs Azul's C4 in production and how it compares to ZGC.