Strange memory maps wasting ram

I was looking around in system monitor and was really curious as to why 
things were using so much memory.  For instance, clock-applet is using 
111 megs of ram.  I took a look at the memory maps and what I found 
confounds me.  I noticed it lists a TON of 1 MB maps.  For instance, it 
shows that /usr/lib/libX11.so.6.2.0 has a 1 MB map starting at VM Offset 
D5000.  When I do an objdump -x on that library, I see this:

Sections:
Idx Name          Size      VMA               LMA               File 
off  Algn
  0 .hash         00002300  0000000000000158  0000000000000158  
00000158  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00007128  0000000000002458  0000000000002458  
00002458  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       00004c0c  0000000000009580  0000000000009580  
00009580  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .gnu.version  0000096e  000000000000e18c  000000000000e18c  
0000e18c  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.version_r 00000060  000000000000eb00  000000000000eb00  
0000eb00  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rela.dyn     00004c08  000000000000eb60  000000000000eb60  
0000eb60  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .rela.plt     00003000  0000000000013768  0000000000013768  
00013768  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .init         00000018  0000000000016768  0000000000016768  
00016768  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .plt          00002010  0000000000016780  0000000000016780  
00016780  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  9 .text         0006a6a8  0000000000018790  0000000000018790  
00018790  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 10 .fini         0000000e  0000000000082e38  0000000000082e38  
00082e38  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .rodata       00043230  0000000000082e60  0000000000082e60  
00082e60  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 12 .eh_frame_hdr 00002e9c  00000000000c6090  00000000000c6090  
000c6090  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 13 .eh_frame     0000bdf4  00000000000c8f30  00000000000c8f30  
000c8f30  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 14 .ctors        00000010  00000000001d5000  00000000001d5000  
000d5000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 15 .dtors        00000010  00000000001d5010  00000000001d5010  
000d5010  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 16 .jcr          00000008  00000000001d5020  00000000001d5020  
000d5020  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 17 .data.rel.ro  00000728  00000000001d5040  00000000001d5040  
000d5040  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 18 .dynamic      000001c0  00000000001d5768  00000000001d5768  
000d5768  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 19 .got          00000200  00000000001d5928  00000000001d5928  
000d5928  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 20 .got.plt      00001018  00000000001d5b28  00000000001d5b28  
000d5b28  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 21 .data         00002120  00000000001d6b40  00000000001d6b40  
000d6b40  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 22 .bss          000006b0  00000000001d8c60  00000000001d8c60  
000d8c60  2**5
                  ALLOC
 23 .gnu_debuglink 00000014  0000000000000000  0000000000000000  
000d8c60  2**0
                  CONTENTS, READONLY


At offset D5000 there is a 16 byte section.  It is followed by several 
other smallish sections with the same permissions, so I assume that the 
loader would combine them into a single mapping, but the total size of 
all of the remaining sections is nowhere NEAR 1 MB, so why is the 
mapping that large?

It looks like just about every GUI process has around 40 such mappings 
that are shown in system monitor as 1.0 MB, but the library that is 
being mapped should not need nearly that much space.  Heck, trashapplet 
is using 96 MB. 

Now either something is really wrong here, or something is really wrong 
here.  I'm running breezy amd64-generic on an Athlon 64 3200+ with a gig 
of ram.  Does anyone else have this problem or have any idea what in the 
world could be causing it?