First cut at a card table for Shenandoah

[Roman Kennke]

Instead of simulating, you could probably use my earlier generations-
prototype?

http://cr.openjdk.java.net/~rkennke/generation.patch

Not sure if that easily fits, though, because it's dynamically
shuffling young and old regions, instead of having a fixed boundary.
Might be worth though.

I haven't gotten around to try your stuff yet, but will do so soon!

Thanks,
Roman


> That there is too much tracking is quite possible. I'll figure out a
> way to simulate a young generation. I'll also switch those individual
> barrier parts on one-by-one to see which one does the most damage.
> (Benchmarks that cratered: derby, mmpegaudio, scimark, serial.
> "compress" was fine.)
> 
> Bernd
> 
> On 7/16/20, 1:17 AM, "Roman Kennke" <rkennke at redhat.com> wrote:
> 
>     CAUTION: This email originated from outside of the organization.
> Do not click links or open attachments unless you can confirm the
> sender and know the content is safe.
> 
> 
> 
>     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.
>     >
>     >
> 
>