[XOM-interest] StackOverflowError compiling XOM

cowwoc cowwoc at bbs.darktech.org
Tue Jul 15 02:10:54 EDT 2008


	I've generated a replacement for UnicodeUtil.getCombiningClass() that 
consists of 223 lines of code and runs approximately 20x faster than the 
original code (which consists of 1143 lines of code). Please see the 
attached file.

	The next thing I would recommend optimizing is 
"UnicodeUtil.decompose(int character)". It is a whopping 6934 lines of 
code and is likely causing the most pain for compilers and obfuscators. 
You could either break this method down into multiple methods (since 
most of its execution is linear anyway) or replace the if-else 
statements with a switch block to improve performance but then reducing 
the method size is not as obvious.

	There is a "FIXME must recurse this" beside it, so maybe you already 
have ideas for breaking it down?

Gili

cowwoc wrote:
> 
>     By the way, this also causes major StackOverflowErrors for Proguard. 
> Increasing the stack-size allows it to proceed further but then it 
> crashes with:
> 
> IllegalArgumentException: Branch instruction can't be widened 
> (goto_w+56833)
> 
>     I've reported the problem to the author but this is yet another 
> example of the headache caused by this code: 
> http://sourceforge.net/forum/forum.php?thread_id=2120087&forum_id=182456
> 
>     What kind of performance impact would you see by splitting this code 
> across two methods? Secondly, looking at UnicodeUtil.getCombiningClass() 
> I see quite a bit of wasted instructions. For example,
> 
>         if (c == 0x0028) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
>         if (c == 0x0029) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
>         if (c == 0x002A) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
>         if (c == 0x002B) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
>         if (c == 0x002C) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
>         if (c == 0x002D) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
> 
> could be replaced by
> 
>         if (c >= 0x0028 && c <= 0x002D) return 
> CANONICAL_COMBINING_CLASS_NOT_REORDERED;
> 
>     There are literally hundreds of such lines that could be folded down 
> into a single line of code. In other words, this bug is fixable. If I 
> manually optimize this code would you merge my changes into future 
> releases?
> 
> Thank you,
> Gili
> 
> cowwoc wrote:
>>
>>     Normally I would agree with you, but seeing as the reference 
>> implementation JDK has this problem and they do not plan on fixing it 
>> I think you should seriously reconsider: 
>> http://bugs.sun.com/view_bug.do?bug_id=6453531
>>
>>     To be clear, not only are you risking compiler crashes here, but 
>> also a severe runtime performance drop. Unless you know of a way to 
>> get this fixed through OpenJDK I suggest you make sure none of your 
>> own code surpasses the 8000 byte limit.
>>
>> Gili
>>
>> Elliotte Harold wrote:
>>> cowwoc wrote:
>>>
>>>>     There should definitely be a better way of mapping characters 
>>>> than dumping a whole slew of if statements into a method. Have you 
>>>> tried asking on the Java discussion forums?
>>>>
>>>
>>> There are such ways and I use them, but the goal is maximum 
>>> efficiency at runtime, not working around compiler bugs. This is a 
>>> real hot spot in XOM and some serious effort has gone into optimizing 
>>> every last millisecond out of this. Check out my chapter in Beautiful 
>>> Code for the details sometime.
>>>
>>> The simple fact is that the most efficient way is table lookup (O(1)) 
>>> based on carefully constructed switch statements with no holes. If 
>>> it's legal code and a compiler can't handle it, then get a better 
>>> compiler. I'm not going to slow XOM down to work around compiler bugs.
>>>
>>
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: replacement.txt
Url: http://lists.ibiblio.org/pipermail/xom-interest/attachments/20080715/f2ad3941/attachment.txt 


More information about the XOM-interest mailing list