[
https://issues.apache.org/jira/browse/HBASE-14268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733436#comment-14733436
]
Hiroshi Ikeda commented on HBASE-14268:
---------------------------------------
The output of another test condition.
Change the code to force the referent to move to the old generation by
{{System.gc}}:
{code}
Object referent = new Object();
Reference<Object> ref = new WeakReference<Object>(referent);
System.gc();
referent = null;
{code}
and print again the referent after {{System.gc}}:
{code}
System.out.println(ref.get());
System.gc();
System.out.println(ref.get());
{code}
and run with -verbose:gc -Xmx2m -XX:+PrintGCDetails, creating 100MB objects.
The result is as follows:
{code}
[GC [PSYoungGen: 732K->485K(2560K)] 732K->541K(3584K), 0.0011560 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
[Full GC [PSYoungGen: 485K->0K(2560K)] [ParOldGen: 56K->437K(1024K)]
541K->437K(3584K) [PSPermGen: 2561K->2560K(21504K)], 0.0097690 secs] [Times:
user=0.01 sys=0.00, real=0.02 secs]
----start----
[GC [PSYoungGen: 82K->96K(2560K)] 519K->533K(3584K), 0.0006806 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
[Full GC [PSYoungGen: 96K->0K(2560K)] [ParOldGen: 437K->437K(1024K)]
533K->437K(3584K) [PSPermGen: 2560K->2560K(21504K)], 0.0064223 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
[GC [PSYoungGen: 2048K->0K(2560K)] 2485K->437K(3584K), 0.0004021 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
[GC [PSYoungGen: 2048K->0K(2560K)] 2485K->437K(3584K), 0.0004474 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
[GC [PSYoungGen: 2048K->0K(2560K)] 2485K->437K(3584K), 0.0004198 secs] [Times:
user=0.06 sys=0.00, real=0.02 secs]
(...skip...)
[GC [PSYoungGen: 2047K->0K(2560K)] 2500K->453K(3584K), 0.0089507 secs] [Times:
user=0.01 sys=0.00, real=0.02 secs]
[GC [PSYoungGen: 2048K->0K(2560K)] 2501K->453K(3584K), 0.0154225 secs] [Times:
user=0.00 sys=0.00, real=0.02 secs]
[GC [PSYoungGen: 2048K->0K(2560K)] 2501K->453K(3584K), 0.0013939 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
java.lang.Object@243f06e9
[GC [PSYoungGen: 899K->32K(2560K)] 1352K->485K(3584K), 0.0004124 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
[Full GC [PSYoungGen: 32K->0K(2560K)] [ParOldGen: 453K->437K(1024K)]
485K->437K(3584K) [PSPermGen: 2561K->2561K(21504K)], 0.0072723 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]
null
---- end ----
Heap
PSYoungGen total 2560K, used 41K [0x00000000ffd00000, 0x0000000100000000,
0x0000000100000000)
eden space 2048K, 2% used
[0x00000000ffd00000,0x00000000ffd0a4f8,0x00000000fff00000)
from space 512K, 0% used
[0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to space 512K, 0% used
[0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
ParOldGen total 1024K, used 437K [0x00000000ff800000,
0x00000000ff900000, 0x00000000ffd00000)
object space 1024K, 42% used
[0x00000000ff800000,0x00000000ff86d688,0x00000000ff900000)
PSPermGen total 21504K, used 2568K [0x00000000fa600000,
0x00000000fbb00000, 0x00000000ff800000)
object space 21504K, 11% used
[0x00000000fa600000,0x00000000fa882098,0x00000000fbb00000)
{code}
> java.lang.Object@243f06e9
How many scavenge CGs are invoked, the referent in the old generation is never
garbage-collected.
> [Full GC ...
> null
Only full-GC can collect it.
> 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, ReferenceTestApp.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)
