The SGA is comprised of fixed areas like the Log Buffers and the Buffer Cache(s) as well as memory pools (Shared Pool, Large Pool, Java Pool, and in 10g, the Streams Pool).  Memory allocated to the various pools are divided in heaps that can be composed of one or many sub heap memory structures. 

This is similar to many segments inside a tablespace. The tablespace will be the heap and the segments are the subheaps. The extents within the segment are like the various subheaps that can exist inside "parent" subheaps.   The goal in the shared memory areas is the same as a tablespace--avoid fragmentation.  To do this we allocate the chunk of memory that best fits the request for memory, coalescing adjacent free space as needed and detecting memory that can be flushed and reused.

Inside these pools, we use free list buckets.   They are structures of free lists and each list correspond to a specific size. Oracle does a binary search on the free list sizes to find the appropriate free list.  The first bucket that is greater or equal to the requested size will be returned.  At startup of the database, there are various sized chunks of memory created in each pool.  We will continue to walk the free list until we find a bucket which points to a large enough extent of memory.  The Shared Pool will utilize a Least Recently Used (LRU) algorithm to "age out" memory structures that have not been reused over time.

To get a better idea, see this information from a heapdump trace showing the free list bucket summary:

Free List Bucket Summary :
Bucket 0 [size=32 ] Count= 0 Av.Size= 0.00 Max= 0
Bucket 1 [size=40 ] Count= 443 Av.Size= 40.00 Max= 40
Bucket 2 [size=48 ] Count= 1850 Av.Size= 48.00 Max= 48

This shows that bucket 1 has 443 chunks of memory where the maximum size is 40 bytes and the average is 40 bytes. Bucket 2 is a free list of memory chunks with sizes between 40 and 48 bytes. When a chunk of space is freed/deallocated, it is added to the bucket whose size is less than or equal to the chunk’s size.  If you find smaller chunks of memory available in the Shared Pool vs. a mixture of large chunks and small chunks, this can indicate the application is causing fragmentation and there is a increasing chance that a future large memory requests will fail with an ORA-04031 error.  See How can we determine if there are Application issues causing the problem? for more on tracing inefficient application code.

The Shared Pool and Large Pool divide their shared memory areas into subpools (starting with 9i).  Each subpool will have Free List Buckets containing pointers to memory chunks within the subpool.  The other pools are treated as one large memory area with a single Free List as described above.

When a memory chunk is allocated inside the memory pool, it will be associated with a memory type.  The chunk will be allocated as PERMANENT, FREEABLE, or RECREATABLE.   These memory chunks are then associated with a memory structure or element inside the pool.  For example, "KGLS heap".  These memory structures/elements are not always tracked/commented in the data dictionary (specifically those in the PERMANENT type).

Chunk types:

Normal (freeable) chunks - These chunks are allocated in such a way that the user can explicitly free 
the chunk once they have finished with the memory.

Free chunks - These chunks are free and available for reuse should a request come into the pool for 
this chunk size or smaller.

Recreatable chunks - This is a special form. of "freeable" memory.  These chunks are placed on an 
LRU list when they are unpinned.   If memory is needed, we go to the LRU list and free "recreatable"
memory that hasn't been used for a while.

Permanent chunks - These chunks can be allocated in different ways.   Some chunks are allocated 
and will remain in use for the "life" of the instance.   Some "permanent" chunks are allocated but can 
be used over and over again internally as they are available.