tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 43925] - org.apache.jasper.runtime.BodyContentImpl causing huge memory allocations
Date Tue, 12 Feb 2008 09:44:30 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43925>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43925





------- Additional Comments From brian.remmington@celestialservices.co.uk  2008-02-12 01:44
-------
Thanks very much, Remy.

> - I don't see where memory usage is bounded in the code (if it's not, you should
> compare performance with the unbounded mode of Jasper, which will never
> reallocate anything); that's a problem

Perhaps you could help me here. The memory usage doesn't appear to be bounded in
the current implementation of BodyContentImpl which *always* appears to
reallocate exponentially-larger blocks (in the reAllocBuff method at the
bottom). I must be missing something, but am not sure what. I'm looking at the
head of 5.5, which is the version affected by this change.


> - The opportunity is the ability to share the buffer list per thread, so the
> CharBuffer.bufList should be ThreadLocal<LinkedList> (and should be limited in
> size, which should solve item 1); as a configuration option, it could be a
> concurrent static structure, for use with thread intensive connectors

This would require CharBuffer objects to be pooled to be of use. At the moment
they aren't (and neither are BodyContentImpl objects, as far as I can see). If I
understand you correctly, this would have the undesirable effect of holding onto
blocks of memory once allocated rather than making them available for garbage
collection. This would certainly require a bounded memory pool approach, but its
debatable whether that would be preferable. It would certainly be a bigger change.

> - CharBuffer.toArray is expensive (no other option, though), so you should try
> to show a (real) test result

I will put together a suitable test case for this. Is there a set of test cases
for the current implementation? If so I could just add new ones to it.


Regards
Brian

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message