Deprecating the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods

[JacksonTian]

When I browse the source code of src/node.cc, I found _startProfilerIdleNotifier & _stopProfilerIdleNotifier methods. These methods never be documented and haven't any test cases in test/*.

I am proposing that we can mark the two methods as deprecated and remove later.

In user land, v8-profiler can do things better.

If no against for this proposal, I will start the work.

CC @nodejs/collaborators

[bnoordhuis]

I know I added them but I'll be damned if I remember why. I'm good with removing them.

[mcollina]

👍 to remove or runtime-deprecate them.

[benjamingr]

Anyone using these methods in userland?

[ofrobots]

Just found this issue while trying to understand why Node doesn't notify the VM for idle phases by default.

I don't know the motivation that @bnoordhuis had originally. My motivation is from a profiler perspective. A profiler (e.g. Chrome DevTools) should be able to distinguish JS execution vs. native execute vs. idle time. Currently, when no JS is executing, the profiler has no idea if Node was spending time in C++ or was really idle.

Apart from the the diagnostic use-case, I think the VM might also be able to get a better idea of process load based on how busy the host (Node) seems to be, and might be able to take advantage of this in tweaking GC and background compilation heuristics. This is not profiling specific.

IOW, I think we should

1. Perform idle notifications by default. I think the current mechanism (uv_prepare_t, uv_check_t) might do a few too many notifications (once per loop iteration). I think this can be improved.
2. If we do that, we do not need to expose these functions to JavaScript. I'm +1 on deprecating and removing these, if we do the previous bullet (I'd be happy to go implement that).

WDYT? Any concerns/objections?

[joyeecheung]

@ofrobots (This may not be helpful but FWIW) I think I've seen somewhere in the comments that the idle notifications in core were removed because they "did not work well". But those notes were ancient and it's probably not a bad time to revisit this and integrate the core better with the VM.

[ofrobots]

@joyeecheung thanks! if you have pointers to some of these discussions, those would be very useful for me. Perhaps you were thinking of requestIdleCallback (#2543) – which is something very different?

[joyeecheung]

@ofrobots Did some archeology and I am pretty sure I was talking about d607d85 although it seems specific to regulating GC

[Yogu]

@ofrobots I don't know any node internals, but I'm 100% with you on enabling these by default (if there are no significant performance problems). And thanks a lot for this PR where you fixed it in a project - I shamelessly copied it into my project to get idle times working. ❤️

[Trott]

Looks like these are now in src/node_process_methods.cc.

What's the status of this?

1. Perform idle notifications by default. I think the current mechanism (uv_prepare_t, uv_check_t) might do a few too many notifications (once per loop iteration). I think this can be improved.
2. If we do that, we do not need to expose these functions to JavaScript. I'm +1 on deprecating and removing these, if we do the previous bullet (I'd be happy to go implement that).

Did the first bullet point ever happen? If not, is there someone motivated to implement it? I don't get the impression that either @JacksonTian or @ofrobots are terribly active on the project these days, but I'd be thrilled to see them or anyone else jump in on this to get it across the finish line.