<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 May 2018 at 06:03, Loïc Gelle <span dir="ltr"><<a href="mailto:loic.gelle@polymtl.ca" target="_blank">loic.gelle@polymtl.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi,<div><br></div><div>There has been a previous discussion on the mailing list about porting LTTng to Golang, about a year ago: <a href="https://lists.lttng.org/pipermail/lttng-dev/2017-June/027203.html" target="_blank">https://lists.lttng.org/<wbr>pipermail/lttng-dev/2017-June/<wbr>027203.html</a> . This new topic is to discuss more precisely about implementation possibilities.</div><div><br></div><div>Currently, one has to use the the C UST agent from LTTng in order to instrument Golang programs, and to compile the whole thing using custom Makefiles and cgo. Here is a recent example that I wrote: <a href="https://github.com/loicgelle/jaeger-go-lttng-instr" target="_blank">https://github.com/<wbr>loicgelle/jaeger-go-lttng-<wbr>instr</a></div><div><br></div><div>As you can guess, there are a low of drawbacks in that approach. It is actually a hack and cannot be integrated into more complex Golang program that use a more complex build process (e.g. the Golang runtime itself), because of the compiler instructions that you have to include at the top of the Golang files. There is also a big concern about the performance of this solution, as calling a C function from Go requires to do a full context switch on the stack, because the calling conventions in C and Golang are different.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>I think a more integrated and performant solution is needed. We can’t really ignore a language such as Golang that is now widely adopted for cloud applications. LTTng is really the best solution out there in terms of overhead per tracepoint, and could benefit from being made available to such a large community. My question to the experts on this mailing list: how much would it take to write a Golang agent for LTTng?</div></div></blockquote><div><br></div><div><div><br></div><div>Hi Loïc,</div><div><br></div><div>Without having performed any measurements myself, it does seem like calling C from Go is very expensive. In that context, I can see that LTTng would probably lose its performance advantage over any native Go solution. However, it wouldn't hurt to measure the impact and see if it really is a deal breaker.<br></div><div><br></div><div><div>We faced the same dilemma when implementing the Java
 and Python support in lttng-ust. In those cases, we ended up calling C 
code, with the performance penalties it implies. The correlation with 
other applications' and the kernel's events, along with the rest of LTTng's features, provided enough value to 
make that solution worthwhile.<br></div><div><br></div></div><div>There aren't a ton of solutions if we can't call existing C code. We basically have to reimplement a ring-buffer and the setup/communication infrastructure to interact with the lttng-sessiond. The communication with the session daemon is not a big concern as the protocol is fairly straightforward.</div><div><br></div><div>The "hairy" part is that lttng-ust and lttng-consumerd use a shared memory map to produce and consume the tracing buffers. This means that all changes to that memory layout would need to be replicated in the Go tracer, making future evolution more difficult. Also, I don't know how easy it would be to synchronize C and Go applications interacting in a shared memory map given those languages have different memory models. My knowledge of Go doesn't go that far.<br></div><div><br></div><div>A more viable solution could be to introduce a Go-native consumer daemon implementing its own synchronization with Go applications. This way, that implementation could evolve on its own and could also start with a simpler ring buffer than lttng-ust's.<br></div><div></div><div><br></div><div>Still, it is not a small undertaking and it basically means maintaining a third tracer implementation.<br></div></div><div></div><div><br></div><div><br></div><div>What do you think?<br></div><div><br></div><div>Thanks!<br></div><div>Jérémie<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>Cheers,</div><div>Loïc.</div></div><br>______________________________<wbr>_________________<br>
lttng-dev mailing list<br>
<a href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a><br>
<a href="https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">https://lists.lttng.org/cgi-<wbr>bin/mailman/listinfo/lttng-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Jérémie Galarneau<br>EfficiOS Inc.<br><a href="http://www.efficios.com" target="_blank">http://www.efficios.com</a></div>
</div></div>