pool async state in SslStream

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)

[wfurt]

fixes#68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

fixes #68467

I had simple test code like

using(varsslClient=newSslStream(_client,leaveInnerStreamOpen:true,delegate{returntrue;}))using(varsslServer=newSslStream(_server,leaveInnerStreamOpen:true,delegate{returntrue;})){awaitTask.WhenAll(sslClient.AuthenticateAsClientAsync(clientOptions),sslServer.AuthenticateAsServerAsync(serverOptions));for(intj=0;j<100;j++){vart=sslClient.ReadAsync(_clientBuffer,CancellationToken.None);awaitsslServer.WriteAsync(_serverBuffer,CancellationToken.None);awaitt;}}

before the change it would allocate

after the change

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	-

[stephentoub]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect. Pooling the read method objects seems fairly reasonable, as in general we expect the SslStreams themselves to be relatively long-lived, pooled themselves as part of a connection pool. One of the difficulties with object pooling is that it can create artificial references from gen2 to gen0, and so if the state you're using is itself likely to be gen2, this negative aspect of pooling mostly goes away. With Connection: close, though, that suggests this is a scenario where these streams aren't being pooled and are much less likely to be gen2, and as such it's more likely that pooling the state machines will end up creating gen2 to gen0 references.

[wfurt]

EnsureFullTlsFrameAsync is also used in handshake so it should help little with Connection: close as well.

If you want to use it here, go ahead. But FWIW I think this case is a little more suspect.

The EnsureFullTlsFrameAsync as also called from Read so it is on hot path. I did not touch methods that are only in handshake e.g. called once per session. There are still easier wins for handshake.

[rzikm]

The changeset now seems to include #69527, was this intentional?

[wfurt]

no, it was not intentional @rzikm.

[davidfowl]

Nice! Are the other allocations the handshake?

[wfurt]

There are some @davidfowl. Some are easy to avoid some of them are more tricky.

It would be great if you can share any real workload you care about. With that we can investigate allocations as well as other runtime parts.

[rzikm]

LGTM

[wfurt]

Failing Quic tests are unrelated and will be fixed by #69709 (msquic upgrade)