Incredible benchmark results! And very nice to see the multi-mapping gone which was a bit of a headache from an operations perspective. Thread-local GC also sounds very interesting, but definitely also looks like quite a challenge to implement. But then again, you are used to huge challenges like this.
Thread-local gc sounds really promising, can I ask if thread-local gc would be applied to the whole application with both platform thread and virtual thread supported? or thread-local gc would only be applied to virtual threads only, and zgc would be used on platform threads?
Thread local GC in the general case tends to have to deal with roots that are live. But I want a free lunch, and you only get that when a thread terminates, because then it has no frames and hence no GC roots you have to trace from. To optimize for short lived threads makes the most sense in the context of virtual threads, so that will at least be the initial focus.
It means the addresses are always multiples of 8, meaning it will end with 8, 16, 24, 32, etc. Or in binary: 1000, 10000, 11000, 100000, etc. Note how they all end with at least 3 zeros. Makes sense since multiplying an integer by 8 is equivalent to shifting its bits left 3 positions.
why cant peopole properly explain how it works and when does it get advantage... just laying out useless implementation details that not necessarily cover either... the proper thing to benchmark this against is shenandoah GC.
You realise that this talk was presented during the latest JVM Language Summit, right? JVMLS is the forum where various JVM implementers discuss... JVM implementations. 😉 Also, Generational Shenandoah (experimental) support was dropped from the JDK 21 plan in June last year. So, and as of now, there's nothing to benchmark against.
@@delabassee hmm it seems they cut it because it wasnt ready, its a new feature, they simply do not deliver it, which is fine, they are not removing the gc. Also most of the java projects are still on JDK 8 even in 2024, so if anything they should benchmark it not on java 21 but earlier versions.
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
![[VDT19] Concurrent Garbage Collectors: ZGC & Shenandoah by Simone Bordet [IT]](/img/n.gif)
I was hyped by generational ZGC and now I am even more than ever before. Thank you for the talk, the recording and all the work you are doing guys.
Wow, looks awesome in performance.
Incredible benchmark results! And very nice to see the multi-mapping gone which was a bit of a headache from an operations perspective.
Thread-local GC also sounds very interesting, but definitely also looks like quite a challenge to implement. But then again, you are used to huge challenges like this.
@erik - could you please share some refences on tuning parameters for ZGC
19:20 test can fuse with the following jcc so the non-generational load barrier is actually a one-instruction barrier.
I don't think there's any desire to make improvements to the non-generational ZGC.
@@broneetube One-instruction barrier is the current state of non-generational ZGC
Nah it isn’t a short branch, so I don’t believe it can fuse. Certainly behaves as if it can’t as well.
Thread-local gc sounds really promising, can I ask if thread-local gc would be applied to the whole application with both platform thread and virtual thread supported? or thread-local gc would only be applied to virtual threads only, and zgc would be used on platform threads?
Thread local GC in the general case tends to have to deal with roots that are live. But I want a free lunch, and you only get that when a thread terminates, because then it has no frames and hence no GC roots you have to trace from. To optimize for short lived threads makes the most sense in the context of virtual threads, so that will at least be the initial focus.
20:37 I don't quite understand what it means, why alignment ensure address low order bits are zero?
It means the addresses are always multiples of 8, meaning it will end with 8, 16, 24, 32, etc. Or in binary: 1000, 10000, 11000, 100000, etc. Note how they all end with at least 3 zeros. Makes sense since multiplying an integer by 8 is equivalent to shifting its bits left 3 positions.
@@ErikOsterlund-pu6pn Oh, thank you for the explanation!
why cant peopole properly explain how it works and when does it get advantage... just laying out useless implementation details that not necessarily cover either... the proper thing to benchmark this against is shenandoah GC.
You realise that this talk was presented during the latest JVM Language Summit, right? JVMLS is the forum where various JVM implementers discuss... JVM implementations. 😉
Also, Generational Shenandoah (experimental) support was dropped from the JDK 21 plan in June last year. So, and as of now, there's nothing to benchmark against.
@@delabassee hmm it seems they cut it because it wasnt ready, its a new feature, they simply do not deliver it, which is fine, they are not removing the gc.
Also most of the java projects are still on JDK 8 even in 2024, so if anything they should benchmark it not on java 21 but earlier versions.