rschmitt commented on PR #578: URL: https://github.com/apache/httpcomponents-core/pull/578#issuecomment-3764386779
> @olegk @rschmitt How should I proceed here? The advantage of pooling (or of more aggressive buffer reuse) is that we can reduce ephemeral garbage from the client. The risks are: 1. We could leak memory (can be mitigated by following Aleksey's suggestion, i.e. transfer ownership of a buffer to and from the pool instead of the pool holding a reference to leased-out buffers) 2. We could leak data by leasing out previously used buffers (can be mitigated by zeroing out buffers upon return to the pool) 3. Buffers could be aliased internally, or references to buffers could leak outside of the client, resulting in corruption or potentially a security vulnerability (e.g. disclosure of plaintext, disclosure of request or response data across HTTP exchanges) The third risk has no comprehensive mitigation in Java, we simply have to be able to tell by inspecting the code that there are obviously no issues like this. Before we proceed with any code changes, I think we should profile the client first to see what is actually allocating the most ephemeral garbage internally. If nobody has done this in a while, then there are probably some easy wins available. A simple example is `EntityUtils`, which has several fixed `new byte[]` and `new char[]` allocations that could trivially be replaced with thread-local buffers, no object pooling necessary; `EntityUtils::toString` shouldn't need to allocate any memory other than the `String` it returns. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
