3 ms·
I see the current arch uses a separate process. Is the JVM integration likely to follow the same path or use a Java Agent? Very cool project, continuous profi
by jpgvm 6y ago
I see the current arch uses a separate process.
Is the JVM integration likely to follow the same path or use a Java Agent?
Very cool project, continuous profiling, distributed tracing and always-on debugging are production tooling I feel will eventually become common place just need to crack through the YAGNI by making them easier to obtain.
- petethepig 6y agoI think for languages like Java we're gonna have the profiler run inside the profiled process. This is how it currently works in our Go integration. RE continuous profiling and things: that's our hope as well. At my last job I got a lot of people to start using these kinds of tools and it's fun to watch this technology adoption process that goes from "why do I need this?" to "I remember you showed me this once, how do I use it again?" to "wow, this saved us so much time / money". It's a bit of an uphill battle, but we're hopeful because there's clearly value in these tools.
- jpgvm 6y agoThat is good news. I think Java Agent is definitely the way to go for JVM. Gives you all the access and APIs you need with low resource usage and only need to drop file in place add flag to JVM. If you don't need the C API you can also write the agent in a JVM language which obviates the need platform specific binaries. Agree wholeheartedly on direction, I'm hoping for a final phase of "of course we have that" but maybe that is wishful thinking considering not even good metrics are a given in many shops still but we can hope for a better future.