By: Peter
Hi Roman, First off, thanks for the series of articles explaining the changes in Shenandoah in JDK13. I’m really excited to see the active development going on for this GC. I had a question about the...
View ArticleBy: Roman Kennke
Hi Peter, there are several aspects playing into this: – I believe the original paper was concerned with whether or not to place weak barriers or strong barriers at the use-site. The problem with this...
View ArticleBy: Peter
Hi Roman, thanks for the reply – yes, that helps a lot! Thanks for your time and appreciate you and your team’s work on this.
View ArticleBy: 57skies
It’s fair to say that a “read barrier” is not really a barrier? I mean it’s just a dereference via the forwarding pointer, isn’t it? I do understand that reads are much more compared to writes and that...
View ArticleBy: Roman Kennke
Ah yes! The load-barrier functions pretty much as the old write-barrier did. It’s basically like you described in your original question. And, maybe surprisingly, testing+branching is overall cheaper...
View ArticleBy: Roman Kennke
A barrier is a small snippet of code that is inserted by the JIT to accomodate special needs of the GC. In the case of read-barrier, yes it ‘only’ amounts to a dereference. And even though it’s only a...
View ArticleBy: 57skies
I do understand that the reasoning is easier than before: no ‘weird’ equality code, far simpler optimizations I assume also; no need to intercept every single write – be that a primitive or a...
View ArticleBy: 57skies
Not going to comment on CPU branch prediction, that always hurst my brain when I know ‘cmove’ exists… and goes a lot beyond my level of comfort. Or those filters are just amazingly good. Evacuation...
View Article
