Shenandoah experimental flags

[Cristian Velazquez]

Thanks, I can confirm that this doesn't happen in java 11 and above. For
now I'll keep a small buffer size. Is there a way I can see the satb
traffic from the log? Or a way to determine a proper buffer size for my
workloads? If not I can wait for any future fix.

For my use case I would prefer concurrent to spend more time just to clean
the buffers and let the pause to be as small as possible, but I don't how
feasible is that.

Thanks for all the help, regards
   Cristian V

On Fri, May 1, 2020 at 8:53 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 5/1/20 4:36 PM, Aleksey Shipilev wrote:
> > On 4/30/20 11:17 PM, Cristian Velazquez wrote:
> >> Thanks for the prompt response. I'm using the docker jdk8 image
> (shipilev/openjdk-shenandoah:8).
> >
> > Aha! I am able to reproduce it with current sh/jdk8. Let me see what is
> up there.
>
> I believe it is what I initially expected: concurrent mark runs into
> termination very fast, the
> periodic task that flushes SATB buffers does not have the opportunity to
> act, then final mark hits
> and discovers lots of hidden work from the SATB buffers.
>
> A new thing I see is, the SATB traffic itself is too low to enqueue SATB
> buffers naturally. Indeed,
> reducing SATB buffer sizes is the workaround here.
>
> It is interesting that it happens reliably on sh/jdk8, but not on sh/jdk11
> and later. Maybe Jetty is
> using something unusual, like lots of phantom references? Anyhow, another
> way to dodge this problem
> is upgrading.
>
> As for sh/jdk8, we should probably try and see if we can adjust SATB sizes
> looking back at traffic
> we are getting. The nuclear option would be to introduce another pause
> where we force all threads go
> give up their SATB buffers, regardless of their capacity.
>
> That is something to look at next week.
>
> With some instrumentation, good cycle:
>
> [Concurrent marking, start]
>     Using 4 of 8 workers for concurrent marking
> Flushed SATB buffer for thread qtp475266352-44
> Flushed SATB buffer for thread qtp475266352-30
> Flushed SATB buffer for thread qtp475266352-31
> Flushed SATB buffer for thread qtp475266352-48
> Flushed SATB buffer for thread qtp475266352-61
> Flushed SATB buffer for thread qtp475266352-47
> Flushed SATB buffer for thread qtp475266352-63
> Flushed SATB buffer for thread
> qtp475266352-21-selector-ServerConnectorManager at 1c07660a/0
> Flushed SATB buffer for thread
> qtp475266352-20-selector-ServerConnectorManager at 1c07660a/2
> Flushed SATB buffer for thread
> qtp475266352-22-selector-ServerConnectorManager at 1c07660a/3
> Flushed SATB buffer for thread
> qtp475266352-27-selector-ServerConnectorManager at 1c07660a/1
> Flushed SATB buffer for thread qtp475266352-26
> Flushed SATB buffer for thread qtp475266352-37
> [Concurrent marking, 911.426 ms]
> [Pause Final Mark, start]
>     Using 8 of 8 workers for final marking
>     Adaptive CSet Selection. Target Free: 290M, Actual Free: 316M, Max
> CSet: 87381K, Min Garbage: 0B
>     Collectable Garbage: 956M (97%), Immediate: 1024K (0%), CSet: 955M
> (97%)
>     Pacer for Evacuation. Used CSet: 965M, Free: 247M, Non-Taxable:
> 25368K, Alloc Tax Rate: 9.5x
> [Pause Final Mark, 0.917 ms]
>
> ...and bad cycle:
>
> [Concurrent marking, start]
>     Using 4 of 8 workers for concurrent marking
> [Concurrent marking, 1.937 ms]
> [Pause Final Mark, start]
>     Using 8 of 8 workers for final marking
>     Adaptive CSet Selection. Target Free: 290M, Actual Free: 456M, Max
> CSet: 87381K, Min Garbage: 0B
>     Collectable Garbage: 918M (96%), Immediate: 0B (0%), CSet: 918M (96%)
>     Pacer for Evacuation. Used CSet: 926M, Free: 382M, Non-Taxable:
> 39184K, Alloc Tax Rate: 5.9x
> [Pause Final Mark, 987.943 ms]
>
> --
> Thanks,
> -Aleksey
>
>

-- 
Atentamente.
       Cristian D. Velázquez Ramírez.