Then kindly inform them that (as the man page states), top reports the Virtual and Real memory in use by processes and the system free memory. At the time of your screen shot, your processes were only using 1,099,752Kb of virtual address space (just over 1Gb) and the system had over 4Gb of free memory.
You don't see your 24Gb of virtual address space possible (not all the 8Gb of RAM is available as virtual address space) simply because the user space processes aren't using that much. There is no indication of a low memory condition here, nor is there any sign that the system isn't using the full memory. (Only that user processes aren't consuming it all at this time, which is very normal - especially since at the time of the screen shot, the load looks very light).
There _could_ be a low virtual address space condition if the swap was reserved via other paths (such as almost all swap being memory swap and almost all of that being kernel consumption, but that's more than a bit unlikely with 4Gb free). Still, the swapinfo output is also needed to establish that there is no virtual memory lack on the system (and your output shows 21.8Gb or so available for reservation, so there certainly is not at this time, anyway).
If/when the application issue happens again (is it reporting a clear error number that you know of? Is it ENOMEM? Is there any indication of what system call it may have been using [malloc? mmap?])? It is certainly possible (in fact likely) that what is really going on here is that they've hit maxdsiz and hence their application rlimit/ulimit on data or stack and there's no resource issue with the system as a whole at all.
