XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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.