+1
> On May 12, 2014, at 11:03 PM, Gregg Wonderly <gr...@wonderly.org> wrote: > > All of these things are the reason why we just need to take Peter’s hard work > an go with it. There is really no reason to look back. The performance > issues and security problems that Peter has so patiently waded through have > needed attention for a long time. Only people trying to actually stress and > use Jini to it’s full capacity will have any chance at seeing these things be > big barriers, but that doesn’t discount their importance to even small > applications. > > Gregg Wonderly > >> On May 12, 2014, at 6:17 PM, Peter <j...@zeus.net.au> wrote: >> >> Hi Simon, >> >> http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/net/jini/loader/ClassLoading.java?view=markup >> >> During stress test profiling I found Class.forName to be heavily contended >> (the method with a ClassLoader parameter). >> >> Uncontended synchronization is very fast, so rather than employ parallel >> ClassLoading (which requires a lock for every class and isn't part of the >> jvm or lang specs), I decided to try thread confinement instead (for each >> ClassLoader). Before I found class loading to be a bottle neck, I had to >> fix a number of other throughput bottlenecks however: >> >> 1. Security Policy provider would cause contention while it performed dns >> calls. Dns calls are still made, but far fewer and concurrent security >> checks are now non blocking. The new policy provider takes advantage of >> immutability, how often do you change your policy files? >> 2. SecureClassLoader uses CodeSource in a loader map as keys, causing >> multiple dns lookup calls, fixed that with a RFC3986 compliant URI class to >> replace URL based keys in maps. >> 3. PreferredClassLoader also used URL's as keys in maps. >> 4. Exising thread pools didn't take advantage of concurrent utilities and >> TaskManager performed very poorly when it's task queue became large, since >> dependant tasks had to synchronize and iterate over the whole queue to find >> preceeding tasks. >> >> All fixed now, just need to reduce network traffic as Sockets are now the >> bottleneck. >> >> After I finish with latent bugs, I'll investigate using a provider to plug >> in various serialization frameworks that are available now. >> >> That and codebase provisioning should make River really sing. >> >> The stress tests were devised by the original Jini team, they're probably >> the closest thing I've got to deployment scenario's. >> >> Regards, >> >> Peter. >> ----- Original message ----- >>> Peter, >>> >>> With apologies that this it totally off-topic, but you made a comment >>> here that I'd really like to understand better: >>> >>> * ClassLoading is thread confined for each classloader to avoid >>>> contention. >>> >>> >>> Without impinging on your time unduly, are you able to point me at >>> something that would allow me to discover what this is about? It sounds >>> interesting, but I have no idea how this would work. >>> >>> And, I quite understand if you remain silent :) >>> >>> Cheers, >>> Simon >
