ctubbsii opened a new pull request, #39: URL: https://github.com/apache/accumulo-classloaders/pull/39
I have been trying to find a way to clean up the URLClassLoader instances, while still keeping them in the deduplication cache. The problem is that the cleaner registration has to watch the reachability of a wrapper object, because the clean action cannot have a strong reference to the monitored object that triggers the clean. Conversely, the deduplication cache needs to track references to the classloader itself, because that is kept alive by the existence of any classes that it loaded. The deduplication cache cannot track a wrapper object like the cleaner, because classes loaded by the classloader will not have a reference to the wrapper in order to keep it around. So, it seems we cannot do deduplication and cleaning at the same time, with URLClassLoader. These changes are an attempt to use a proxy object to delegate to the actual classloader. However, I don't think this will work, because loaded classes will have a reference to the delegate object, not the proxy, in the same way that they don't have a reference to any other kind of wrapper object. For the same reason, we also can't delegate to a different classloader than the one we're monitoring using the parent parameter when constructing URLClassLoader. It may be posible to have the proxy implementation load proxied versions of each class it loads, to force those proxied versions to have a reference to the proxy wrapper, but that seems very convoluted and error prone. My next approach was to try to replace URLClassLoader with a functionally equivalent implementation, but which exposes URLClassLoader's internal cleanable resources, so that those internal cleanable resources can be closed instead of the URLClassLoader itself, when the URLClassLoader becomes phantom-reachable. However, that became very difficult because making a functionally equivalent URLClassLoader is very tricky without access to the jdk internals that URLClassLoader is using. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
