First cut at a card table for Shenandoah

[Mathiske, Bernd]

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