First cut at a card table for Shenandoah

[Aditya Mandaleeka]

FWIW, I looked at this briefly when Bernd sent the original email and couldn't find any place
where CMS/Parallel are taking fast-outs in card marking for non-young-gen refs either.

-Aditya

-----Original Message-----
From: shenandoah-dev <shenandoah-dev-retn at openjdk.java.net> On Behalf Of Roman Kennke
Sent: Wednesday, July 22, 2020 1:59 PM
To: Mathiske, Bernd <mathiske at amazon.com>
Cc: shenandoah-dev <shenandoah-dev at openjdk.java.net>
Subject: Re: First cut at a card table for Shenandoah

I am not very familiar with all this stuff.

You should check if the C2 optimizations for card-table-barriers kick
in. IIRC, there was something that elides those barriers on stores into
new objects altogether, which make up the majority of stores.

Roman


On Wed, 2020-07-22 at 17:58 +0000, Mathiske, Bernd wrote:
> That limiting card table updates to part of the heap helps seems
> doubtful to me now:
> 1. I could not find code that does this for Parallel or CMS. Correct
> me if I got this wrong!
> 2. The young gen detection technique I did see in G1 was to read from
> the card table and compare the value there to a young gen indicator
> value. Very similarly, conditional marking reads the value and
> compares it to the dirty card value. So I ran the benchmarks with
> -XX:+UseCondCardMark and dirtied the whole card table to begin with.
> Only minimal improvement. 
> 
> On 7/16/20, 10:40 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.
> 
> 
> 
>     Instead of simulating, you could probably use my earlier
> generations-
>     prototype?
> 
>     https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fgeneration.patch&data=02%7C01%7Cadityam%40microsoft.com%7C8513d6ee8bf4457ba7c108d82e826ea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637310485034589775&sdata=h18f%2BvPaKXHmOsSBz%2FEqXWmvzU%2FxDRhclMnJldRkr%2Bo%3D&reserved=0
> 
>     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:
>     >     > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~bmathiske%2Fcardshen%2Fwebrev.00%2F&data=02%7C01%7Cadityam%40microsoft.com%7C8513d6ee8bf4457ba7c108d82e826ea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637310485034589775&sdata=VjLl%2F7FLsdVMZ13ajtAhgzF%2Fz%2Bf%2FsGTXgXtaMZJSheQ%3D&reserved=0
>     >     >
>     >     > 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.
>     >     >
>     >     >
>     >
>     >
> 
>