-
Notifications
You must be signed in to change notification settings - Fork 78
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
Time-Travel diagnostics in Node #164
Comments
Good writeup. I fear the N-API approach is not feasible - adopting that would have a noticeable performance overhead, and I'm not confident if the overall group would accept the tradeoff. |
Is there a way to limit the scope of "A N-API style model needs to be adopted in core so that there are no longer any direct calls through V8 API's." to something smaller than "everything". I agree that we are long way from removing all direct references to v8, but if a smaller subset is possible (even if that only gives us a subset of the history), then there might be a way to move towards incremental progress. Otherwise we are probably stuck with the option of it being implemented in the JavaScript engines for at least a number of years. |
One other option is to take the approach of incrementally moving towards a full N-API implementation via conditional compilation to provide a "diagnostic" build with some overhead and a zero cost production build during the process of N-API'ing code and working out performance issues that arise. The limited scope TTD implementation could be possible but I think it could be difficult for people to understand when/why TTD doesn't work in some cases. |
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made. |
Was going to let this be closed, but @bnb mentioned something about it on Twitter so maybe there's hope this will be a Node.js/V8 feature some day ^^ |
Extending that, if folks have front-end use cases (obviously not the right forum here but want to be clear on my... path to success) and would like to really see this land in Chromium (leading to it being available in Edge, Chrome, Electron, and other Chromium-based projects) please reach out to me. I'd like to chat with you about yourself, why you want it, where you want it, and how it could be valuable to you. |
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made. |
At the Node Diagnostics WG there was discussion around what is needed to make time-travel debugging more generally available. Key work items identified to make this happen include:
Providing TimeTravel as a functionality in Node uniformly instead of as a vendor specific feature is a challenge.
One option is for each vendor to implement it primarily in the VM as is currently done in ChakraCore now. This approach has the upside of requiring minimal changes in Node but is likely to be problematic as it requires extensive duplication of almost identical functionality in each VM providing the support and, in the case of V8 since Node currently calls directly into their raw API's, the addition record/replay support presents potentially large maintainability and performance concerns.
The second approach, as discussed during the WG, involves using N-API to move from direct calls to V8 API's. This has the immediate benefit of a single location to put a large body of common record/replay code currently implemented in Chakra's JsRT host embedding API (for example here, which drives the logger in ChakraCore) with a neutral shared implementation based around the N-API specification. As N-API is at a higher level that JsRT this will also have the benefit of decreasing the overhead of running in record mode. However, there are several items that need investigation/work for this approach:
The text was updated successfully, but these errors were encountered: