Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All my favorite tracing tools

thume.ca

Post reply on HN
Print view View original

31–40 of 42 posts

Re: All my favorite tracing tools

#31

Post by saagarjha »

mark_undoio wrote: post #28
Veserv wrote: post #26

Earlier quoted context omitted.

Not that I am aware of. They phase in and out of existence every so often because developing the technology is expensive and requires constant maintenance, but nobody wants to pay for tools so they never catch on with enough resources to stay maintained.

As byefruit says above - we (undo.io) sell a Java Time Travel Debugger. If anybody wants to try it, they should get in touch with us. Our Java tech is based on an underlying record/replay engine that works at the level of machine instructions / syscalls to record the entire process. On top of that we've added the necessary cleverness to show what that means at Java level (so normal source-level debugging works). That…

This would be heavily tied to the JVM you’re using, no? Do you have to keep updating this as it evolves?

Re: All my favorite tracing tools

#32

Post by felixrieseberg »

I wish the industry had a better answer for deterministically profiling the execution cost of JavaScript. Attempts were made in Chromium by hooking into Linux perf, but that change has since been removed.

If anyone has any tips on how to trace JavaScript (not just profile by time, but deterministically measure the cost of it in CI), I'd love to hear tips!

Re: All my favorite tracing tools

#33

Post by mark_undoio »

saagarjha wrote: post #31
mark_undoio wrote: post #28

Earlier quoted context omitted.

As byefruit says above - we (undo.io) sell a Java Time Travel Debugger. If anybody wants to try it, they should get in touch with us. Our Java tech is based on an underlying record/replay engine that works at the level of machine instructions / syscalls to record the entire process. On top of that we've added the necessary cleverness to show what that means at Java level (so normal source-level debugging works). That…

This would be heavily tied to the JVM you’re using, no? Do you have to keep updating this as it evolves?

The short answer is yes - but not as tightly as you'd think. We don't need a deep awareness of what the JVM is doing, e.g. its internal data structures are largely opaque to us.

When we need to reconstruct state we always have the option of time travelling the process and re-executing to drill down on the details, though that's only required when you're replaying a recording.

Re: All my favorite tracing tools

#34

Post by inetknght »

mark_undoio wrote: post #18
trishume wrote: post #3

Earlier quoted context omitted.

Do you know of anyone who's built that kind of time travel debugging with a trace visualization in the open outside of Javascript? I know about rr and Pernosco but don't know of trace visualization integration for either of them, that would indeed be very cool. I definitely dream of having systems like this.

At undo.io we're interested in using our time travel capability beyond conventional time travel debugging - a recording file contains everything the program did, without any advance knowledge of what you need to sample, so there's a lot of potential to get other data out of it. I just read your post and don't think it would take much to integrate with some of the visualisations you posted about, as a first step. We'v…

I've seen undo.io several times at cppcon. I've been throughly impressed with the demonstrations at the conference and came to this thread specifically to recommend undo.io. I was particularly impressed this year by a demonstration of debugging stack smashing -- that's something I recently worked around stack smashing in protobuf which happens before `main()` even starts. It seems perfect for undo.io to help debug :)

I'm still waiting on the keyserver to be able to run in Kubernetes though

Re: All my favorite tracing tools

#35

Post by mark_undoio »

mark_undoio wrote: post #33
saagarjha wrote: post #31

Earlier quoted context omitted.

This would be heavily tied to the JVM you’re using, no? Do you have to keep updating this as it evolves?

The short answer is yes - but not as tightly as you'd think. We don't need a deep awareness of what the JVM is doing, e.g. its internal data structures are largely opaque to us. When we need to reconstruct state we always have the option of time travelling the process and re-executing to drill down on the details, though that's only required when you're replaying a recording.

(the result is that it's quite feasible to update to new JVMs and to support multiple at once)

Re: All my favorite tracing tools

#36

Post by saagarjha »

mark_undoio wrote: post #35
mark_undoio wrote: post #33

Earlier quoted context omitted.

The short answer is yes - but not as tightly as you'd think. We don't need a deep awareness of what the JVM is doing, e.g. its internal data structures are largely opaque to us. When we need to reconstruct state we always have the option of time travelling the process and re-executing to drill down on the details, though that's only required when you're replaying a recording.

(the result is that it's quite feasible to update to new JVMs and to support multiple at once)

Hmm, so what do you do to answer questions like "what code corresponds to this address" or "what object is this allocation"? Run the recording, ask the JVM itself using its introspection interfaces in your replay by forking it?

Re: All my favorite tracing tools

#38

Post by mark_undoio »

mark_undoio wrote: post #29
rubyissimo wrote: post #24

Earlier quoted context omitted.

how long can you time-travel? is this something like https://www.reddit.com/r/ruby/comments/15o9hc1/timetraveling... ?

Conceptually similar in that you can decide after-the-fact what state you want to see. But Time Travel Debugging applies that to everything in the program, not just log statements - all function calls, variables, memory locations, etc can be reconstructed after the fact without having to log them explicitly.

Oh, and regarding how long - it depends how long it takes to fill the circular buffer of non deterministic behaviour.

Serious compute bound workloads can run days with a gigabyte of non deterministic event log. Serious IO bound workloads burn it much faster.

For a rule of thumb, think of it consuming a few MB per second, so the length of the time travel is limited by how much of that you can store.

Re: All my favorite tracing tools

#39

Post by mark_undoio »

saagarjha wrote: post #36
mark_undoio wrote: post #35

Earlier quoted context omitted.

(the result is that it's quite feasible to update to new JVMs and to support multiple at once)

Hmm, so what do you do to answer questions like "what code corresponds to this address" or "what object is this allocation"? Run the recording, ask the JVM itself using its introspection interfaces in your replay by forking it?

At lower optimisation levels there's a register allocated by the JVM to refer back to the bytecode, which makes things easy. In principle they could change that with a JVM revision - but in practice they don't, so it's an easy cheat.

We have some ability to walk data structures and the re-compute the program's behaviour by other means, which I probably shouldn't get into here. I think we could fall back on that more-or-less completely if we couldn't retrieve the bytecode pointer directly.

The fact the JVM introduces Safe Points to help it transition between optimisation levels is quite helpful!

Our original intention was to always fork a copy of the JVM back in time to handle Java debug protocol requests but that turned out to be painful and, thankfully, also unnecessary.

Re: All my favorite tracing tools

#40

Post by mark_undoio »

inetknght wrote: post #34
mark_undoio wrote: post #18

Earlier quoted context omitted.

At undo.io we're interested in using our time travel capability beyond conventional time travel debugging - a recording file contains everything the program did, without any advance knowledge of what you need to sample, so there's a lot of potential to get other data out of it. I just read your post and don't think it would take much to integrate with some of the visualisations you posted about, as a first step. We'v…

I've seen undo.io several times at cppcon. I've been throughly impressed with the demonstrations at the conference and came to this thread specifically to recommend undo.io. I was particularly impressed this year by a demonstration of debugging stack smashing -- that's something I recently worked around stack smashing in protobuf which happens before `main()` even starts. It seems perfect for undo.io to help debug :)…

> I was particularly impressed this year by a demonstration of debugging stack smashing

I'm glad you liked it - and that's useful feedback for other demos we give!

> I'm still waiting on the keyserver to be able to run in Kubernetes though

I believe support for that is on the way. If you're already in touch then I imagine you'll get an announcement soon.

Post reply on HN