Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pron on Wednesday August 05, 2020 @09:42AM
(#24060626)
Scanning is most certainly done concurrently with ZGC. Even root scanning is on its way to become fully concurrent, which is why we're nearing the goal of <1ms latency.
[ Parent
| on HN ]
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by jerrinot on Wednesday August 05, 2020 @09:51AM
(#24060711)
I didn't know about fully concurrent root scanning, thank you!
How does root scanning work wrt to Loom? Are stacks of virtual threads treated as roots? I guess there is no other option?
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pron on Wednesday August 05, 2020 @09:54AM
(#24060742)
No, virtual thread stacks are not roots! This is one of the main design highlights of the current Loom implementation. In fact, at least currently, the VM doesn't maintain any list of virtual threads at all. They are just Java objects, but the GC does treat them specially.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by kjeetgill on Wednesday August 05, 2020 @01:51PM
(#24063528)
Interesting! In what way are they handled specially?
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pron on Wednesday August 05, 2020 @04:27PM
(#24065192)
Unlike any other object, the location of references on a stack can change dynamically, so the GC needs to recognise those objects and walk their references differently. There are other subtleties, too.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pkolaczk on Wednesday August 05, 2020 @10:41AM
(#24061288)
Right, it is concurrent, but it is still costly. It brings rarely used data into the caches and pushes useful data out of the caches. If some parts of the heap were swapped out, the impact of concurrent scanning can be quite dramatic.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pron on Wednesday August 05, 2020 @11:20AM
(#24061783)
Ah, but you can pin GC threads to specific cores, and a reference-counting GC also has such non-trivial costs. In practice, however, people in the 90-95% "mainstream" domain that Java targets are very happy with the results. Of course, there are some applications that must incur the costs of not having a GC. In general, though, the main tangible cost of a GC today, for a huge portion of large-scale applications, is neither throughput nor latency by RAM overhead.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pjmlp on Wednesday August 05, 2020 @01:06PM
(#24063068)
I also enjoy the low level C++ like tooling that .NET offers, but I am also looking forward to the fruits of Panama and Valhalla in that direction.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pkolaczk on Wednesday August 05, 2020 @01:28PM
(#24063287)
Pinning doesn't solve the problem of cache L3+ thrashing.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pron on Wednesday August 05, 2020 @02:40PM
(#24064076)
It could if the GCs used non-temporal instructions that bypass the L3. Of course, how much of a problem this is in practice in most applications is something that would need to be measured.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pkolaczk on Wednesday August 05, 2020 @03:06PM
(#24064341)
Point taken. What about swap?
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads
by pron on Wednesday August 05, 2020 @04:23PM
(#24065154)
Yeah, swapping could be really bad and should be avoided. So: don't swap :) Java's memory consumption can't go up indefinitely. The most important setting is the maximum heap size. Set it to a good level and don't swap.