Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8204043 | 11.0.1 | Matthias Baesken | P3 | Resolved | Fixed | team |
On Windows, the os::print_memory_info misses a few memory-related infos that might be interesting :
- current and peak WorkingSet size (= physical memory assigned to the process)
- current and peak commit charge (also known as "private bytes" in Windows tools)
- on 32bit Windows :
user-mode portion/free user mode portion of virtual address-space (Total/AvailVirtual) because it shows how close do we get to the 2-4 GB per process border.
- the current naming of "swap/free-swap" memory is a bit misleading;
in the Windows world swap is a special page file used for UWP apps.
(see Windows Internals : "The swap file" (chapter 5 Memory management)
Windows 8 added another page file called a swap file. It is ... exclusively used for UWP (Universal Windows Platform) apps.
Our output (ullTotalPageFile and ullAvailPageFile) is NOT about the UWP related values, it is about page file sizes
(so calling it TotalPageFile/AvailPageFile in "Windows-speak" or just virtual memory might be more appropriate).
https://msdn.microsoft.com/de-de/library/windows/desktop/aa366770(v=vs.85).aspx
documents it in the following way:
ullTotalPageFile:
The current committed memory limit for the system or the current process, whichever is smaller,...
ullAvailPageFile :
The maximum amount of memory the current process can commit, in bytes. This value is equal to or smaller than the system-wide available commit value
Aditionally I suggest having output of the various memory-values in M (megabyte) as well , the k (kilobyte) output sometimes gives very high and unreadable numbers).
After the change, the output in the hs-error file looks like this (Windows Server 2012 R2) :
Memory: 4k page, system-wide physical 16383M (8828M free)
TotalPageFile size 48778M (AvailPageFile size 41076M), user-mode portion of virtual address-space 2047M (3M free)
current process WorkingSet (physical memory assigned to process): 504M, peak: 504M
current process commit charge ("private bytes"): 847M, peak: 847M
- current and peak WorkingSet size (= physical memory assigned to the process)
- current and peak commit charge (also known as "private bytes" in Windows tools)
- on 32bit Windows :
user-mode portion/free user mode portion of virtual address-space (Total/AvailVirtual) because it shows how close do we get to the 2-4 GB per process border.
- the current naming of "swap/free-swap" memory is a bit misleading;
in the Windows world swap is a special page file used for UWP apps.
(see Windows Internals : "The swap file" (chapter 5 Memory management)
Windows 8 added another page file called a swap file. It is ... exclusively used for UWP (Universal Windows Platform) apps.
Our output (ullTotalPageFile and ullAvailPageFile) is NOT about the UWP related values, it is about page file sizes
(so calling it TotalPageFile/AvailPageFile in "Windows-speak" or just virtual memory might be more appropriate).
https://msdn.microsoft.com/de-de/library/windows/desktop/aa366770(v=vs.85).aspx
documents it in the following way:
ullTotalPageFile:
The current committed memory limit for the system or the current process, whichever is smaller,...
ullAvailPageFile :
The maximum amount of memory the current process can commit, in bytes. This value is equal to or smaller than the system-wide available commit value
Aditionally I suggest having output of the various memory-values in M (megabyte) as well , the k (kilobyte) output sometimes gives very high and unreadable numbers).
After the change, the output in the hs-error file looks like this (Windows Server 2012 R2) :
Memory: 4k page, system-wide physical 16383M (8828M free)
TotalPageFile size 48778M (AvailPageFile size 41076M), user-mode portion of virtual address-space 2047M (3M free)
current process WorkingSet (physical memory assigned to process): 504M, peak: 504M
current process commit charge ("private bytes"): 847M, peak: 847M
- backported by
-
JDK-8204043 Enhance os::print_memory_info on Windows
-
- Resolved
-