[
https://issues.apache.org/jira/browse/HBASE-14268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733278#comment-14733278
]
Hiroshi Ikeda commented on HBASE-14268:
---------------------------------------
I have googled and created some learning test applications, and I'm sure now as
follows:
Objects refereed by weak references and soft references are handled in the same
way as other objects by the generational GC. That means, if these objects are
not garbage-collected in several scavenge (non-full) GCs, they are moved from
the young generation to the old generation and required full-GC.
In general, weak referents are always garbage-collected (unless someone uses
them at the time and they are temporarily promoted to strong ones), so that
scavenge CG can collect them while they are still in the young generation. In
the other hand, soft referents tend to be alive while several scavenge GCs and
moved to the old generation, and full-GC is required to collect them.
The VM option {{-XX:SoftRefLRUPolicyMSPerMB=...}} can be used for Oracle VM
(http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_softrefs).
This option represents soft referents' lifetime (msec) per free memory (MB)
from their last access time. (For Client VM the free memory is the one before
growing the heap, but PCs in recent years are applied with Server VM.) The
default value is 1000msec/MB (= 1sec/MB) and if there is more 1GB free memory
you must wait more about 17min to garbage-collect. Obviously, such objects are
in the old generation and full-GC is required.
By setting the VM option to 0, there is little between soft references and weak
references, and it is possible that scavenge CG collects soft referents (though
it seems true that soft references is required for at least two GC because the
clock time to calculate their lifetime is updated by the previous GC
(http://jeremymanson.blogspot.jp/2009/07/how-hotspot-decides-to-clear_07.html)).
Instead of adding a log to the previously added patch to confirm the above
matter, I'll add a more clear learning test application and its outputs.
> Improve KeyLocker
> -----------------
>
> Key: HBASE-14268
> URL: https://issues.apache.org/jira/browse/HBASE-14268
> Project: HBase
> Issue Type: Improvement
> Components: util
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Priority: Minor
> Fix For: 2.0.0, 1.3.0
>
> Attachments: 14268-V5.patch, HBASE-14268-V2.patch,
> HBASE-14268-V3.patch, HBASE-14268-V4.patch, HBASE-14268-V5.patch,
> HBASE-14268-V5.patch, HBASE-14268-V6.patch, HBASE-14268-V7.patch,
> HBASE-14268-V7.patch, HBASE-14268.patch, KeyLockerIncrKeysPerformance.java,
> KeyLockerPerformance.java
>
>
> 1. In the implementation of {{KeyLocker}} it uses atomic variables inside a
> synchronized block, which doesn't make sense. Moreover, logic inside the
> synchronized block is not trivial so that it makes less performance in heavy
> multi-threaded environment.
> 2. {{KeyLocker}} gives an instance of {{RentrantLock}} which is already
> locked, but it doesn't follow the contract of {{ReentrantLock}} because you
> are not allowed to freely invoke lock/unlock methods under that contract.
> That introduces a potential risk; Whenever you see a variable of the type
> {{RentrantLock}}, you should pay attention to what the included instance is
> coming from.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
