<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Adding the GC dev alias to get their opinion.<div><br><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Azeem Jiva</div><div>@javawithjiva</div></div>
</div>
<br><div><div>On Aug 22, 2013, at 6:34 AM, "Doerr, Martin" &lt;<a href="mailto:martin.doerr@sap.com">martin.doerr@sap.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br>we have an addon to your G1 pre-barrier change which reduces<br>its cost.<br>It is possible to get rid of the do_load in inline_unsafe_load_store<br>because we always know the value which gets overwritten.<br><br>In case of cmpxchg, the only value which might get overwritten<br>is known in advance.<br>In case of xchg, the old value is returned by the load_store.<br>It is allowed to do the barrier after the xchg because there's<br>no safepoint between them.<br><br>Please review<br><a href="http://cr.openjdk.java.net/~goetz/webrevs/opto_g1_barr/">http://cr.openjdk.java.net/~goetz/webrevs/opto_g1_barr/</a><br><br>Best regards,<br>Martin and Goetz<br><br><br>-----Original Message-----<br>From: hotspot-compiler-dev-bounces@openjdk.java.net [mailto:hotspot-compiler-dev-bounces@openjdk.java.net] On Behalf Of Vladimir Kozlov<br>Sent: Donnerstag, 22. August 2013 02:55<br>To: hotspot compiler<br>Subject: Re: RFR (XS): 8023472: C2 optimization breaks with G1<br><br>Thanks, Christian<br><br>On 8/21/13 4:04 PM, Christian Thalinger wrote:<br><blockquote type="cite"><br>On Aug 21, 2013, at 3:18 PM, Vladimir Kozlov &lt;vladimir.kozlov@oracle.com&gt; wrote:<br><br><blockquote type="cite">http://cr.openjdk.java.net/~kvn/8023472/webrev/<br><br>The load of previous value in G1 pre-barrier code (method GraphKit::g1_write_barrier_pre()) does not have control. It is from the time when G1 code was merged into Hotspot sources. I can only speculate that it was done to allow commoning with a preceding normal load if it exists and to avoid generation of 2 loads.<br>This problem, I think, only affects loads from an array because a load from a field should be guarded by NULL check of object.<br><br>The fix is to put control on this load to always generate it after if (marking) check. I doubt it affect performance much. If there was load before the value should be in cache.<br></blockquote><br>The fix looks good. &nbsp;Can you at least do a refworkload run to do some due diligence?<br></blockquote><br>Will do it tonight.<br><br><blockquote type="cite"><blockquote type="cite"><br>Added regression test.<br></blockquote><br>Could you change the name of the test? &nbsp;Since we moved away from using bug ids the test name should more or less explain what it tests. &nbsp;I suppose there will be more G1CrashTest's in the future :-)<br></blockquote><br>It is external test. I don't want to change it much or its name.<br><br>Vladimir<br><br><blockquote type="cite"><br>-- Chris<br><br><blockquote type="cite"><br>Thanks,<br>Vladimir<br><br></blockquote></blockquote></blockquote></div><br></div></body></html>