ramkrishna.s.vasudevan commented on HBASE-18375:

Thanks for clearing my doubt.
In your earlier comment
b. When S is closed, C is returned to ChunkCreator, which in turn returns C to 
the pool, but in parrallel the GC is already freeing C's "unreachable" 
You said the ByteBuffer were freed. So it is like the Chunks are cleared though 
there was an active ref to one of its member.
Ya previously it was soft reference so the chance of that getting freed is 
lesser if we have enough memory.
Thanks for this useful info. 

> The pool chunks from ChunkCreator are deallocated while in pool because there 
> is no reference to them
> -----------------------------------------------------------------------------------------------------
>                 Key: HBASE-18375
>                 URL: https://issues.apache.org/jira/browse/HBASE-18375
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Anastasia Braginsky
>            Assignee: Anastasia Braginsky
>            Priority: Critical
>             Fix For: 2.0.0, 3.0.0, 2.0.0-alpha-2
>         Attachments: HBASE-18375-V01.patch, HBASE-18375-V02.patch, 
> HBASE-18375-V03.patch, HBASE-18375-V04.patch
> Because MSLAB list of chunks was changed to list of chunk IDs, the chunks 
> returned back to pool can be deallocated by JVM because there is no reference 
> to them. The solution is to protect pool chunks from GC by the strong map of 
> ChunkCreator introduced by HBASE-18010. Will prepare the patch today.

This message was sent by Atlassian JIRA

Reply via email to