2016-01-28 20:22 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 28 January 2016 15:11:03 GMT+00:00, "Rémy Maucherat" <r...@apache.org> > wrote: >>2016-01-28 15:53 GMT+01:00 Mark Thomas <ma...@apache.org>: >> >>> On 28/01/2016 14:16, Konstantin Kolinko wrote: >> >> I have always used local encoders and decoders, nobody ever >>complained >>about memory use so it's most likely not a problem. > > I need to check the history (I'm on my phone rather than at my computer) but > I think I add the caches to reduce GC churn. They certainly helped when I > added them but it is worth revisiting if we should cache them at all. >
1. The javadoc in SynchronizedStack says "This is intended as a (mostly) GC-free alternative to ConcurrentLinkedQueue" So it looks that we tried the concurrent linked queue as well. 2. This class is present in TC8 and TC 9. Looking for references, it is used a lot. E.g. InputBuffer.encoders, NioEndpoint.processorCache. If removal of this class gives noticeable +2% - +4%, it is troubling. It may apply to all other uses as well. Maybe some simple improvement can be there. E.g. empty cache can be signaled by volatile size field, without a need for synchronization. Or split it into compartments (e.g. by this.hashCode() of the calling class). 3. I do not like this solution, but I do not have enough evidence to veto it for an OutputBuffer. Still, a) it makes an assumption that output encodings of a web application cannot be controlled by client. (I agree that it is likely that a web application uses a small fixed number of output encodings). HTTP/1.1 declared an "Accept-Charset" header. (RFC 7231 5.3.3.) In theory it can be used to ask the server to return content in that encoding. b) HashMap was optimized in Java 8. I think that in Java 7 and earlier it may waste more memory than your numbers show. 4. This solution cannot be applied to InputBuffer, due to DoS/OOM threat, as that processes client data. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
