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

[Erik Österlund]

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