3 ms·
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 ad
by kirtivr 2mo ago
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.
- karanraina 2mo agoptrace 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