G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector]

[Vitaly Davidovich]

Erik,

Thanks for the update/correction on the current state.  Looking forward to
seeing more details when you're ready.

sent from my phone
On Jul 30, 2015 4:42 AM, "Erik Österlund" <erik.osterlund at lnu.se> wrote:

> Hi Andrew and Vitaly,
>
> Sorry for interrupting the discussion, but some things need setting
> straight about my current work.
>
> I currently don’t use IPI. Conversely, I have removed two places where it
> was previously used and hence depend less on IPI than the current solution.
> Now that this is brought up, I feel like I should explain at least a little
> bit.
>
> I changed the safepointing mechanism of hotspot to use thread-local
> conditional branches instead of IPI/mprotect, without performance cost in
> my DaCapo benchmarks. (long story) This allowed a handshaking mechanism to
> piggy-back on the safepointing mechanism and reply with a simple releasing
> store instead of IPI. (also a long story)
>
> It’s a rather tricky mechanism exploiting lazy eventual synchronization,
> asynchronous card scanning, different dynamically increasing urgency levels
> with different platform-specific support for reaching a synchronized state
> faster etc. Higher urgency means it uses more drastic measures (potentially
> interfering with mutators) to reach a synchronized state, and conversely
> lower urgency is more lazy, does not try as hard, but leads to better
> throughput as it does not interfere with mutators.
>
> All in all, my solution depends less on IPI than the current solution. I
> don’t use IPI for serializing thread states, I don’t use it for safepoints,
> I don’t use it for ADS. Yet that membar in the G1 write barrier is gone
> with good performance improvements on my machine in some G1 stressing
> microbenchmarks.
>
> Details will probably follow at some point in the future in a separate
> thread when the time is right.
>
> Regards,
> /Erik
>
>
> > On 30 Jul 2015, at 09:49, Andrew Dinn <adinn at redhat.com> wrote:
> >
> > On 29/07/15 19:27, Vitaly Davidovich wrote:
> >> IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will
> speed
> >> this up.  A few months back there was a discussion around this in the
> >> context of adding full fence with CMS when UseConditionalCardMarking is
> >> enabled (which I'm not sure if that change went in actually) and
> >> interaction with precleaning.
> >
> > A change did go in but not quite as you describe it. As a fix for
> > JDK-8079315 a /StoreLoad/ barrier was added -- see this changeset:
> >
> >  http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7d15bf7b961
> >
> > I agree that TLB shootdowns are unlikely to improve performance -- also,
> > they are a hostage to fortune since you are at the mercy of the OS
> > implementation as regards both performance and, perhaps to a lesser
> > degree, correctness.
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> >
>
>