[
https://issues.apache.org/jira/browse/HBASE-17747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15923548#comment-15923548
]
Yu Li commented on HBASE-17747:
-------------------------------
Thanks [~stack] and [~Apache9] for your concerns, such concerns make our
project better (smile).
Allow me to quote some words from
[javadoc|https://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html]:
{noformat}
Soft reference objects, which are cleared at the discretion of the garbage
collector in response to memory demand.
Soft references are most often used to implement memory-sensitive caches.
...
Direct instances of this class may be used to implement simple caches; this
class or derived subclasses may also be used
in larger data structures to implement more sophisticated caches. As long as
the referent of a soft reference is strongly reachable,
that is, is actually in use, the soft reference will not be cleared. Thus a
sophisticated cache can, for example, prevent its most
recently used entries from being discarded by keeping strong referents to those
entries, leaving the remaining entries to be
discarded at the discretion of the garbage collector.
{noformat}
> Support both weak and soft object pool
> --------------------------------------
>
> Key: HBASE-17747
> URL: https://issues.apache.org/jira/browse/HBASE-17747
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Yu Li
> Assignee: Yu Li
> Fix For: 2.0
>
> Attachments: HBASE-17747.patch, HBASE-17747.v2.patch,
> HBASE-17747.v3.patch
>
>
> During YCSB testing on embedded mode after HBASE-17744, we found that under
> high read load GC is quite severe even with offheap L2 cache. After some
> investigation, we found it's caused by using weak reference in
> {{IdReadWriteLock}}. In embedded mode the read is so quick that the lock
> might already get promoted to the old generation when the weak reference is
> cleared, which causes dirty card table (old reference get removed and new
> lock object set into {{referenceCache}}, see {{WeakObjectPool#get}}) thus
> slowing YGC. In distributed mode there'll also be more lock object created
> with weak reference than soft reference that slowing down the processing.
> So we proposed to use soft reference for this {{IdReadWriteLock}} used in
> cache, which won't get cleared until JVM memory is not enough, and could
> resolve the issue mentioned above. What's more, we propose to extend the
> {{WeakObjectPool}} to be more generate to support both weak and soft
> reference.
> Note that the GC issue only emerges under embedded mode with DirectOperator,
> in which case all costs on the wire is removed thus produces extremely high
> concurrency.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
