Looking at the list of classloading sequence and how prefetch is taking effect, one thing I noticed is that when JVM loads Foo, it immediately resolves all the interfaces and super classes that Foo extends/implements. This makes sense, but our prefetching logic doesn't take this into account.
So when you have a deeply nested type hierarchy, this results in multiple roundtrips. A related inefficiency applies in the following situation: - French side requests Foo - British side sends Foo and prefetches Bar - ... - French side tries to load Bar, finds it prefetched - French side requests the base interfaces/super classes for Bar, resulting in multiple roundtrips. Finding super classes and interfaces require a deeper parsing of a class file, though. 2013/5/14 Jesse Glick <[email protected]> > On 05/13/2013 08:11 PM, Dean Yu wrote: > >> the hypothesis is that you save on the latency of >> round trip calls for loading a single class at a time by sending many >> classes up front. The only way this would be true is if the amount of >> latency you add by increasing the size of the original payload is less >> than the sum of the latency for each round trip call that is saved. >> > > Right, but I hope this is satisfied by most of the payloads being small > enough to fit into one transport packet even considering prefetch. > > The proposed patch is a little tricky. My original work on the branch, > which seemed to provide some benefit, only dealt with class prefetch: > before the master sends a class file to the slave, it scans the bytecode > for class constants referring to to related classes (dependencies, inner > classes, etc.), determines which class loader would be used for those if > the code ever asked for them to be loaded, and bundles all this up in the > response so that the slave can quickly load a series of classes without > making a new round trip. > > We also wanted to deliver entire JAR files, both to try to push as much > actual data in a single burst as possible, and to allow the slave to cache > JAR files after an agent restart. The tricky part is that the slave does > not know which JAR file it is supposed to consult for a given class name, > since the remoting layer models an arbitrary class loader hierarchy (or > graph!) rather than a “flat classpath”. So the master still needs to inform > the slave of the code source for each proposed class load. It can however > avoid a round trip per class loader by using the original prefetch > heuristic to predict what classes might soon be loaded as well. > > The result would be that when first setting up a slave (or after updating > Jenkins and/or plugins) you would get some big packets full of JAR content > being pushed down the pipe at full speed, which does not need to wait for > the slave to respond and so can be relatively efficient if the transport > itself is (and Kohsuke did some fixes here in 1.509). Then when taking a > slave online, or starting to use some complex plugins for the first time in > a given slave connection, the class loading will require some round-trip > communication to inform the slave of where to load everything from (even > though it already has the bytecode on disk); but most of these little > packets will include information about several classes rather than just > one, so we reduce the overall latency. > > Another option initially considered, but not implemented in the branch, > was to avoid all of the round-trip activity by having the master send a > serializable proxy which would effect the same class loading logic as > exists on the master. For example, a model for the loader of a Jenkins > plugin would refer to the models of the Jenkins core and any plugin > dependencies, with some additional fields for options such as plugin-first > class loading. This could be very efficient but for it to work requires > that every ClassLoader in the master which loads anything serialized to the > slave also supply a proxy, meaning more code in Jenkins core to > troubleshoot and maintain. > > The above is my interpretation of what the branch currently does, so > Kohsuke please correct me if I have got it wrong! > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > jenkinsci-dev+unsubscribe@**googlegroups.com<jenkinsci-dev%[email protected]> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
