http://www.advogato.org/person/Ringding/ Advogato blog for Ringding en-us mod_virgule Fri, 24 May 2013 00:49:20 GMT Wed, 29 Sep 2010 13:33:47 GMT http://www.advogato.org/person/Ringding/diary.html?start=1 http://www.advogato.org/person/Ringding/diary.html?start=1 <b>Motivated testers are a godsend</b><br/> <p> Ken Gilmer has found <a href="http://kgilmersden.wordpress.com/2010/09/24/javaone-2010-summary/" >some<br/> examples of surprisingly bad CACAO performance</a> on ARM<br/> (see <a href="http://angelshare.org/files/javaone/javaone_fossjava.pdf" >slides</a>).<br/> In my understanding, CACAO should be at least as fast as<br/> JamVM for moderately long-running benchmarks such as<br/> <tt>probe</tt> and <tt>decode</tt>. Before looking into the<br/> issue, I could only imagine lots of JIT/native transitions<br/> as the cause of this, but I was not entirely convinced that<br/> that alone would create such a performance problem.<br/> <p> Digging into it using <tt>oprofile</tt>, I quickly found<br/> some very inefficient code for handling JNI local<br/> references. Interestingly, it&rsquo;s mostly a <code>memset</code><br/> of 64 bytes that is run on every transition from JIT code to<br/> native code. It seems that either memory bandwidth on ARM is<br/> unbelievably low or the machine&rsquo;s caching behavior is<br/> extremely poor, as the same call, when run on decent x86<br/> hardware, doesn&rsquo;t even show up in a profile, at least not<br/> nearly as prominently.<br/> <p> Anyway, after an <a href="http://mips.complang.tuwien.ac.at/hg/cacao/rev/34bcb84b9dc0" >overhaul<br/> of this half-decade old code</a>, performance for these two<br/> benchmarks has improved by more than 50%. JamVM is still<br/> faster for <tt>decode</tt>, but only slightly. I attribute<br/> this to the garbage collector.<br/> <p> Without Ken&rsquo;s talk, I would have never found out about this.<br/> Mon, 23 Aug 2010 10:28:23 GMT http://www.advogato.org/person/Ringding/diary.html?start=0 http://www.advogato.org/person/Ringding/diary.html?start=0 <b>The CACAO 1.0 that wasn&rsquo;t</b> <p> <p> I have a confession to make: it seems that there will be no CACAO 1.0 release, and I&rsquo;m to blame for that. Maintaining two branches of CACAO has become tiresome and quite boring over time, and I never fully understood what the 1.0 branch was there for, anyway. So when yet another problem with <a href="http://icedtea.classpath.org/" >IcedTea</a> (which was using CACAO 0.99.4 at the time) popped up which could trivially be solved by switching to the &ldquo;default&rdquo; branch, I suggested that <a href="http://icedtea.classpath.org/" >IcedTea</a> would be better off just using the Mercurial version, and this is what they did. Now, as this version identifies itself as 1.1, I don&rsquo;t see the point of releasing a 1.0 version from a branch that nobody cares about (or should care about, IMHO) anymore.