PK24130: BETTER BUFFER USAGE ALGORITHM FOR BODYCONTENTIMPLBUFFER | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description Better buffer usage algorithm for BodyContentImpl The size of the buffer BodyContentImpl is using is growing by 1k at a time when it is filled, which in this case might not be aggresive enough. It is believed that this behaviour has come in with the subsiquent eFix "PQ98460 - BodyContentImplBuffer length too long", which is still required but this might be a side effect. In the above example we have calculated that in this jsp alone, this approach of only growing the buffer by 1k causes the JVM to cycle 2.4MB of garbage. It is believed if this strategy was changed to doubling the buffer size everytime instead of increasing size by 1k,it would require something more like 256K in this jsp. Applications running on WAS 5.0.2.6 (with PQ98460 applied) and 5.1.1.7 that would benefit from this change. Would it be possible to get a fix to the org.apache.jasper.runtime.BodyContentImpl that doubles the buffer instead of growing it by 1k? The customer does not have a one size fits all usage of the bodycontentimpl. There are many JSPs in their application and some require larger buffers, some smaller. As we cannot set an optimum setting for this (too high and waste memory on some pages, too low and we suffer the memory churn of growing the buffer by 1k each time) we require the algorithm be more aggresive for growing the buffer. With the ability to set the buffer size, and it doubling in size rather than expanding by 1k we would then be able to customise the optimum setting. private void reAllocBuff(int len) { if (bufferSize + len <= cb.length) { bufferSize = cb.length; return; } if (len < cb.length) { len = cb.length; } bufferSize = cb.length + len; char[] tmp = new char[bufferSize]; System.arraycopy(cb, 0, tmp, 0, cb.length); cb = tmp; tmp = null; } This is the type of algorithm we believe will provide better memory usage from this heavily used class. With PK04091, lets say we set the initial buffer size to 512, every time the buffer fills up the buffer would grow from 512, 1k, 1.5k, 2k, 2.5k, etc. This means that the sizing of the initial buffer size would need to assume that all usage of the buffer is in the same region of size, too small and we would get too many reallocs, too big and we waste memory. With the above algorithm thesame situation would go 512, 1k, 2k, 4k, etc. It doubles up everytime.Therefore if you require a small buffer then the initial size can be kept small, but if you require a larger buffer you will not waste as much memory stepping up to the required size.Local fix N/AProblem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server version 5.0.2 * * and 5.1.1 users whose applications * * extensively use tags and print large data * * and would also store large objects. * **************************************************************** * PROBLEM DESCRIPTION: The buffer allocation algorithm was * * initially growing the size of the * * buffer by (bodycontentbuffsize) bytes * * for every allocation which was * * causing more garbage collection * * cycles for high memory requests. * **************************************************************** * RECOMMENDATION: * **************************************************************** The algorithm was considered not higly aggressive in cases of huge memory requests and so the algorithm for buffer allocation has been modified to satisfy this requirement.Problem conclusion The algorithm is now modified to double the buffer size for every allocation. For instance, if the 'BodyContentBuffSize' property is set to 1000 bytes then the first allocation would cause 2000 bytes to be allotted and the next allocation would be for 4000 bytes and so on. The fix for this APAR is currently targeted for inclusion in cumulative fixes 5.0.2.18 and 5.1.1.12. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: PK38778 Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 10A
Software edition:
Reference #: PK24130
IBM Group: Software Group
Modified date: Feb 5, 2007
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.