-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
tls_wrap: Unlink TLSWrap and SecureContext objects asap. #1580
Conversation
Just tested — the same results are applicable to the server — a full gc run goes from ~30ms to ~14ms. |
Full stack trace:
Looking into it... |
`StreamBase::AfterWrite` is passing handle as an argument to the `afterWrite` function in net.js. Thus GC should not collect the handle and the request separately and assume that they are tied together. With this commit - request will always outlive the StreamBase instance, helping us survive the GC pass. Fix: nodejs#1580
Should be fixed by #1590 |
Yes, that issue is fixed by #1590 for me. It didn't affect the GC timings I posted above. |
`StreamBase::AfterWrite` is passing handle as an argument to the `afterWrite` function in net.js. Thus GC should not collect the handle and the request separately and assume that they are tied together. With this commit - request will always outlive the StreamBase instance, helping us survive the GC pass. Same applies to the ShutdownWrap instances, they should never be collected after the StreamBase instance. Fix: #1580 PR-URL: #1590 Reviewed-By: Ben Noordhuis <[email protected]>
7fa24d6
to
0bc9ec8
Compare
Rebased against current master (with #1590 fix), the timings are about the same as above so I won't copy them here again. |
Is there any reason to use I wonder that it deletes properties defined in a constructor so that it would break a reference to the hidden class. Substituting master
this PR
PR without using delete. diff --git a/lib/_tls_wrap.js b/lib/_tls_wrap.js
index c0edd0e..0a30cd3 100644
--- a/lib/_tls_wrap.js
+++ b/lib/_tls_wrap.js
@@ -302,9 +302,9 @@ TLSSocket.prototype._destroySSL = function _destroySSL() {
this.ssl.destroySSL();
if (this.ssl._secureContext.singleUse) {
this.ssl._secureContext.context.close();
- delete this.ssl._secureContext.context;
+ this.ssl._secureContext.context = null;
}
- delete this.ssl;
+ this.ssl = null;
};
TLSSocket.prototype._init = function(socket, wrap) {
|
0bc9ec8
to
725d7ba
Compare
@shigeki No, there is no specific need in |
LGTM to me too, landing. |
Oh, @ChALkeR ! May I ask you to review this paragraph of the CONTRIBUTING.md: https://github.com/iojs/io.js/blob/master/CONTRIBUTING.md#step-3-commit Particularly, please format the commit log according to it, and please add some contents to it as well ;) Thank you again! |
725d7ba
to
f214b9a
Compare
This makes `TLSWrap` and `SecureContext` objects collectable by the incremental gc. `res = null` destroys the cyclic reference in the `reading` property. `this.ssl = null` removes the remaining reference to the `TLSWrap`. `this.ssl._secureContext.context = null` removes the reference to the `SecureContext` object, even though there might be references to `this.ssl._secureContext` somewhere. The `reading` property will now throw an error if accessed after the socket is closed, but that should not happen.
f214b9a
to
9ab8f9d
Compare
@indutny I added info from the PR to the commit message. Rebased against current master. |
This makes `TLSWrap` and `SecureContext` objects collectable by the incremental gc. `res = null` destroys the cyclic reference in the `reading` property. `this.ssl = null` removes the remaining reference to the `TLSWrap`. `this.ssl._secureContext.context = null` removes the reference to the `SecureContext` object, even though there might be references to `this.ssl._secureContext` somewhere. The `reading` property will now throw an error if accessed after the socket is closed, but that should not happen. PR-URL: #1580 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
Landed in f7620fb, thank you! |
Thanks! |
`StreamBase::AfterWrite` is passing handle as an argument to the `afterWrite` function in net.js. Thus GC should not collect the handle and the request separately and assume that they are tied together. With this commit - request will always outlive the StreamBase instance, helping us survive the GC pass. Same applies to the ShutdownWrap instances, they should never be collected after the StreamBase instance. Fix: nodejs#1580 PR-URL: nodejs#1590 Reviewed-By: Ben Noordhuis <[email protected]>
This makes `TLSWrap` and `SecureContext` objects collectable by the incremental gc. `res = null` destroys the cyclic reference in the `reading` property. `this.ssl = null` removes the remaining reference to the `TLSWrap`. `this.ssl._secureContext.context = null` removes the reference to the `SecureContext` object, even though there might be references to `this.ssl._secureContext` somewhere. The `reading` property will now throw an error if accessed after the socket is closed, but that should not happen. PR-URL: nodejs#1580 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
This makes
TLSWrap
andSecureContext
objects collectable by the incremental gc.res = null;
destroys the cyclic reference in thereading
property,delete this.ssl
removes the remaining reference.delete this.ssl._secureContext.context;
makes SecureContext objects collectable by the incremental gc even though there might be references tothis.ssl._secureContext
somewhere.The
reading
property will throw an error if accessed after the socket is closed. If this is unwanted then the property getter/setter should be altered.Can someone please comment on this part?Should be ok as it is.Test results for 20000 opened-closed non keep-alive connections to localhost (100 parallel requests):