Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unconditional reallocation on the read path #227

Open
Lukasa opened this issue Jun 17, 2020 · 0 comments
Open

Unconditional reallocation on the read path #227

Lukasa opened this issue Jun 17, 2020 · 0 comments
Labels
bug Something isn't working

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Jun 17, 2020

On the read path in SSLConnection.readDataFromNetwork we try to avoid the number of reallocations we perform by using ByteBuffer.writeWithUnsafeMutableBytes(minimumWritableBytes:). We pass SSL_MAX_RECORD_SIZE (16kB) to the minimum size, ensuring we will always be able to write a complete record.

This is reasonable in theory, but it behaves awkwardly when we combine it with the fact that NIOSSLHandler.plaintextReadBuffer is always allocated with an initial size of SSL_MAX_RECORD_SIZE. The reason this is awkward is that we call SSLConnection.readDataFromNetwork in a loop until we get .incomplete. This means that the first time we read any record, the next looped call will ask for 16kB of free space. We won't have it (we just wrote into the buffer!) and so we'll realloc.

In practice, this forces an unconditional realloc at some stage. Not great!

There are two options to resolve this. The first is to change the capacity reservation. We could try to use SSL_pending for this. However, we need to do some investigation before we do that, because SSL_pending doesn't read from the transport, and so it may not always be able to tell us how big this needs to be.

The other option, if the above doesn't work, is simply to immediately allocate the buffer at 2 * SSL_MAX_RECORD_SIZE. In practice this will avoid this unconditional resize, and in most allocators this will also be proxied directly to mmap. That means that if we never end up using the trailing 16kB, nothing bad will happen, as the page will never be faulted in.

@Lukasa Lukasa added the bug Something isn't working label Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant