First cut at a card table for Shenandoah

Mathiske, Bernd mathiske at amazon.com
Thu Jul 16 00:20:23 UTC 2020


Just having edited some card table operations into Shenandoah GC, 
I have uploaded a webrev for perusal: 
http://cr.openjdk.java.net/~bmathiske/cardshen/webrev.00/

The general idea of this patch is to mark some cards on the side as if we needed a generational remembered set barrier, without changing how Shenandoah works otherwise. Then we should be able to measure how much mutator overhead this sort of extra barrier might cause. My expected result was "similar to CMS or Parallel compared to Epsilon", but that's not what I am seeing in first attempts to run SPECjvm2008. Some of those benchmarks go way south, 5x and more. So I guess I made a mistake somewhere, but here it is anyway, so you can see the my approach, which is reparenting barrier classes to shared card table barrier classes and then hoping that everything falls into place. ( The array copying barrier for C1/C2 is switched off for now.

For now, this patch is based on 11.0.7. I will rebase this to the latest soon.




More information about the shenandoah-dev mailing list