[Update 2009-11]
http://www.itpub.net/thread-1240926-1-1.html message #4:
Extent is the same as granule. You can change the granule size and check extent size. They always match. E.g.

--My current extent and granule size are both 4194304. Let me double it.
alter system set "_ksmg_granule_size" = 8388608 scope = spfile;
startup force
oradebug dump heapdump 2

$ grep xsz ora11r2t1_ora_7822.trc
parent=(nil) owner=(nil) nex=(nil) xsz=0x0 heap=(nil)
parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil)
parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil)
parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil)
parent=(nil) owner=(nil) nex=(nil) xsz=0x800000 heap=(nil)

0x800000 is 8388608.




I just read Tom Kyte's article.
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:4974546899844
he says the chunk size is 4k. On my Windows XP Oracle 9.2.0.1, I did a heap dump (oradebug dump 
heapdump 2) for a fairly new session. The trace file shows many 4248 byte chunks. 

(The concept of extent still exists. Each extent in the trace file is 4M size. I believe that's 
what the DSGA granule size is, which is 4M if SGA < 128M. That's the dynamic SGA (DSGA for short) 
allocation size.)

The trace also shows many smaller (e.g. 32 or even 16 byte) and larger (like 3990200 byte) chunks. 
I guess those 4k chunks are still not atomic. I.e. if a SQL needs 3k, I believe 1k will be left 
free. 

One test may be keep dumping heaps while you load all kinds of SQLs and PL/SQLs. The test may also 
show that right before ORA-4031 whether two free chunks are coalesced (the addresses are in the 
second column). I don't know. 

On closer look, I realized most if not all those 4248 byte chunks have a ds (descriptor) but they 
don't have a latch. The lines with latch= are different sizes like 32, 312, 756, etc. I checked 
one latch. It happens to be child #1 library cache latch (v$latch_children.addr matches it).