On 28/01/2016 17:49, Konstantin Kolinko wrote: > 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.
Back at my computer. I wrote this from scratch as a replacement for ConcurrentLinkedQueue because it was generating huge amounts of garbage under load. > 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. Non of the other uses have shown up in the profiler so far. Testing some other connectors wouldn't hurt though. > 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). The synchronization was the main bottleneck. > 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. If we remove the caching entirely, that problem goes away. > b) HashMap was optimized in Java 8. I think that in Java 7 and earlier > it may waste more memory than your numbers show. Quite likely. I'm not planning on back-porting it at this point. I wonder if the encoders are more efficient too. > 4. This solution cannot be applied to InputBuffer, due to DoS/OOM > threat, as that processes client data. Agreed. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
