I have the same setup (ClassCache in a shared prototype scope). During a warmup phase (which happens quite often, as I have dynamic class reloading too backed by a soft-reference storage, so code versions get unloaded and reloaded as memory requires, and there are several of them in memory at once, each of them from a separate class loader, with a separate prototype scope and ClassCache), there'll be 50 threads pulling in the class workset concurrently. This happens several times an hour 24/7, on dozens of machines, for 6 years now, heavy production load. I never had that problem.
I'm not saying it's not real, though - race conditions are notorious for being obscure. I could've been lucky. Under *correctly synchronized* multithreaded access, java.util.HashMap.get() can not possibly hang, except if the key's equals() or hashCode() hangs. However, the map you're referring to has java.lang.Class objects as keys, and its equals() and hashCode() don't hang either. On the other hand, unsafe multithreaded mutations could corrupt it so that it never exits the loop in HashMap.get() - i.e. if a race condition victim thread observes an element of the hash table in a moment when e == e.next. I think I did encounter this once in the wild. You might be hitting the same problem. So, do we have unsafe multithreaded mutation here? Well, the only lock is in the NativeJavaPackage.getPkgProperty(), and there can be more than one of those. So I believe that indeed more than one thread can access the ClassCache concurrently - they'll be synchronizing on different NativeJavaPackage objects and thus not mutually exclude one another. Yeah, on the first sight, this indeed looks like we have a potential for an unsynchronized concurrent mutation of the ClassCache backing HashMap. Anyone else care to double-check my analysis? Attila. -- home: http://www.szegedi.org twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com On 2010.01.25., at 21:03, Tom Palkot wrote: > We are trying to resolve an issue where the Rhino engine occasionally > gets stuck early in the run. > > > > We use a shared sealed global scope, and create scripts that execute in > multiple threads, inheriting the core objects from the single shared > global scope. > > > > Under load, it looks like the HashMap instances in > org.mozilla.javascript.ClassCache get corrupted. We get a code thread > hung in this code below, and all the other threads waiting for this guy > to give up a synchronization lock. > > > > We are trying the use of ConcurrentHashMap instead of HashMap inside the > ClassCache. > > Has anyone seen this before, or have any suggestions? Our environment: > > JDK 1.6 > > Rhino 1.7 R1 > > > > "[ACTIVE] ExecuteThread: '395' for queue: 'weblogic.kernel.Default > (self-tuning)'" daemon prio=3 tid=0x02f0b000 nid=0x1bc runnable > [0x8f87d000] > > java.lang.Thread.State: RUNNABLE > > at java.util.HashMap.get(HashMap.java:303) > > at > org.mozilla.javascript.JavaMembers.lookupClass(JavaMembers.java:836) > > at > org.mozilla.javascript.NativeJavaClass.initMembers(NativeJavaClass.java: > 83) > > at org.mozilla.javascript.NativeJavaClass. > > (NativeJavaClass.java:78) > > at > org.mozilla.javascript.NativeJavaPackage.getPkgProperty(NativeJavaPackag > e.java:159) > > - locked > > <0xc05ce0c0> > > (a org.mozilla.javascript.NativeJavaPackage) > > at > org.mozilla.javascript.NativeJavaPackage.get(NativeJavaPackage.java:105) > > at > org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.jav > a:1575) > > at > org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:13 > 97) > > at > org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:13 > 83) _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
