Associate value with class loader #10051
Conversation
|
@JonasKunz could you review whether this would be useful for #10015 |
|
👍 |
There was a problem hiding this comment.
I think this will simplify #10015 significantly:
We can then just eagerly create the InstrumentationModuleClassloader when a TypeInstrumentation is matched.
I'll use ClassLoaderValue<Map<String, InstrumentationModuleClassloader>>, where the String-keys are the module group names.
This also solves the TypePool question when injecting proxies: We'll be able to use a normal TypePool for the eagerly created InstrumentationModuleClassloader here.
Where it unfortunately doesn't help is with the TypePool for the muzzle-matcher, but that is okay I guess.
I'll updated my PR once this one is merged, nice work!
| private static final Cache<ClassLoader, WeakReference<Map<Object, Object>>> data = Cache.weak(); | ||
|
|
||
| public static Object get(ClassLoader classLoader, Object key) { | ||
| return getClassLoaderData(classLoader).get(key); |
There was a problem hiding this comment.
[nitpick] might consider adding a boolean initialize parameter to getClassLoaderData so that we don't do the heavy initialization work when just checking for the presence of a key.
If initialize = false, getClassLoaderData will return null if the map for the classloader hasn't been initialized yet.
Added value will behave as if it was stored in a field in the class loader object, meaning that the value can be garbage collected once the class loader is garbage collected and referencing the class loader from the value will not prevent garbage collector from collecting the class loader.
Hopefully this will help with the indy instrumentation as this will let us associate
InstrumentationModuleClassLoaderand whatever else is needed with the application class loader without the need to use weak references and fear that our stuff gets collected before the class loader.