|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
ClassLoader is always exported with autoUnexport=false (MultiClassLoaderSerializer.Output.annotateClass), so its unexporting is subject to the garbage collection on the other side. When RemoteClassLoader gets GC-ed, its proxy is RemoteIClassLoader and that in turn points to a generated proxy that wraps RemoteInvocationHandler. The finalizer of this object sends an unexport command back to the other side.
Therefore indeed classloaders are getting exported and unexported pretty rapidly, which seems rather wasteful. It forces all the class loading to be redone, for one thing. There's a method to prevent exported objects from getting unexported (Channel.pin and Channel.pinClassLoader), but this is only used once in the Jenkins core to pin down the Jenkins core classloader (SlaveComputer.setChannel) and not plugins. Given that Jenkins doesn't unload plugins, I think we should just pin down all the plugin classloaders as well.
So far, I think my hypothesis that I mentioned in the previous comment is indeed possible. I'm going to write a test case to reproduce this.