Add build-time auto-instrumentation for @WithSpan

[breedx-splk]

Would be nice if we could leverage the @WithSpan attribute from the upstream instrumentation repo and have build-time bytecode weaving to support it in user code.

Start by looking at WithSpanInstrumentation (link).

[gilgoldzweig]

I know this is an old issue. If I'm not mistaken, Android doesn't support the Java agent needed to automate this process; however, I think we can get something very close by building a compiler plugin, in Kotlin, this can probably get done by using the K2/IR plugin, which will allow us to modify the code not at the bytecode level but at the IR level.
I can probably help with it and write the plugin if there is enough interest!

[breedx-splk]

Thanks @gilgoldzweig yeah that's interesting. We are using bytebuddy gradle plugin elsewhere, so doing it at the IR level with a K2 plugin would diverge from this. I'm not against that, but it does make things a bit more complicated and it would be cool if we had a strategy for consolidating or being eventually consistent in our use of build-time tools. Specifically, I wonder if there's room/desire for us to migrate our existing bytecode instrumentation to the K2/IR level. I know @LikeTheSalad has a lot of experience as well with gradle plugins, and I'm curious what he might think.

I don't have a good sense of how much work it would be to build/support a K2 plugin for this, but maybe a rough draft PR could help show this. Thanks again!

[gilgoldzweig]

That sounds interesting as well, I was just suggesting because that would lift a good chunk of our reliance of java.
However, I'm interested in contributing in general so if there are different avenues you prefer to focus on, I'm open for suggestions!

[fractalwrench]

My understanding is that K2 plugins won't run on Java so auto-instrumentation wouldn't work in any app code containing Java. As a rough guess I'd assume that >80% of the average Android app codebase is in Kotlin these days, but there will be legacy code written in Java that is still kicking around.

I'd be interested in discussing K2/WebObject ASM/ByteBuddy usage more generally. In an ideal world we would pick auto-instrumentation tooling that operates at build-time and runs on both Kotlin/Java code. Perhaps a separate issue would be better?

[Kleszczu98]

My proposal for this feature using byteBuddy and kotlin #1348
Let me know if this solution works for you or if there's any improvement to be made.

There is some TODOs still that I'm aware of, just wanted to make sure this is the right approach.

[LikeTheSalad]

I think an IR plugin sounds very interesting and it might be ideal for some cases, especially around Kotlin-specific apis, but apart from that I agree with @fractalwrench that we shouldn't neglect projects that make use of Java. Plus, my understanding is that IR plugins won't work for instrumenting dependencies, even if the source code was written in Kotlin, because once it's compiled is platform-specific. So I think it's better to stick to bytecode weaving in general.

Still, I'm curious if IR plugins could make our lives easier with some Kotlin-specific apis 🤔 such as coroutines and composables, because those tend to translate into complicated bytecode. I remember that Lauri had to write a lot of plain ASM to make @WithSpan work on coroutines, for example. So I'd be interested to know if IR plugins might make things easier for these specific situations.

[gilgoldzweig]

I agree with all the comments above! I'm not stating we should drop the agent! I think they can potentially work together!
For code like coroutines and compose it would most likely make everyone live a LOT easier, because at that stage of the compilation cycle you work on "raw" Kotlin code similar to an Abstract Syntax Tree and you can modify it as you'd like so no need for asm.

[LikeTheSalad]

I agree with all the comments above! I'm not stating we should drop the agent! I think they can potentially work together! For code like coroutines and compose it would most likely make everyone live a LOT easier, because at that stage of the compilation cycle you work on "raw" Kotlin code similar to an Abstract Syntax Tree and you can modify it as you'd like so no need for asm.

Sounds good! - So based on what you mention, it looks like an IR plugin might complement a @WithSpan instrumentation for when it needs to address suspended functions, for example. I'm trying to find a way forward with this approach, though since we don't even have a "regular" instrumentation for @WithSpan, there's nothing we could "complement" with an IR plugin that I'm aware of. I just started to take a look at @Kleszczu98's proposal for a regular @WithSpan instrumentation.

The only other work that I think IR plugins might be able to help with, is this one about propagating OTel contexts to coroutines (it also seems quite popular based on upvotes). If you're interested in taking a look, that's probably a good candidate for a poc.