[
https://issues.apache.org/jira/browse/HBASE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833055#comment-13833055
]
Lars Hofhansl commented on HBASE-10015:
---------------------------------------
The javac warnings are these:
{code}
[INFO] Compiling 150 source files to
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-common/target/classes
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:[51,15]
sun.misc.Unsafe is Sun proprietary API and may be removed in a future release
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:[1110,19]
sun.misc.Unsafe is Sun proprietary API and may be removed in a future release
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:[1116,21]
sun.misc.Unsafe is Sun proprietary API and may be removed in a future release
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:[1121,28]
sun.misc.Unsafe is Sun proprietary API and may be removed in a future release
{code}
These are not new.
Same with the Javadoc warnings (no new ones from this patch).
Same for findbugs.
Going to commit.
> Replace intrinsic locking with explicit locks in StoreScanner
> -------------------------------------------------------------
>
> Key: HBASE-10015
> URL: https://issues.apache.org/jira/browse/HBASE-10015
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Labels: performance
> Attachments: 10015-0.94-lock.txt, 10015-0.94-new-sample.txt,
> 10015-0.94-v2.txt, 10015-0.94-v3.txt, 10015-0.94-v4.txt,
> 10015-0.94-withtest.txt, 10015-0.94.txt, 10015-trunk-lock.txt,
> 10015-trunk-v2.txt, 10015-trunk-v3.txt, 10015-trunk-v4.txt,
> 10015-trunk-v4.txt, 10015-trunk-v4.txt, 10015-trunk.txt, TestLoad.java
>
>
> Did some more profiling (this time with a sampling profiler) and
> StoreScanner.peek() showed up a lot in the samples. At first that was
> surprising, but peek is synchronized, so it seems a lot of the sync'ing cost
> is eaten there.
> It seems the only reason we have to synchronize all these methods is because
> a concurrent flush or compaction can change the scanner stack, other than
> that only a single thread should access a StoreScanner at any given time.
> So replaced updateReaders() with some code that just indicates to the scanner
> that the readers should be updated and then make it the using thread's
> responsibility to do the work.
> The perf improvement from this is staggering. I am seeing somewhere around 3x
> scan performance improvement across all scenarios.
> Now, the hard part is to reason about whether this is 100% correct. I ran
> TestAtomicOperation and TestAcidGuarantees a few times in a loop, all still
> pass.
> Will attach a sample patch.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
