First cut at a card table for Shenandoah

[Mathiske, Bernd]

Aditya, Thomas, Roman,

Thank you for providing these hints, which were helpful to rule out possible root causes!
Looking at all this and at some initial profiling results, 
Volker Simonis suggested that -XX:-EliminateAllocations might help. And it does!
When I use this flag, performance is "back to normal" in the short benchmark runs I have conducted so far.
I'll run some more extensive tests, with repetitions, and report some numbers, soon.

Bernd

On 7/23/20, 4:32 AM, "shenandoah-dev on behalf of Roman Kennke" <shenandoah-dev-retn at openjdk.java.net on behalf of 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.



    On Thu, 2020-07-23 at 12:31 +0200, Thomas Schatzl wrote:
    > Hi,
    >
    > On 22.07.20 22:59, Roman Kennke wrote:
    > > 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.
    > >
    >
    >    if you are talking about eliding write barriers for new objects
    > because they are "always" allocated in young gen, and no
    > generational
    > collector is interested in young->old references, there is no such
    > thing
    > afaik.
    >
    > No collector guarantees this "always" property: e.g. CMS may
    > directly
    > decide to put new objects into old gen for a few reasons, and for
    > parallel (and g1) it e.g. can happen that a gc right after
    > allocating
    > that object (when e.g. transitioning from native slow-path code)
    > will
    > move that object into old gen. Or simply when the object is large.
    >
    > See e.g. https://bugs.openjdk.java.net/browse/JDK-8191342
    >
    > That would still require the compiler to only apply that optimization
    > if
    > it can prove that the object is "small enough" to fit into young gen
    > in
    > any case (it is probably easy to get conservative enough values for
    > that
    > from somewhere).
    >

    Thanks Thomas for clarification! :-)

    Roman