RFR: Remove prefetch during mark

[charlie hunt]

As mentioned by Hugh, marking performance (especially an initial mark or STW mark) could be improved if software prefetches are early enough (and not too early as to be evicted by some other request).

It is great to have your expertise input on software prefetch placement! Looking forward to hearing your suggested placement and details.

To generalize my observations, the software prefetch in its current placement did not show benefit for concurrent marking. In fact, under heavy load, concurrent marking times are actually slightly longer (as ~ 2%). STW marking, which is very quick with ZGC, it does help very slightly. But we are talking less than a millisecond. Hence, the suggestion to remove the software prefetch and do some analysis on better placement.

charlie

> On Feb 14, 2018, at 10:23 AM, Wilkinson, Hugh <hugh.wilkinson at intel.com> wrote:
> 
> I have been looking at this also.
> 
> I find that if the prefetching occurs 3 popped entries ahead of the processing, then there is a worthwhile benefit.
> 
> A bit of re-structuring is required to make this easy and efficient.
> 
> I am prefetching 2 cache lines from the referenced object and also doing a PREFETCHW of the mark bitmap.  (Prefetch::write() requires modification for x86.)
> 
> With the current code structure, removal of the Prefetch::read() probably makes sense; however, I would like to highlight that marking performance can be improved with sufficiently early software cache prefetches.
> 
> I expect to share more details later.
> 
> Hugh
> 
> -----Original Message-----
> From: zgc-dev [mailto:zgc-dev-bounces at openjdk.java.net] On Behalf Of Stefan Karlsson
> Sent: Wednesday, February 14, 2018 4:41 AM
> To: Per Liden <per.liden at oracle.com>; zgc-dev at openjdk.java.net
> Subject: Re: RFR: Remove prefetch during mark
> 
> Looks good.
> 
> StefanK
> 
> On 2018-02-14 09:43, Per Liden wrote:
>> Small patch to remove the prefetch we do during marking. Charlie Hunt 
>> spent some time looking into the effect of this, and in conclusion the 
>> prefetch doesn't help.
>> 
>> http://cr.openjdk.java.net/~pliden/zgc/remove_mark_prefetch/webrev.0/
>> 
>> /Per