I'm not sure it gets any easier to understand or less cryptic by calling the amount of RAM end of RAM and printing it twice?
Actually, it's the end of RAM. On my 4 GB machine, tom_k is 0x00500000 which is 5*1024*1024. The hole starts at 3 GB in that configuration. However, printing it twice serves no purpose. I'll fix and resend.
I think it makes it easier to review patches like this (that only change debugging output) if you include before and after log snippets.
Thanks, Myles