[
https://issues.apache.org/jira/browse/HBASE-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629697#comment-13629697
]
Hiroshi Ikeda commented on HBASE-7437:
--------------------------------------
An instance of Calendar automatically update its internal time only just after
its creation.
That means, without explicitly updating the internal time, a static field of
Calendar always returns the same hour when the nesting class was loaded.
Moreover, since Calendar is not thread safe and the static field is intended to
called by multiple threads, some synchronization is required while updating the
internal time and getting the corresponding hour. (I think it is safe to get
the hour without synchronization if we never update the time, even though it is
useless.)
Contention between threads causes context switches, which are quite huge
overhead that we should give priority to remove, and the most simple way to
remove the worry is creating an instance for each call. But, as you mentioned,
the implementation logic of GregorianCalendar is complex and it is possible
that we cannot ignore both of overheads of creating an instance and updating
its time.
For this reason, I created the independent class CurrentHourProvider in order
to encapsulate its implementation details, and tried to reduce the above
overheads without blocking threads. Of course it is overkill if the current
hour is not so frequently required that it is acceptable to create an instance
of Calendar for each call.
> Improve CompactSelection
> ------------------------
>
> Key: HBASE-7437
> URL: https://issues.apache.org/jira/browse/HBASE-7437
> Project: HBase
> Issue Type: Improvement
> Components: Compaction
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Priority: Minor
> Attachments: HBASE-7437.patch, HBASE-7437-V2.patch,
> HBASE-7437-V3.patch, HBASE-7437-V4.patch
>
>
> 1. Using AtomicLong makes CompactSelection simple and improve its performance.
> 2. There are unused fields and methods.
> 3. The fields should be private.
> 4. Assertion in the method finishRequest seems wrong:
> {code}
> public void finishRequest() {
> if (isOffPeakCompaction) {
> long newValueToLog = -1;
> synchronized(compactionCountLock) {
> assert !isOffPeakCompaction : "Double-counting off-peak count for
> compaction";
> {code}
> The above assertion seems almost always false.
--
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
