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

Anoop Sam John commented on HBASE-20716:
----------------------------------------

Sorry for the delay...   Its coming good.. I like the way you abstracted out 
the things.. Now we will have Bytes and BBUtils class as front end and within 
which we deal via Unsafe or pure java costly way.  
The concern is some times the static classes within say BBUtils can get loaded 
which might cause the static fields to get initialized.  You can see in class 
UnsafeConverter , there is static state of type Unsafe which can cause a class 
loading try for Unsafe class. And in some env this is not available!  We have 
seen such cases been reported in mailing list/jira.
See how we have handled the Best comparator thing in Bytes class..  The loading 
is based on a FQCN and by Class.forName.  
Also for BBUtils, all the access where via UnsafeAvailChecker (dont know things 
changed in later but when these classes were introduced it was this way).  
Within UnsafeAvailChecker , there is no direct ref to Unsafe class at all.
We need a similar way now.
Am I making it clear to you?  

> Unsafe access cleanup
> ---------------------
>
>                 Key: HBASE-20716
>                 URL: https://issues.apache.org/jira/browse/HBASE-20716
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>            Assignee: Sahil Aggarwal
>            Priority: Critical
>              Labels: beginner
>         Attachments: HBASE-20716.master.001.patch, 
> HBASE-20716.master.002.patch, HBASE-20716.master.003.patch, 
> HBASE-20716.master.004.patch, Screen Shot 2018-06-26 at 11.37.49 AM.png
>
>
> We have two means of getting at unsafe; UnsafeAccess and then internal to the 
> Bytes class. They are effectively doing the same thing. We should have one 
> avenue to Unsafe only.
> Many of our paths to Unsafe via UnsafeAccess traverse flags to check if 
> access is available, if it is aligned and the order in which words are 
> written on the machine. Each check costs -- especially if done millions of 
> times a second -- and on occasion adds bloat in hot code paths. The unsafe 
> access inside Bytes checks on startup what the machine is capable off and 
> then does a static assign of the appropriate class-to-use from there on out. 
> UnsafeAccess does not do this running the checks everytime. Would be good to 
> have the Bytes behavior pervasive.
> The benefit of one access to Unsafe only is plain. The benefits we gain 
> removing checks will be harder to measure though should be plain when you 
> disassemble a hot-path; in a (very) rare case, the saved byte codes could be 
> the difference between inlining or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to