-
Notifications
You must be signed in to change notification settings - Fork 30k
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
async-wrap: add provider id and object info cb #1896
Conversation
CHECK(wrapper->IsObject()); | ||
CHECK(!wrapper.IsEmpty()); | ||
Local<Object> object = wrapper.As<Object>(); | ||
AsyncWrap* wrap = Unwrap<AsyncWrap>(object); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I'd prefer to unwrap the instance as the given provider type that's passed, but am coming up short on the necessary syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
guess I could do a massive switch statement, but that feels wrong.
@@ -8,6 +8,8 @@ | |||
|
|||
namespace node { | |||
|
|||
#define ASYNC_ID_OFFSET 0xA1C |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm feeling a little bit un-easy about the magic Class Ids.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a deterministic way to generate a class id? that's pretty much how it's done everywhere else in core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
smalloc is the only other example I can find. We could maintain a central table for classIds. The danger that I am thinking about is if user-space modules need to use use classIds as well and happen to use the same value. It would be nice if one (i.e. user-space or core) could request a classId from the table. That way we can be sure that there won't be collisions.
I am only 'a little bit un-easy', and don't have objections to this PR landing as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. Think that's definitely a PR to explore.
0a87ffd
to
e0268e3
Compare
@@ -43,6 +43,9 @@ | |||
|
|||
startup.processRawDebug(); | |||
|
|||
// Load async_wrap to init the wrapper class info provider. | |||
process.binding('async_wrap'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to just run SetWrapperClassInfoProvider()
from node.cc
, but then I'd have to migrate all the RetainedAsyncInfo
logic as well. Thoughts on a better solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you export a function in src/async-wrap.cc and call that in src/node.cc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oop. Missed this comment. Sounds like a much better alternative.
I see two issues with this PR.
2a. Wastes memory because most instances have a static layout and size. 2b. Probably slows down heap snapshots. 2a and 2b probably aren't that significant so long as there aren't too many |
@bnoordhuis I should have labeled this as WIP. Knew before it was posted that the implementation was incomplete. (1) was my biggest concern while writing this patch, and something I couldn't figure out on my own. Was hoping you'd have a suggestion about how to potentially get around it. Wasn't aware of the issues pointed out in (2). Most of the implementation was pulled directly out of |
I think the easiest solution to (1) is to add a Regarding (2), it would help to have static |
67b3114
to
6965730
Compare
@bnoordhuis Thanks for the reviews. Finished fixing the last round. While I've been wanting a means to do this (furthering use of |
9c78909
to
c47c024
Compare
All test failures are the same:
I doubt it's related to this PR, but don't know for sure. |
@trevnorris the test seems to time out as well. |
@jbergstroem Thank for pointing that out. |
I know this test. It's mine. It was kinda broken while #1400 is merged. |
0890f6c
to
a511c2e
Compare
Started new CI: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/798/ |
a511c2e
to
49d168b
Compare
And again. Something went strange w/ my force push last time. https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/799/ |
CI completed. Same failures as before. None related to this patch. @bnoordhuis if you're okay with the fixes, mind if I merge this? |
: label_(provider_names[class_id - ASYNC_ID_OFFSET]), | ||
wrap_(nullptr), | ||
length_(0) { | ||
CHECK_NE(0xA1C, class_id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Magic constant.
49d168b
to
bb669c4
Compare
@bnoordhuis Thanks much for the additional review. All points have been addressed. |
Re-add the wrapper class id to AsyncWrap instances so they can be tracked directly in a heapdump. Previously the class id was given without setting the heap dump wrapper class info provider. Causing a segfault when a heapdump was taken. This has been added, and the label_ set to the given provider name so each instance can be identified. The id will not be set of the passed object has no internal field count. As the class pointer cannot be retrieved from the object. In order to properly report the allocated size of each class, the new pure virtual method self_size() has been introduces.
bb669c4
to
5e792aa
Compare
LGTM at a glance. |
Getting the following from centos5-32:
Don't know how it could be related, so going to say that tests are looking good. |
Re-add the wrapper class id to AsyncWrap instances so they can be tracked directly in a heapdump. Previously the class id was given without setting the heap dump wrapper class info provider. Causing a segfault when a heapdump was taken. This has been added, and the label_ set to the given provider name so each instance can be identified. The id will not be set of the passed object has no internal field count. As the class pointer cannot be retrieved from the object. In order to properly report the allocated size of each class, the new pure virtual method self_size() has been introduces. PR-URL: #1896 Reviewed-By: Ben Noordhuis <[email protected]>
Landed in e56758a. Thanks @bnoordhuis for the reviews. |
Re-add the wrapper class id to AsyncWrap instances so they can be
tracked directly in a heapdump.
Previously the class id was given without setting the heap dump wrapper
class info provider. Causing a segfault when a heapdump was taken. This
has been added, and the label_ set to the given provider name so each
instance can be identified.
R=@bnoordhuis
For performance testing I ran the following:
It was the most direct way I found to instantiate a new
AsyncWrap
instance from JS. It shows no performance degradation with this patch applied.