hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nkeywal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6755) HRegion.internalObtainRowLock uses unecessary AtomicInteger
Date Wed, 12 Sep 2012 10:22:08 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453887#comment-13453887
] 

nkeywal commented on HBASE-6755:
--------------------------------

You can save an increment (Wow!), and may be some synchronisation issues with this (not tested).
{noformat}
       // loop until we generate an unused lock id
       while (true) {
        Integer lockId = ++lockIdGenerator;
         HashedBytes existingRowKey = lockIds.putIfAbsent(lockId, rowKey);
         if (existingRowKey == null) {
           return lockId;
         } else {
           // lockId already in use, jump generator to a new spot
	   do {
		 lockIdGenerator = rand.nextInt();
           }while (lockIds.putIfAbsent(lockIdGenerator , rowKey) == null);
           return lockIdGenerator ;
         }
       }
     } finally {
{noformat}


But if this piece of code is important for the performances, it may need some rethinking imho,
with stuff around native structures (int vs. Integer, allocation per block, pre allocation
(may be in a different thread)...

Is it that important?

                
> HRegion.internalObtainRowLock uses unecessary AtomicInteger
> -----------------------------------------------------------
>
>                 Key: HBASE-6755
>                 URL: https://issues.apache.org/jira/browse/HBASE-6755
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.96.0, 0.94.3
>
>         Attachments: 6755-0.96.txt
>
>
> I was looking at HBase's implementation of locks and saw that is unnecessarily uses an
AtomicInteger to obtain a unique lockid.
> The observation is that we only need a unique one and don't care if we happen to skip
one.
> In a very unscientific test I saw the %system CPU reduced when the AtomicInteger is avoided.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message