Congratulations on the launch. I love the idea and the execution.
When I looked into this a while back I explored using ptrace() to add breakpoints and even add functions at specific line numbers. But ptrace is so slow, and it doesn't work with bytecode-in-VM setups.
What were some of the requirements you guys had when building HyperProbe? I can see low latency was one.
ptrace is too low level and will freeze your process. it cant be used for production debugging i feel.
we work at the application layer by hooking into production grade tooling if available (inspector in v8, sys.monitoring in python) or bytecode manipulation(jvm)
since we arent controlling the application for a different process, we dont need to freeze the app to get the current app state
requirements we had in mind in order of importance
1. safety -> user app needs to function as usual no matter what happens, there shouldnt be an error in the user's app because of us
2. zero idle footprint -> if no probe is active, cpu/memory differency in the user app should be immeasurable
3. zero latency footprint at non probe paths while other probes are active
4. measure mem/cpu footprint directly or via a proxy like eventloop lag and have guardrails around it. suspend probes or even lose snapshot data if guardrail conditions meet
5. minimal mem/cpu footprint for active probes
6. minimal latency foot print for active probe paths
When I looked into this a while back I explored using ptrace() to add breakpoints and even add functions at specific line numbers. But ptrace is so slow, and it doesn't work with bytecode-in-VM setups.
What were some of the requirements you guys had when building HyperProbe? I can see low latency was one.