jkesselm 02/02/01 12:12:57
Modified: java/src/org/apache/xml/utils FastStringBuffer.java
Log:
Bugzilla 6182. Darned fence posts; always either too many or not enough... <grin/>
Revision Changes Path
1.17 +23 -6 xml-xalan/java/src/org/apache/xml/utils/FastStringBuffer.java
Index: FastStringBuffer.java
===================================================================
RCS file: /home/cvs/xml-xalan/java/src/org/apache/xml/utils/FastStringBuffer.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- FastStringBuffer.java 18 Jan 2002 18:53:50 -0000 1.16
+++ FastStringBuffer.java 1 Feb 2002 20:12:57 -0000 1.17
@@ -62,12 +62,12 @@
* applications, thread-safety of a StringBuffer is a somewhat
* dubious concept in any case.
* <p>
- * Note that Stree is using a single FastStringBuffer as a string pool,
- * by recording start and length indices within a single buffer. This
+ * Note that Stree and DTM used a single FastStringBuffer as a string pool,
+ * by recording start and length indices within this single buffer. This
* minimizes heap overhead, but of course requires more work when retrieving
* the data.
* <p>
- * This has been recoded to operate as a "chunked buffer". Doing so
+ * FastStringBuffer operates as a "chunked buffer". Doing so
* reduces the need to recopy existing information when an append
* exceeds the space available; we just allocate another chunk and
* flow across to it. (The array of chunks may need to grow,
@@ -76,8 +76,15 @@
* boundaries; larger chunks make that less frequent.
* <p>
* The size values are parameterized, to allow tuning this code. In
- * theory, RTFs might want to be tuned differently from the main
- * document's text.
+ * theory, Result Tree Fragments might want to be tuned differently
+ * from the main document's text.
+ * <p>
+ * %REVIEW% An experiment in self-tuning is
+ * included in the code (using nested FastStringBuffers to achieve
+ * variation in chunk sizes), but this implementation has proven to
+ * be problematic when data may be being copied from the FSB into itself.
+ * We should either re-architect that to make this safe (if possible)
+ * or remove that code and clean up for performance/maintainability reasons.
* <p>
*/
public class FastStringBuffer
@@ -348,7 +355,6 @@
*/
public final void setLength(int l)
{
-
m_lastChunk = l >>> m_chunkBits;
if (m_lastChunk == 0 && m_innerFSB != null)
@@ -359,6 +365,17 @@
else
{
m_firstFree = l & m_chunkMask;
+
+ // There's an edge case if l is an exact multiple of m_chunkBits, which
risks leaving
+ // us pointing at the start of a chunk which has not yet been allocated.
Rather than
+ // pay the cost of dealing with that in the append loops (more scattered and
more
+ // inner-loop), we correct it here by moving to the safe side of that
+ // line -- as we would have left the indexes had we appended up to that
point.
+ if(m_firstFree==0 && m_lastChunk>0)
+ {
+ --m_lastChunk;
+ m_firstFree=m_chunkSize;
+ }
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
