High CPU and GC spikes from JDOM 2 TextBuffer.append Calls

Environment

• JBoss Enterprise Application Platform (EAP) 6
• JDOM 2.0.0 - 2.0.4

Issue

• We see very high CPU and increased GC activity when calls are made to TextBuffer.append in the jdom library bundled in our application:

"ajp-localhost/127.0.0.1:8009-11" daemon prio=10 tid=0x00007fee6c021000 nid=0x2f2b runnable [0x00007fee7d555000]
   java.lang.Thread.State: RUNNABLE
	at org.jdom2.internal.ArrayCopy.copyOf(ArrayCopy.java:113)
	at org.jdom2.input.sax.TextBuffer.append(TextBuffer.java:103)
 	at org.jdom2.input.sax.SAXHandler.characters(SAXHandler.java:763)

Resolution

• Upgrade to JDOM 2.0.5

Root Cause

• There is a major performance issue in the append method of jdom's TextBuffer:

  void append(char[] source, int start, int count)
  {
    if (count + this.arraySize > this.array.length) {
      this.array = ArrayCopy.copyOf(this.array, count + this.arraySize);
    }
    System.arraycopy(source, start, this.array, this.arraySize, count);
    this.arraySize += count;
  }

• So when the array for the buffer is too small to take in a newly appended char, the array is copied to a new array that is sized to be the previous array size + the incoming append size. The array buffer is only expanded enough just for that particular append to fit. This means with each and every additional append to the buffer, this jdom text buffer is copying a whole new array and discarding the old one. This practice causes unneeded amount of CPU time in array copying and churns out an unnecessary amount of array garbage to increase GC activity.
• This is Content from github.com is not included.a known JDOM issue

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.