First cut at a card table for Shenandoah

[Roman Kennke]

Hi Bernd,

could the performance drop come from the fact that we have no
generations yet, and thus the barrier would track *all* stores (all the
time) rather than only old->young stores?

I'll give the patch a spin soon!

Thank you!
Roman


On Thu, 2020-07-16 at 00:20 +0000, Mathiske, Bernd wrote:
> 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.
> 
>