Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] StackOverflowError compiling XOM

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: cowwoc <cowwoc AT bbs.darktech.org>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] StackOverflowError compiling XOM
  • Date: Mon, 14 Jul 2008 22:39:10 -0400


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.






Archive powered by MHonArc 2.6.24.

Top of Page