Row cache object latch

I have a microbenchmark where the bottleneck was latch wait on the
"row cache object" latch. (Oracle 8.1.7.3, HP-UX 11i)

Can anybody expand on the rather garbled paragraph on tuning in Metalink DocID 166474.1 ?

"Tuning Row cache is so limited, some references point to it as
non-tunable,so if the pct_succ_gets above is not getting closer to "1" or if you detected a high Row Cache Objects Latch contention in performance tuning reports then you need to add more shared pool by either increasing SHARED_POOL_SIZE or avoid Sharde [sic] Pool Fragmentation."

I'm not sure how expanding the shared pool will alleviate contention for a latch that's used "when a process attempts to access or update an entry in the Dictionary Cache."

Doc ID 22908.1 says "This latch comes into play when user processes are attempting to access the cached data dictionary values."

From reading Steve Adams' book (p49), each row in the dictionary cache has its own enqueue. If this is the case, why is a single latch needed?

Can anybody explain exactly what this latch protects, and when it is acquired?

Also, is the Metalink document correct that a larger shared pool would reduce contention. Surely if there are more objects in the dictionary cache, contention on a latch would be greater? Or is this a rare case where Oracle will hold a latch while doing an I/O (in the event of a dictionary cache miss)?

-- 
Andrew Mobbs - http://www.chiark.greenend.org.uk/~andrewm/