Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Cache misses in namespace URI verification

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Cache misses in namespace URI verification
  • Date: Fri, 10 Dec 2004 15:37:55 -0800

On Dec 10, 2004, at 12:38 PM, Elliotte Harold wrote:

Wolfgang Hoschek wrote:


Because everything in nu.xom.Verifier is static. All threads are contending for the same shared lock in the URICache, irrespective of whether they work in the same or different documents. If you have 100 threads, each rapidly executing URICache.contains() millions of times you can get a lot of lock contention and serious performance degradation.


That's a separate issue. My question is if you're parsing ten different documents at a time, each of which uses the same three or four namespaces, if the namespace URIs aren't interned across parses, won't they tend to keep knocking each others namespaces out of the cache? Even though they're really the same URIs?

Yes, they can knock each other out of the cache. If thrashing becomes an issue it might be worthwhile to consider using a ThreadLocal, as in

private static final ThreadLocal localCache = new ThreadLocal() {
protected Object initialValue() { // lazy init
return new URICache();
}
};

static void checkAbsoluteURIReference(String uri) {
URICache cache = (URICache) localCache.get();
if (cache.contains(uri)) {
... and so on
}

Quoting Doug Lea from http://altair.cs.oswego.edu/pipermail/concurrency-interest/2004- November/001116.html

Accessing a ThreadLocal is also reasonably fast, but typically
slightly slower than an allocation. I'd guess somewhere around 20
instructions. (This varies across machines - x86 might be relatively a
bit slower than others like sparc because thread-local base pointer
isn't kept in a register because there aren't many registers.)

Above statement does not hold for prehistoric VMs.

Use of ThreadLocal is lock-free (using atomic CPU instructions) and so you can have arbitrarily long running code in URICache.contains()/put() without suffering lock contention. [If you go down that route the "synchronized" tags on both methods become unnecessary].

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page