[
https://issues.apache.org/jira/browse/HBASE-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020766#comment-16020766
]
Yu Li commented on HBASE-18085:
-------------------------------
Referring to this [post|http://java-performance.info/jmh/], we need a non-local
state variable to avoid JIT optimization, so I changed the testLock method as
below:
{code}
private boolean blackHoleVal;
@Benchmark
public void testLock(Blackhole bh) {
boolean attained = purgeLock.tryLock();
blackHoleVal = attained;
try {
// do purge
bh.consume(blackHoleVal);
return;
} finally {
if (attained) {
purgeLock.unlock();
}
}
}
{code}
And get a more reasonable result (the previous result was not that reasonable
considering the underlying implementation of ReentrantLock#tryLock):
{noformat}
Benchmark Mode Cnt Score Error
Units
AtomicLockBenchmark.testAtomicBoolean thrpt 100 47314035.981 ± 1418461.917
ops/s
AtomicLockBenchmark.testLock thrpt 100 47139427.031 ± 677362.892
ops/s
AtomicLockBenchmark.testVolatileBoolean thrpt 100 45676053.492 ± 786938.305
ops/s
{noformat}
> Prevent parallel purge in ObjectPool
> ------------------------------------
>
> Key: HBASE-18085
> URL: https://issues.apache.org/jira/browse/HBASE-18085
> Project: HBase
> Issue Type: Bug
> Reporter: Yu Li
> Assignee: Yu Li
> Attachments: e89l05465.st3.jstack, HBASE-18085.patch
>
>
> Parallel purge in ObjectPool is meaningless and will cause contention issue
> since {{ReferenceQueue#poll}} has synchronization (source code shown below)
> {code}
> public Reference<? extends T> poll() {
> if (head == null)
> return null;
> synchronized (lock) {
> return reallyPoll();
> }
> }
> {code}
> We observed threads blocking on the purge method while using offheap bucket
> cache, and we could easily reproduce this by testing the 100% cache hit case
> in bucket cache with enough reading threads.
> We propose to add a purgeLock and use tryLock to avoid parallel purge.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
