First cut at a card table for Shenandoah

[Mathiske, Bernd]

The async_profiler just told me that C2Compiler::compile_method is running ~60% of total runtime if my C2 card table code inserted. I'll look further into that.

On 7/22/20, 10:58 AM, "Mathiske, Bernd" <mathiske at amazon.com> 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.
        >     >
        >     >
        >
        >