![]() ![]() These are some of the surprising things that our users have in their testimonials. If you have a system where you have lots of parallelism, meaning you have lots of free CPUs, and you can just say “I have 16 CPUs, and I can dedicate 2 of those CPUs for doing GC work”, then it might be a better tradeoff for you than accepting a stop-the-world pause in 8 application threads. Now, it is not specific to Shenandoah, it is a property of concurrent collectors. For some misbehaving applications, or applications that do lots of weird stuff around finalizers and suchlike, you can have larger pauses, but normal regular Java applications usually enjoy very, very, very low pause times. It routinely runs with pauses around and about one millisecond. If you’re still not meeting your pause time guarantees and the GC pauses are still significant contributors to the latency that break your performance targets, then you will have to consider a fully concurrent GC. If your pauses from Parallel are not fitting your requirements, I would say then you can go to G1, and starting with JDK 9 you would get it by default. In many cases, you can get away with fully stop-the-world collectors like Parallel or Serial if your application allows it. ![]() Richard: So, what would you say the scenarios are where Shenandoah is best? What would you say were the scenarios where people should try and use Shenandoah versus scenarios where maybe it’s weaker?Īleksey: One important thing to realize is that OpenJDK collectors are actually quite nice. Technically, we could say that if you want a low latency collector, you have to update to the newest JDK, but this argument usually lands on deaf ears because updating the JDK, even after 9, is tedious. We upstreamed it in JDK 12 and maintain it in mainline since then, and we also ship backports to 8u and 11u because this is where our users are.Īleksey: That turns out to be a real problem for users. Since we are in this business to help customers, we are not only doing the current JDK version of Shenandoah (which is JDK 13 at this point). We've been doing Shenandoah for a while, and it left us with lots of JDK flavors. CMS does concurrent mark and sweep, but then you get memory fragmentation at some point, and you will have to face the music, actually dive into stop-the-world compaction of the heap to resolve those fragmentation issues. You can go without those other concurrent phases like CMS does, for instance. G1 has had concurrent mark for a while, but Shenandoah also does concurrent compaction, and then concurrent update references that solve the rest of the pause problem for the application. It is a regionalised collector like G1 and it is fully concurrent, meaning that it has all the concurrent phases. ![]() It has a long development history, it started way before I joined Red Hat and that project. Shenandoah is a project that targets to create a low latency Garbage Collector for Java. Perhaps you could just do a brief introduction of what Shenandoah is for readers out there?Īleksey: Sure. Richard: So let's move on to the other half of your work at Red Hat which involves Shenandoah. In Part 2 of Opsian's interview with Aleksey Shipilëv we discuss his work with Shenandoah, the concurrent Garbage Collector for Java and the reasons why we're seeing a new wave of state-of-the-art concurrent Garbage Collectors. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |