Remove VirtualField agent fallback to weak map

[trask]

See discussion at #4218 (comment)

In particular, the benefit of avoiding the fallback is that it can lead to memory leaks if not careful (e.g. #441 and #3027).

One concern about removing the fallback was identified:

there is hack that skips field injection on classes annotated with javax.decorator.Decorator

I think my comment was not correct:

I wonder if the javax.decorator.Decorator hack is needed since #3948

because it looks like the javax.decorator.Decorator hack is just an ignore matcher.

@laurit just confirming that I understand your concern correctly, does the concern apply to everything in ignores matchers? and if that's the case, if we remove the fallback, wouldn't tests for any instrumentation that uses a VirtualField key that is in an ignore matcher fail?

[laurit]

I meant

opentelemetry-java-instrumentation/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/context/FieldBackedProvider.java

Line 404 in 635acd4

.and(InstrumentationModuleInstaller.NOT_DECORATOR_MATCHER)

this is separate from ignores matcher. I don't think ignore matcher applies to field injection.
If we decide to remove the fallback then we have to keep in mind that there are classes that don't have the field. We add field to all subclasses of Runnable. Thread is a Runnable, but doesn't have the fields because it is loaded too early.

[laurit]

Field injection could also fail when hasSuperType matcher can't find some super types. This happens when getResourceAsStream of class loader that defines the class can't find bytes for some of the super types. It could be that this class loader doesn't implement getResourceAsStream in a sensible way or defined class has a generated super type (ClassLoader.getResourceAsStream won't find anything for generated classes) or in osgi it should be possible to have class hierarchies where class sees its immediate super types but not their super types.

[trask]

@laurit do you think there's anything to be done here, or should we close it?

[laurit]

@trask I think we should close this. There are classes that are loaded before field injection is set up and rely on the fallback to function properly, for example java.util.concurrent.FutureTask.
To find classes that rely on fallback you can print out the key in

opentelemetry-java-instrumentation/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/field/VirtualFieldImplementationsGenerator.java

Line 295 in 865a4bb

return map.get(key);

and run executor tests.