Set up virtual field transforms before otel sdk is initialized

[laurit]

Hopefully resolves #12303
Set up virtual field transforms for executors instrumentation before otel sdk is initialized. This should reduce usage of the fallback map.

[trask]

cc @JonasKunz @SylvainJuge in case one of you happens to have time to review

[JonasKunz]

LGTM, I just wonder where the actual memory leak in #12303 you think comes from?

In order for an entry in WeakHashMap to leak, the value (e.g. the Otel context) needs to have a transitive reference to the key with which it is stored in the map. I currently can't imagine how the Otel-context would have a reference to e.g. it's FutureTask? If you have any explanation that would be appreciated, but it shouldn't block this PR.

[JonasKunz]

Are there any things an EarlyInstrumentationModule must not do in it's constructor / static initializers? E.g. logging maybe?

If yes, it would be great to add those restrictions to the javadoc.

[laurit]

Since we are not fully set up when we start looking for EarlyInstrumentationModule instances there definitely will be things, such as reading configuration, that won't work. In this PR I moved calling ExperimentalConfig.get() out of the static initializer of InstrumentationModule. In my opinion it is too hard to predict what exactly can or can not be called. I would deal with these issues as they come up. There is a good chance there only the executor instrumentation will use EarlyInstrumentationModule.

[laurit]

LGTM, I just wonder where the actual memory leak in #12303 you think comes from?

In order for an entry in WeakHashMap to leak, the value (e.g. the Otel context) needs to have a transitive reference to the key with which it is stored in the map. I currently can't imagine how the Otel-context would have a reference to e.g. it's FutureTask? If you have any explanation that would be appreciated, but it shouldn't block this PR.

I don't think there is a leak in that sense. Without a heap dump we can only speculate what is going on. My guess is that everything in the weak map can be collected, but since the app is running with a large heap gc lets the virtual field maps grow very large. We could approach this either by avoiding the fallback map for virtual fields or by setting the field to null when we are done with. #12397 implements clearing virtual field on runnables. We'd also need to clear the virtual field on futures, but this is a difficult. Probably it would make sense to restrict the future instrumentation to more specific futures such as FutureTask where we could clear the state immediately when the value is set for the future. Or we could drop the future instrumentation altogether.

[trask]

thanks @JonasKunz!