[
https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091196#comment-13091196
]
Yang Yang edited comment on CASSANDRA-2252 at 8/25/11 6:32 PM:
---------------------------------------------------------------
SlabAllocator:
private void tryRetireRegion(Region region)
{
if (currentRegion.compareAndSet(region, null))
{
filledRegions.add(region);
}
}
could you please explain why we need to add them to "filledRegions"? when all
the buffers that share the same region die/become unreachable, shouldn't we
just let the region go and free memory? , then we should not tie this region
in memory through the references starting from filledRegions . no ??
just to confirm my thoughts, I looked at the HBase implementation:
./src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreLAB.java
/**
* Try to retire the current chunk if it is still
* <code>c</code>. Postcondition is that curChunk.get()
* != c
*/
private void tryRetireChunk(Chunk c) {
@SuppressWarnings("unused")
boolean weRetiredIt = curChunk.compareAndSet(c, null);
// If the CAS succeeds, that means that we won the race
// to retire the chunk. We could use this opportunity to
// update metrics on external fragmentation.
//
// If the CAS fails, that means that someone else already
// retired the chunk for us.
}
it does not tie it to a region list .
the current result of tying regions together through the filledRegions is that
all regions (even if those dead ones) always occupy memory. --- well if the
purpose is to count the size() held in allocator, should we just keep a int var
of total size , or use weak references?
was (Author: yangyangyyy):
SlabAllocator:
private void tryRetireRegion(Region region)
{
if (currentRegion.compareAndSet(region, null))
{
filledRegions.add(region);
}
}
could you please explain why we need to add them to "filledRegions"? when all
the buffers that share the same region die/become unreachable, shouldn't we
just let the region go and free memory? , then we should not tie this region
in memory through the references starting from filledRegions . no ??
just to confirm my thoughts, I looked at the HBase implementation:
./src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreLAB.java
/**
* Try to retire the current chunk if it is still
* <code>c</code>. Postcondition is that curChunk.get()
* != c
*/
private void tryRetireChunk(Chunk c) {
@SuppressWarnings("unused")
boolean weRetiredIt = curChunk.compareAndSet(c, null);
// If the CAS succeeds, that means that we won the race
// to retire the chunk. We could use this opportunity to
// update metrics on external fragmentation.
//
// If the CAS fails, that means that someone else already
// retired the chunk for us.
}
it does not tie it to a region list .
the current result of tying regions together through the filledRegions is that
all regions (even if those dead ones) always occupy memory. --- well if the
purpose is to count the size() held in allocator, should we use weak references?
> arena allocation for memtables
> ------------------------------
>
> Key: CASSANDRA-2252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2252
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.0
>
> Attachments: 0001-add-MemtableAllocator.txt,
> 0002-add-off-heap-MemtableAllocator-support.txt, 2252-v3.txt, 2252-v4.txt,
> merged-2252.tgz
>
>
> The memtable design practically actively fights Java's GC design. Todd
> Lipcon gave a good explanation over on HBASE-3455.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
