[ 
https://issues.apache.org/jira/browse/CASSANDRA-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984778#action_12984778
 ] 

Todd Lipcon commented on CASSANDRA-1968:
----------------------------------------

The old gen allocation works like this:
- If it's smaller than 16 words, bump-the-pointer allocate into the "sLAB" - 
small linear allocation buffer. This buffer is allocated in chunks and then 
doled out for small objects
- If it's between 16 and 256 words, use "indexed free lists" - basically an 
array of freelists, one per size.
- If there are no objects free in a freelist, keep searching through bigger 
free lists until you find one. There is a "hint" pointer in each free list to 
allow you to skip directly to the next larger one that last succeeded in 
allocation, so it should be expected O(1)
- If the "indexed free lists" have no space that fit (or you're bigger than 256 
words) then move to the BinaryTreeDictionary
- BTD is a balanced tree of chunks keyed by size. It uses a best fit strategy
- The chosen chunk is split in two, data structures updated, and the remaining 
half returned into the free space tracking (ie into indexed free lists if it's 
small, BTD if big)

So I would guess it's O(1) for small allocations, O(lg(number of fragments)) 
for large allocations.

There's also a concept of a PLAB (promotion local allocation buffer) which I 
don't quite understand yet - I think each collector thread in the young gen 
allocates a bigger chunk out of the old gen rather than allocating space for 
each object. This makes sense because the old gen allocations happen under one 
big lock.

> Increase JVM young generation size
> ----------------------------------
>
>                 Key: CASSANDRA-1968
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1968
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 0.7.0
>            Reporter: Brandon Williams
>            Assignee: Brandon Williams
>             Fix For: 0.7.1
>
>         Attachments: 1968.txt, 1968_v2.txt
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Increasing the young generation size has a profound effect on performance and 
> cpu utilization.  We should set it explicitly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to