This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
What is the system you are on? Is it a 64 bit OS? Is your JRE 64 bit compatible? Is JProfiler 64 bit compatible?
With 64 bit machines you can have much more memory than 32 bit machines. Problem with this is that many applications are just 32 bit programs running in a 64 bit shell, so they can only see the 32 bit addressed memory, and they can't get to the rest that the system has available.
As Jeanne wrote, Task Manager (and any other operating system-based tool that reports process memory usage) reports the memory used by the java process. This includes the amount of heap allocated, the code for the JVM, the data structures used by the JVM, and so on.
Java-based tools, such as JConsole, VisualVM, and JProfiler, report on heap usage. This is always a subset of the full memory used by the java process.
There is no way to control the non-heap portion of the JVM memory because that is already handled automatically by the operating system as the C/C++ code that makes up the JVM allocates/deallocates structures referenced by pointers.
The bug you referenced appears to be more about perceptions that reality. Yes, doing what was suggested can effect working set memory usage, but has no bearing on commit memory (man, I hope I have these terms correct, it has been quite a while since I delved deeply into Windows memory management).
As a basic example, if the JVM asks Windows for 200MB to allocate the heap, Windows marks 200MB of memory (in this case, RAM-size + page-file-size) as reserved (committed), but physically gives the JVM only a small chunk. This small chunk is what is reported in Task Manager as used memory. Then as the JVM uses more and more of the heap, Windows gives it more and more of its allocation of the 200MB. Typically, the full 200MB is never marked as in-use because a full GC will take place well before you get there.
The suggested fix in the reported bug is, after GC, to get Windows to mark the unused heap as not in-use. But note that the memory will still be marked as reserved - that is as part of committed memory.
In Windows, when the committed memory for all process hits the maximum system memory (RAM + page file), you get an out of memory error from Windows.
As I said, it has been a while since I studied Windows memory allocation in depth, so take the above with a grain of salt, but that is what I remember.