[XOM-interest] StackOverflowError compiling XOM
cowwoc
cowwoc at bbs.darktech.org
Mon Jul 14 22:39:10 EDT 2008
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.
>>
>
More information about the XOM-interest
mailing list