Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Tue, 21 Nov 2006 00:17:42 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Releasing latches when waiting for locks. When and why?
In-reply-to: <x1o3zmaldcmj.fsf@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x7odr1673d.fsf@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <wjo8bqn6t7s6.fsf@sun.com> <455E4FDF.5030600@amberpoint.com>
 <wjo81wnytb0f.fsf@sun.com> <4561FE49.2000901@sbcglobal.net>
 <20061120194538.GG22233@trapper.coreless.net> <x1o3zmaldcmj.fsf@sun.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (usg-unix-v)

Dyre.Tjeldvoll@Sun.COM writes:

> Anders Morken <andersmo@stud.ntnu.no> writes:
>
>> We've taken some long hard looks at the lock manager, and we're
>> convinced that there's a lot of potential for improvement in Derby lock
>> management. Not that there's anything wrong with the approach taken in
>> the current implementation - correctness first, optimization later. =)
>>
>> One of the things that we've observed is that on a single-row update
>> transaction, a shared lock is obtained on a row in the B-tree container
>> just before an exclusive lock is obtained on a row in the data
>> container. Off the top of my head I can't remember if why figured out
>> exactly why. =)
>>
>>> Having said that it would be interesting if someone had time to 
>>> implement a higher performance latch implementation and plug it in
>>> and see how much it helps.  It would decrease the total time spent
>>> in lock manager.
>
> I think Knut Anders has been playing with that idea, so if you're not
> doing it yourself I'm sure he (we) would love to hear about any ideas
> you may have.

Well, my ideas are pretty vague at the moment. The ideas I have played
with so far (see also DERBY-1704) are:

  1) Split the hash table in LockSet into multiple hash tables to
     reduce the monitor contention. This would reduce monitor
     contention for both locking and latching, but wouldn't make any
     of them cheaper in the single-client case.

  2) Eliminating the hash table in SinglePool by having a direct
     pointer from a compatibility space to its locks. This would
     reduce monitor contention and CPU usage for locking, but not for
     latching.

To reduce the cost of latching, we would at least need to move the
latches out of the lock table (LockSet). One way could be to change
the interface and separate between lockable and latchable objects. As
it is now, both lockable and latchable objects implement the Lockable
interface, and the LockFactory interface says that two Lockables
represent the same lockable object if their equals() methods return
true. This is fine for row locking, but for latching it is unnecessary
overhead because the objects that are latched have no equals() method
and therefore must be the exact same object. If we instead had a
Latchable interface which were simpler than the Lockable, and which
required reference equality in order to represent the same latchable
object, I think we could get closer to the "just set a flag on the
page" idea.

>> We've actually considered doing that for fun, but as our goal right now
>> is to produce a big honkin' report, not fix anything, we haven't. Still,
>> it would probably give a quite significant benefit. 
>
> Reports are a fact of life :)
>
>> Using a Java profiler on a reasonably modern X86 system we've found that
>> while acquiring a Derby lock takes about 60-70 microseconds and a latch
>> costs 50-60 microseconds in the non-contended (single thread) cases,
>> acquiring and releasing a ReentrantLock available in Java 1.5 and up
>> costs about 1,5 microseconds. A latch could in theory be about as cheap
>> as a ReentrantLock, and on Java 1.5 and up it would make sense to base
>> Latches on ReentrantLocks.
>
> Interesting observation! But unfortunately not available for Derby for a long
> time :(

If the interface of the lock manager is changed to be more in line
with the new concurrency utilities, we could have different lock
managers for JDK < 1.5 and JDK >= 1.5, and let the 1.5 lock manager
(or at least the latching) just be a thin wrapper around
ReentrantLock. Don't know if that is feasible.

>> However, just separating the latch data structures from the lock data
>> structures could give significant scalability benefits, as right now the
>> latches and locks are all stored in the same hash tables, causing
>> significant monitor contention in multithreaded cases.
>
> Absolutely. In the multi-core world it is essential to keep the amount
> of shared data at an absolute minimum
>  
>> I dunno if our report would be of any interest to you guys, but it's not
>> finished yet, and I'm not sure if it appropriate to post it just yet.
>> Still, it's interesting stuff we're digging up, and it's interesting to
>> see how you guys investigate this. =)
>
> I'd love to read it, and I expect others in the Derby community would
> too. 

Indeed! It sounds like you have some very interesting numbers, and I'm
looking forward to reading your report!

-- 
Knut Anders