It's right there in your output (and if this is a default executable [no use of chatr to go EXEC_MAGIC]), I'm sorry -- but I don't believe you when you claim it goes above 1Gb for a 32-bit app. It may go over 1 billion bytes, but that's not the same thing.
Anyway -- the difference in the machines in the difference in maxssiz:
< maxssiz 134217728 134217728 Immed
---
> maxssiz 8388608 Default Immed
The default layout for 32-bit applications is 2 private quadrants and 2 shared quadrants. One private quadrant is used for the Text (yes, there's a lot of virtual address space that's unused for small programs... but there's optimizations when you have the same binary run in many places and only Read+Executable. Performance is a good thing... and that's why EXEC_MAGIC isn't the default).
The other private quadrant holds all other private objects -- that's your heap [where the malloc is going] _and_ MAP_PRIVATE mmap objects _and_ most importantly, your stack. The stack grows from low addresses to high -- so in order for maxssiz to work, the stack *must* start maxssiz (rounded down to a page) before the end of the private quadrant. You can't span the quadrant.
So a higher maxssiz means you have less space for other private data... such as your malloc() space. On one system, you have 128Mb of virtual address space reserved for stack consumption. No malloc() over 896Mb [minus 4096 bytes, but close enough] will be possible... because you hit the stack.
On the other, the stack is only 8Mb, hence you have around 1016Mb available for other private objects.
Or in short, if you want more data -- lower maxssiz.
