First cut at a card table for Shenandoah

[Roman Kennke]

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?
> 
>     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.
>     >     >
>     >     >
>     >
>     >
> 
>