Why do i see c++ pointers in multi-terabyte range on a mac with 16 gigabytes of memory?

Question

Memory address values outputted by C++ 14 compiler on a Mac Mini with 16 GB of RAM (+1 GB virtual) show just shy of 128 TB range, even the difference between the stack and heap is over 186 GB.

I had just installed the latest C++ compiler (to refresh my C++ knowledge) on my Mac Mini with Intel CPU, 16 GB of RAM, 1TB SSD.

#include <iostream>

int main () {
    double value = 2.0;
    double* pvalue  = NULL; // Pointer initialized with null
    pvalue  = new double;   // Request memory for the variable

    *pvalue = 29494.99;     // Store value at allocated address
    std::cout << "Value of value : " << value << std::endl; // This is stored on stack
    std::cout << "Address of value : " << &value << std::endl; // 0x7ffedfd08a30 (just below 128 TB)

    std::cout << "Value at pvalue : " << *pvalue << std::endl; // This is stored on heap
    std::cout << "Value of pvalue : " << pvalue << std::endl; // 0x7fd05f402830 (just below 128 TB)
    // Even the difference is: 0x2E80906200 (over 186 GB)

    delete pvalue;         // free up the memory.

    return 0;
}

/usr/local/bin/c++-9 heap.cpp -o heap

./heap

I was curious to see the memory ranges of the stack and heap. I expected both numbers to be within my system's total physical memory range: 16 GB RAM, 1 GB Virtual RAM, 1 TB SSD RAM . However, the results for both Stack and Heap show just shy of 128 TB, and even the difference between them is more than 186 GB:

Value of value : 2
Address of value : 0x7ffee1776a30
Value at pvalue : 29495
Value of pvalue : 0x7fd05f402830

I had researched this oddity with no good result. Anybody can explain this please?

Have your reasearch not immediately led you to the notion of virtual memory? — , Jun 19 '19 at 01:19
Why would the amount of physical memory have anything to do with the way sections are laid out in virtual memory? You could have 4GB of physical RAM but a process could memory map three 1TB files into its view of virtual memory if you wanted to. — David Schwartz, Jun 19 '19 at 02:51
I'd suggest reading [What are the differences between virtual memory and physical memory?](https://stackoverflow.com/q/14347206/364696) — ShadowRanger, Jun 19 '19 at 02:51
Thanks for all the comments! Just to clarify, I am aware of the virtual memory being set to 1 GB by default by the OSX on my Mac Mini, so the question remains, why the huge numbers used by the compiler to describe the stack and heap. After restart, I only started the Terminal, and again the same kind of numbers: Stack at: 0x7ffee8ba7a20 Heap at: 0x7ff9cad00000. All this with less than 25% of 16.00 GB of physical RAM being used: Memory Used: 2.65 GB < App Memory: 1.25 GB Wired Memory: 1.40 GB. Please post your code execution numbers! My best guess: 7f0000000000 is added to all actual values. — Lucifer Morningstar, Jun 19 '19 at 04:38
I think you missed the concept of virtual addresses and paging. Hence, the address seen in your process is not a physical address. Instead, it is a bit combination of a page number and an offset in the addressed page. This virtual address is translated into a physical/linear address using the page table (under to hood). Now, the virtual memory might come into play as the page might be swapped out of physical memory. Paging is not only for virtual memory. It's other purpose is to provide linear memory to process which might be spread in physical memory -> it simplifies mem. management in OS. — Scheff's Cat, Jun 19 '19 at 05:42
May be, this may help: [Virtual Addresses](https://www.bottomupcs.com/virtual_addresses.xhtml) — Scheff's Cat, Jun 19 '19 at 05:43
_My best guess: 7f0000000000 is added to all actual values._ You seem to believe that the binary number of the virtual address means that at least that size is in use. You cannot assume to read the virtual address as one binary number. There are ranges of bits with distinct meaning. I failed to find an explicit explanation of the virtual address bits for e.g. Intel x64. However, there is often mentioned that certain ranges of virtual addresses are reserved for certain uses. Hence, there might be gaps by design. — Scheff's Cat, Jun 19 '19 at 06:06
An address is not a counting number, it doesn't count anything. It's like a phone number. If you see 212-555-5555, it doesn't mean there are 2125555555 or more phone numbers out there. — n. m. could be an AI, Jun 19 '19 at 06:57

Lucifer Morningstar · Answer 1 · 2019-06-19T21:46:31.437

Following up on my guess, that 7f0000000000 is added to actual values.

I looked up that number and came up with this Linux related info:

Direct shadow mapping (64-bit Linux) Application 0x7fffffffffff 0x7f0000000000 ;

So it looks like GCC on Darwin is using a similar scheme to prefix the Application Virtual Memory Pool. Since a 64 bit processor can theoretically address 16 EiB (exbibyte) memory locations (2 to the power of 64), from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF, it may follow that the Application virtual memory space was chosen as well above the usual physical memory address space, so as to not clash with it in the near future, while still being located in the lowest 1/512 fraction of the 64 bit addressable space.

Mind boggling numbers... I digress here to keep whats left of my sanity :)

Why do i see c++ pointers in multi-terabyte range on a mac with 16 gigabytes of memory?

1 Answers1