I am testing the behavior of a 32 bit application running on Solaris 5.10 (SPARC), and realize it reaches 4GB of memory and then crashes.
It doesn't matter the amount of used memory as application is intended to perform many transactions; rather, what I want to achieve is to get the application capable to address more than 4GB without having to recompile and rebuild it in 64 bit mode.
It is possible to achieve that? if so, I am glad if you can indicate me how to do that.
A 32-bit system generally cannot physically address more than 4GB of RAM.
Various systems, however, have adopted extensions that permit a 32-bit system to physically access more than 4GB of RAM.
In generally, this is implemented via "page table hacks".
For example, the x86 architecture, for example, supports a feature called Physical Address Extension (PAE) that commonly extends physically-addressable memory to 64GB.
PAE is quite common. If your system supports it, you can have more than 4GB of RAM. Otherwise you are stuck at 4GB.
You might check to see if your SPARC architecture also supports PAE and post back the results of your research.
PAE was invented for 32bit kernels, in order to address more than 4GB.
It allowed many apps to consume more than 4GB, but I have my doubts that a single app could address more than 4GB.
PAE caused some severe misbehavior on Linux: for example, OOM killer was invoked if one 4GB segment was full; without knowing which process occupied most in that segment it often killed "wrong" processes before it killed a "correct" one. OpenSuSE kernels even invoked OOM killer if a single small process did continous I/O that filled a 4GB segment with only cache data - a nightmare!
Fortunately PAE is from the past - today there are 64bit kernels.
Solaris never had OOM killer, and Sparc early supported 64bit - there was no need for something like PAE.