Tracking Issue: Move JS API out of experimental

[mmarchini]

trafficstars

• [ ] v8 findrefs equivalent
  • List of retainers as a property of heap instances?
• [x] ~v8 bt equivalent~
  • Accessible through LLNode.getProcessObject().threads[0]
• [ ] v8 getactivehandles and v8 getactiverequests equivalent
  • Maybe as a property of the process info
• [ ] Represent value for heap instances as objects instead of strings
• [ ] Make the API async
• [ ] Documentation

Those are the things I noticed missing while playing with the JS API. Feel free to edit, remove or add requirements as you see fit.

[mmarchini]

I think JavaScript developers will expect getProcessObject to return Node.js' process object for the core dump instead of a SBObject representation. Maybe we could have lldb-related methods inside a LLDB class?

[joyeecheung]

I think JavaScript developers will expect getProcessObject to return Node.js' process object for the core dump

Is it even possible to recreate that? process is fairly complex with lots of interceptors/getter/setters. We could return something based on best-effort but it will be pretty far away from the actual process object.

[joyeecheung]

Maybe we should merge getProcessInfo with getProcessObject, and just use the name getProcessInfo.

[joyeecheung]

I'd also add

• Progress reporting when scanning the heap

It's kind of bad that getHeapTypes() could stuck for minutes when being called for the first time. Less of a big deal for the LLDB console because you are already interacting with an interface. I suppose to add progress reporting we would need to break the current API design, e.g. make it async.

[mmarchini]

I think JavaScript developers will expect getProcessObject to return Node.js' process object for the core dump

Is it even possible to recreate that? process is fairly complex with lots of interceptors/getter/setters. We could return something based on best-effort but it will be pretty far away from the actual process object.

I meant a representation of the process object (at least some key information), not the actual object. We already use some heuristics for v8 nodeinfo, maybe we could just expose the information from that command in a structured manner.

It's kind of bad that getHeapTypes() could stuck for minutes when being called for the first time. Less of a big deal for the LLDB console because you are already interacting with an interface. I suppose to add progress reporting we would need to break the current API design, e.g. make it async.

Yep, making the API async sounds like a good idea. I'll add that to the roadmap.