<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 21, 2011, at 5:53 AM, Krystal Mok wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi all,</div><div><br></div><div>(Just in case my company email strips attachment again, I'm replying with my personal email)</div><div><br></div><div>I've got the patch ported to 32-bit x86. See attachment.</div>
<div><br></div><div>Additional comments about the patch:</div>
<div>Joseph's original patch moves the IC miss jump out-of-line, but on x64 with compressed oops, that doesn't really save space in the unverified entry point code sequence, due to the 8-byte alignment. Examples in [1].</div>
<div><br></div><div>The version in this mail's attachment uses jump_cc() inline instead of jcc() and a out-of-line jump(). The UEP code generated by both C1 and C2 uses the same pattern.</div><div><br></div><div>There's a similar pattern in&nbsp;generate_i2c2i_adapters() that could have used jump_cc() to call the ic_miss_stub. But the gains doesn't look significant enough so I didn't modify it.</div></blockquote><div><br></div>Are there any performance regressions with this patch on older x86 architectures?</div><div><br><blockquote type="cite">
<div><br></div><div><br></div><div>Another note:</div><div>In x64's version of&nbsp;SharedRuntime::generate_dtrace_nmethod(), the IC check isn't using load_klass().</div><div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace">__ verify_oop(receiver);</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">__ cmpl(ic_reg, Address(receiver, oopDesc::klass_offset_in_bytes()));</font></div><div><font class="Apple-style-span" face="'courier new', monospace">__ jcc(Assembler::equal, hit);</font></div>
</div><div><br></div><div>Is this correct, or should it be modified to use load_klass(), too? My take is the latter.</div></blockquote><div><br></div>It seems the 32-bit version was copied verbatim to the 64-bit one and looks like a bug to me.</div><div><br></div><div>-- Chris</div><div><br><blockquote type="cite"><div><br></div><div>load_klass() was introduced in [2], and later, generate_dtrace_nmethod() was introduced in [3]. I think [3] missed the compressed oops changes.</div>
<div><br></div><div>Regards,</div><div>Kris Mok</div><div>Software Engineer, Taobao (<a href="http://www.taobao.com/" target="_blank">http://www.taobao.com</a>)</div><div><br></div><div>[1]:&nbsp;<a href="https://gist.github.com/1380416#file_notes.md">https://gist.github.com/1380416#file_notes.md</a></div>
<div>[2]:&nbsp;<a href="http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/ba764ed4b6f2/src/cpu/x86/vm/sharedRuntime_x86_64.cpp">http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/ba764ed4b6f2/src/cpu/x86/vm/sharedRuntime_x86_64.cpp</a></div>
<div>[3]:&nbsp;<a href="http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/018d5b58dd4f/src/cpu/x86/vm/sharedRuntime_x86_64.cpp">http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/018d5b58dd4f/src/cpu/x86/vm/sharedRuntime_x86_64.cpp</a></div>

<br><div class="gmail_quote">2011/11/18 changren <span dir="ltr">&lt;<a href="mailto:changren@taobao.com" target="_blank">changren@taobao.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Ok, Kris will help to port to 32bit.<br>
Thanks,<br>
Joseph<br>
<br>
于 2011-11-18 17:09, Christian Thalinger 写道:<br>
<div><div></div><div>&gt; Looks like a good patch to me. &nbsp;What about 32-bit x86?<br>
&gt;<br>
&gt; -- Chris<br>
&gt;<br>
&gt; On Nov 18, 2011, at 7:39 AM, changren wrote:<br>
&gt;<br>
&gt;&gt; Hi, all<br>
&gt;&gt; Attached patch(diff with hsx20) is supposed to speed up native<br>
&gt;&gt; invocation. It rearranges the compiled-to-native wrapper code to<br>
&gt;&gt; straighten branches which improves spatial locality. Micro<br>
&gt;&gt; benchmark(500m consecutive JNI invocations with warm up) shows the<br>
&gt;&gt; stalled CPU cycles caused by instruction fetch due to L1 ICache miss<br>
&gt;&gt; decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core<br>
&gt;&gt; microarchitecture. The real execution time of the micro benchmark is<br>
&gt;&gt; also decreased 5-10% respectively which reflects the improvement.<br>
&gt;&gt; Thanks,<br>
&gt;&gt; Joseph<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ________________________________<br>
&gt;&gt;<br>
&gt;&gt; This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.<br>


&gt;&gt;<br>
&gt;&gt; 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人,请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。<br>
&gt;&gt; &lt;JNIWrapperOpt.patch&gt;<br>
<br>
</div></div></blockquote></div><br>
<span>&lt;JNI_wrapper_ver2.patch&gt;</span></blockquote></div><br></body></html>