<div dir="ltr">Hi Kim,<div><br></div><div>Thanks for reviewing and testing the patch. If there are any failures or performance degradation relevant to the work, please let me know and I'll be very happy to keep improving it. Also, any suggestions about code improvements are well appreciated.</div><div><br></div><div>I'm not quite sure if both G1 and Shenandoah have the similar region dependency issue, since I haven't studied their GC behaviors before. If they have, I'm also willing to propose a more general optimization.</div><div><br></div><div>As to the memory overhead, I believe it will be low because this patch exploits empty regions in the young space rather than off-heap memory to allocate shadow regions, and also reuses the <i>_source_region</i> field of each <i>RegionData </i>to record the correspongding shadow region index. We only introduce a new integer filed <i>_shadow </i>in the RegionData class to indicate the status of a region, a global <i style="">GrowableArray _free_shadow</i> to store the indices of shadow regions, and a global <i>Monitor</i> to protect the array. These information might help if the memory overhead need to be evaluated.</div><div><br></div><div>Looking forward to your insight.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="font-size:12px"><div><font face="黑体" color="#000000">Best Regrads,</font></div><div><font face="黑体" color="#000000">Haoyu Li,</font></div><div><font face="黑体" color="#000000">Institute of Parallel and Distributed Systems(IPADS),</font></div><div><font face="黑体" color="#000000">School of Software,</font></div><div><font face="黑体" color="#000000">Shanghai Jiao Tong University</font></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.com</a>> 于2019年3月12日周二 上午6:11写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Mar 11, 2019, at 1:45 AM, Kim Barrett <<a href="mailto:kim.barrett@oracle.com" target="_blank">kim.barrett@oracle.com</a>> wrote:<br>
> <br>
>> On Jan 24, 2019, at 3:58 AM, Haoyu Li <<a href="mailto:leihouyju@gmail.com" target="_blank">leihouyju@gmail.com</a>> wrote:<br>
>> <br>
>> Hi Kim,<br>
>> <br>
>> I have ported my patch to OpenJDK 13 according to your instructions in your last mail, and the patch is attached in this mail. The patch does not change much since PSGC is indeed pretty stable.<br>
>> <br>
>> Also, I evaluate the correctness and performance of PS full GC with benchmarks from DaCapo, SPECjvm2008, and JOlden suits on a machine with dual Intel Xeon E5-2618L v3 CPUs(16 physical cores), 64G DRAM and linux kernel 4.17. The evaluation result, indicating 1.9X GC throughput improvement on average, is attached, too.<br>
>> <br>
>> However, I have no idea how to further test this patch for both correctness and performance. Can I please get any guidance from you or some sponsor?<br>
> <br>
> Sorry I missed that you had sent an updated version of the patch.<br>
> <br>
> I’ve run the full regression suite across Oracle-supported platforms.  There are some<br>
> failures, but there are almost always some failures in the later tiers right now.  I’ll start<br>
> looking at them tomorrow to figure out whether any of them are relevant.<br>
> <br>
> I’m also planning to run some of our performance benchmarks.<br>
> <br>
> I’ve lightly skimmed the proposed changes.  There might be some code improvements<br>
> to be made.<br>
> <br>
> I’m also wondering if this technique applies to other collectors.  It seems like both G1 and<br>
> Shenandoah full gc’s might have similar issues?  If so, a solution that is ParallelGC-specific<br>
> is less interesting than one that has broader applicability.  Though maybe this optimization<br>
> is less important for G1 and Shenandoah, since they actively try to avoid full gc’s.<br>
> <br>
> I’m also not clear on how much additional memory might be temporarily allocated by this<br>
> mechanism.<br>
<br>
I’ve created a CR for this: <a href="https://bugs.openjdk.java.net/browse/JDK-8220465" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8220465</a><br>
<br>
</blockquote></div>