May Windows 64-bit allocate virtual memory over 7FFF'FFFF'FFFF?How to detect Windows 64-bit platform with .NET?Why is address zero used for the null pointer?Behind Windows x64's 44-bit virtual memory address limitReleasing virtual memory reserved by C++ 'new' on WindowsBehavior of 32 bit applications in 64 bit Windows (memory)allocate more than 1 GB memory on 32 bit XPForce memory allocation to allocate from higher address (>4GB) on 64-bit LinuxHow to cast an allocated memory block to an array addressable data type.Why do we use int when memory is only positiveMemory allocation in cross platform C++ library
Killing a star safely
Considerations when providing money to only one child out of two
Found more old paper shares from broken up companies
Plotting maxima within a simplex
Can a creature sustain itself by eating its own severed body parts?
What happens to a permanent I gained control over using Agent of Treachery, and I leave a multiplayer game?
Why is there an extra "t" in Lemmatization?
Can I use Sitecore's Configuration patching mechanics for my Identity Server configuration?
Magic is the twist
What is the best word describing the nature of expiring in a short amount of time, connoting "losing public attention"?
Quickest way to move a line in a text file before another line in a text file?
My current job follows "worst practices". How can I talk about my experience in an interview without giving off red flags?
Is it OK to accept a job opportunity while planning on not taking it?
Monday's Blocking Donimoes Problem
How to handle not being able to attend as often as I'd like
Why was Quirrell said to be in the Black Forest if Voldemort was actually in Albania?
Has Iron Man made any suit for underwater combat?
Reissue US, UK, Canada visas in stolen passports
Host telling me to cancel my booking in exchange for a discount?
Why Lie algebras if what we care about in physics are groups?
What is the standard representation of a stop which could be either ejective or aspirated?
Why didn't NASA launch communications relay satellites for the Apollo missions?
Claiming statutory warranty for a fault that resulted in the loss of the product
Calculating Fibonacci sequence in several different ways
May Windows 64-bit allocate virtual memory over 7FFF'FFFF'FFFF?
How to detect Windows 64-bit platform with .NET?Why is address zero used for the null pointer?Behind Windows x64's 44-bit virtual memory address limitReleasing virtual memory reserved by C++ 'new' on WindowsBehavior of 32 bit applications in 64 bit Windows (memory)allocate more than 1 GB memory on 32 bit XPForce memory allocation to allocate from higher address (>4GB) on 64-bit LinuxHow to cast an allocated memory block to an array addressable data type.Why do we use int when memory is only positiveMemory allocation in cross platform C++ library
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Context
I'm working on upgrading a .NET library to support 64-bit. That library performs various operation directly in memory of other processes on Windows. I have to choose between the two types IntPtr (max positive value 7FFF'FFFF'FFFF'FFFF) or UIntPtr (max positive value FFFF'FFFF'FFFF'FFFF) to handle my memory pointers. There is a lot of information on the Web about the two. IntPtr seems to be the facto agreed choice, as it is CLS-compliant and most of .NET API rely on that (ref Marshal from InteropServices).
The question
I decided to open a 64-bit process and inspect the allocated memory regions, as well as the loaded modules in the process to see if it would be valuable to support unsigned pointers using UIntPtr (addresses > 7FFF'FFFF'FFFF'FFFF). As illustrated in the screenshot below, it seems the memory addresses does not load symbols, nor allocate memory over 7FFF'FFFF'FFFF. Is there a specific reason for doing so ? May Windows allocate memory regions over that value in some cases ?
Thanks !
c# windows memory 64-bit internals
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
add a comment |
Context
I'm working on upgrading a .NET library to support 64-bit. That library performs various operation directly in memory of other processes on Windows. I have to choose between the two types IntPtr (max positive value 7FFF'FFFF'FFFF'FFFF) or UIntPtr (max positive value FFFF'FFFF'FFFF'FFFF) to handle my memory pointers. There is a lot of information on the Web about the two. IntPtr seems to be the facto agreed choice, as it is CLS-compliant and most of .NET API rely on that (ref Marshal from InteropServices).
The question
I decided to open a 64-bit process and inspect the allocated memory regions, as well as the loaded modules in the process to see if it would be valuable to support unsigned pointers using UIntPtr (addresses > 7FFF'FFFF'FFFF'FFFF). As illustrated in the screenshot below, it seems the memory addresses does not load symbols, nor allocate memory over 7FFF'FFFF'FFFF. Is there a specific reason for doing so ? May Windows allocate memory regions over that value in some cases ?
Thanks !
c# windows memory 64-bit internals
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
Interesting question... +1 and favorite from me, I'm curious about the answer too.
– EJoshuaS
Mar 26 at 13:32
IntPtr is fine, the x64 memory model splits the address space in two with the upper half exclusively reserved to the OS kernel code.
– Hans Passant
Mar 26 at 13:34
Don't depend on this. The last time the limit was raised there was no bwcompat flag.
– Joshua
Mar 26 at 14:45
add a comment |
Context
I'm working on upgrading a .NET library to support 64-bit. That library performs various operation directly in memory of other processes on Windows. I have to choose between the two types IntPtr (max positive value 7FFF'FFFF'FFFF'FFFF) or UIntPtr (max positive value FFFF'FFFF'FFFF'FFFF) to handle my memory pointers. There is a lot of information on the Web about the two. IntPtr seems to be the facto agreed choice, as it is CLS-compliant and most of .NET API rely on that (ref Marshal from InteropServices).
The question
I decided to open a 64-bit process and inspect the allocated memory regions, as well as the loaded modules in the process to see if it would be valuable to support unsigned pointers using UIntPtr (addresses > 7FFF'FFFF'FFFF'FFFF). As illustrated in the screenshot below, it seems the memory addresses does not load symbols, nor allocate memory over 7FFF'FFFF'FFFF. Is there a specific reason for doing so ? May Windows allocate memory regions over that value in some cases ?
Thanks !
c# windows memory 64-bit internals
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
Context
I'm working on upgrading a .NET library to support 64-bit. That library performs various operation directly in memory of other processes on Windows. I have to choose between the two types IntPtr (max positive value 7FFF'FFFF'FFFF'FFFF) or UIntPtr (max positive value FFFF'FFFF'FFFF'FFFF) to handle my memory pointers. There is a lot of information on the Web about the two. IntPtr seems to be the facto agreed choice, as it is CLS-compliant and most of .NET API rely on that (ref Marshal from InteropServices).
The question
I decided to open a 64-bit process and inspect the allocated memory regions, as well as the loaded modules in the process to see if it would be valuable to support unsigned pointers using UIntPtr (addresses > 7FFF'FFFF'FFFF'FFFF). As illustrated in the screenshot below, it seems the memory addresses does not load symbols, nor allocate memory over 7FFF'FFFF'FFFF. Is there a specific reason for doing so ? May Windows allocate memory regions over that value in some cases ?
Thanks !
c# windows memory 64-bit internals
c# windows memory 64-bit internals
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
asked Mar 26 at 13:24
ZenLulzZenLulz
4,1593 gold badges29 silver badges42 bronze badges
4,1593 gold badges29 silver badges42 bronze badges
Interesting question... +1 and favorite from me, I'm curious about the answer too.
– EJoshuaS
Mar 26 at 13:32
IntPtr is fine, the x64 memory model splits the address space in two with the upper half exclusively reserved to the OS kernel code.
– Hans Passant
Mar 26 at 13:34
Don't depend on this. The last time the limit was raised there was no bwcompat flag.
– Joshua
Mar 26 at 14:45
add a comment |
Interesting question... +1 and favorite from me, I'm curious about the answer too.
– EJoshuaS
Mar 26 at 13:32
IntPtr is fine, the x64 memory model splits the address space in two with the upper half exclusively reserved to the OS kernel code.
– Hans Passant
Mar 26 at 13:34
Don't depend on this. The last time the limit was raised there was no bwcompat flag.
– Joshua
Mar 26 at 14:45
Interesting question... +1 and favorite from me, I'm curious about the answer too.
– EJoshuaS
Mar 26 at 13:32
Interesting question... +1 and favorite from me, I'm curious about the answer too.
– EJoshuaS
Mar 26 at 13:32
IntPtr is fine, the x64 memory model splits the address space in two with the upper half exclusively reserved to the OS kernel code.
– Hans Passant
Mar 26 at 13:34
IntPtr is fine, the x64 memory model splits the address space in two with the upper half exclusively reserved to the OS kernel code.
– Hans Passant
Mar 26 at 13:34
Don't depend on this. The last time the limit was raised there was no bwcompat flag.
– Joshua
Mar 26 at 14:45
Don't depend on this. The last time the limit was raised there was no bwcompat flag.
– Joshua
Mar 26 at 14:45
add a comment |
3 Answers
3
active
oldest
votes
In Windows each process has only an address space of 8TB, therefore the upper limit for user code is 0x7FF'FFFF'FFFF
The range of virtual addresses that is available to a process is called the virtual address space for the process. Each user-mode process has its own private virtual address space. For a 32-bit process, the virtual address space is usually the 2-gigabyte range 0x00000000 through 0x7FFFFFFF. For a 64-bit process, the virtual address space is the 8-terabyte range 0x000'00000000 through 0x7FF'FFFFFFFF. A range of virtual addresses is sometimes called a range of virtual memory.
This diagram illustrates some of the key features of virtual address spaces.
https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
The upper 248TB belongs to kernel mode, summing up to 256TB of address space, which is addressed by 48 bits. That means the highest possible positive address is 247-1 = 0x7FFF'FFFF'FFFF
In 64-bit Windows, the theoretical amount of virtual address space is 2^64 bytes (16 exabytes), but only a small portion of the 16-exabyte range is actually used. The 8-terabyte range from 0x000'00000000 through 0x7FF'FFFFFFFF is used for user space, and portions of the 248-terabyte range from 0xFFFF0800'00000000 through 0xFFFFFFFF'FFFFFFFF are used for system space.
The significant part is 48-bit wide probably because most current x86-64 implementations use 48-bit virtual address
The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (240 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM.
https://en.wikipedia.org/wiki/X86-64#Architectural_features
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
add a comment |
Due to specifications on x64 you can depend on userspace pointers always fitting in IntPtr. You cannot depend on a smaller space. The CPU could get more address lines in the future. When this happened between Windows 8 and Windows 8.1, no backwards compatibility flag was added.
In fact you got both positive and negative pointers in x86, but storing pointers in IntPtr worked anyway because of the no-mans-land at 0x7FFF0000 and the null trap range at 0x00000000.
I don't think you're trying to do tagged pointers, but if you are, the only acceptable way to do tagged pointers is the bottom two bits.
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
add a comment |
In Windows, the maximum virtual memory address is 7FFF'FFFF'FFFF'FFFF, i.e. it is not possible to allocate memory beyond this address. Historically, the first 64-bit processors from AMD and Intel (as per AMD64 specs) supported only addresses of 48 bits. Hence the limit.
See more details here:
http://www.alex-ionescu.com/?p=50
and
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
1
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,IntPtrwould be adequate even if we had the full 64-bit range split equally between user and kernel mode.
– eryksun
Mar 26 at 14:23
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55358289%2fmay-windows-64-bit-allocate-virtual-memory-over-7fffffffffff%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
In Windows each process has only an address space of 8TB, therefore the upper limit for user code is 0x7FF'FFFF'FFFF
The range of virtual addresses that is available to a process is called the virtual address space for the process. Each user-mode process has its own private virtual address space. For a 32-bit process, the virtual address space is usually the 2-gigabyte range 0x00000000 through 0x7FFFFFFF. For a 64-bit process, the virtual address space is the 8-terabyte range 0x000'00000000 through 0x7FF'FFFFFFFF. A range of virtual addresses is sometimes called a range of virtual memory.
This diagram illustrates some of the key features of virtual address spaces.
https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
The upper 248TB belongs to kernel mode, summing up to 256TB of address space, which is addressed by 48 bits. That means the highest possible positive address is 247-1 = 0x7FFF'FFFF'FFFF
In 64-bit Windows, the theoretical amount of virtual address space is 2^64 bytes (16 exabytes), but only a small portion of the 16-exabyte range is actually used. The 8-terabyte range from 0x000'00000000 through 0x7FF'FFFFFFFF is used for user space, and portions of the 248-terabyte range from 0xFFFF0800'00000000 through 0xFFFFFFFF'FFFFFFFF are used for system space.
The significant part is 48-bit wide probably because most current x86-64 implementations use 48-bit virtual address
The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (240 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM.
https://en.wikipedia.org/wiki/X86-64#Architectural_features
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
add a comment |
In Windows each process has only an address space of 8TB, therefore the upper limit for user code is 0x7FF'FFFF'FFFF
The range of virtual addresses that is available to a process is called the virtual address space for the process. Each user-mode process has its own private virtual address space. For a 32-bit process, the virtual address space is usually the 2-gigabyte range 0x00000000 through 0x7FFFFFFF. For a 64-bit process, the virtual address space is the 8-terabyte range 0x000'00000000 through 0x7FF'FFFFFFFF. A range of virtual addresses is sometimes called a range of virtual memory.
This diagram illustrates some of the key features of virtual address spaces.
https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
The upper 248TB belongs to kernel mode, summing up to 256TB of address space, which is addressed by 48 bits. That means the highest possible positive address is 247-1 = 0x7FFF'FFFF'FFFF
In 64-bit Windows, the theoretical amount of virtual address space is 2^64 bytes (16 exabytes), but only a small portion of the 16-exabyte range is actually used. The 8-terabyte range from 0x000'00000000 through 0x7FF'FFFFFFFF is used for user space, and portions of the 248-terabyte range from 0xFFFF0800'00000000 through 0xFFFFFFFF'FFFFFFFF are used for system space.
The significant part is 48-bit wide probably because most current x86-64 implementations use 48-bit virtual address
The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (240 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM.
https://en.wikipedia.org/wiki/X86-64#Architectural_features
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
add a comment |
In Windows each process has only an address space of 8TB, therefore the upper limit for user code is 0x7FF'FFFF'FFFF
The range of virtual addresses that is available to a process is called the virtual address space for the process. Each user-mode process has its own private virtual address space. For a 32-bit process, the virtual address space is usually the 2-gigabyte range 0x00000000 through 0x7FFFFFFF. For a 64-bit process, the virtual address space is the 8-terabyte range 0x000'00000000 through 0x7FF'FFFFFFFF. A range of virtual addresses is sometimes called a range of virtual memory.
This diagram illustrates some of the key features of virtual address spaces.
https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
The upper 248TB belongs to kernel mode, summing up to 256TB of address space, which is addressed by 48 bits. That means the highest possible positive address is 247-1 = 0x7FFF'FFFF'FFFF
In 64-bit Windows, the theoretical amount of virtual address space is 2^64 bytes (16 exabytes), but only a small portion of the 16-exabyte range is actually used. The 8-terabyte range from 0x000'00000000 through 0x7FF'FFFFFFFF is used for user space, and portions of the 248-terabyte range from 0xFFFF0800'00000000 through 0xFFFFFFFF'FFFFFFFF are used for system space.
The significant part is 48-bit wide probably because most current x86-64 implementations use 48-bit virtual address
The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (240 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM.
https://en.wikipedia.org/wiki/X86-64#Architectural_features
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
In Windows each process has only an address space of 8TB, therefore the upper limit for user code is 0x7FF'FFFF'FFFF
The range of virtual addresses that is available to a process is called the virtual address space for the process. Each user-mode process has its own private virtual address space. For a 32-bit process, the virtual address space is usually the 2-gigabyte range 0x00000000 through 0x7FFFFFFF. For a 64-bit process, the virtual address space is the 8-terabyte range 0x000'00000000 through 0x7FF'FFFFFFFF. A range of virtual addresses is sometimes called a range of virtual memory.
This diagram illustrates some of the key features of virtual address spaces.
https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
The upper 248TB belongs to kernel mode, summing up to 256TB of address space, which is addressed by 48 bits. That means the highest possible positive address is 247-1 = 0x7FFF'FFFF'FFFF
In 64-bit Windows, the theoretical amount of virtual address space is 2^64 bytes (16 exabytes), but only a small portion of the 16-exabyte range is actually used. The 8-terabyte range from 0x000'00000000 through 0x7FF'FFFFFFFF is used for user space, and portions of the 248-terabyte range from 0xFFFF0800'00000000 through 0xFFFFFFFF'FFFFFFFF are used for system space.
The significant part is 48-bit wide probably because most current x86-64 implementations use 48-bit virtual address
The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (240 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM.
https://en.wikipedia.org/wiki/X86-64#Architectural_features
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
edited Mar 26 at 14:57
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
answered Mar 26 at 14:49
phuclvphuclv
17.4k9 gold badges59 silver badges251 bronze badges
17.4k9 gold badges59 silver badges251 bronze badges
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
add a comment |
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
Starting with Windows 8.1, the user-mode virtual address space is 128 TB (refer to Memory Limits for Windows and Windows Server Releases, i.e. the full 47 bits that are currently available to x64 user-mode code.
– eryksun
Mar 26 at 15:17
add a comment |
Due to specifications on x64 you can depend on userspace pointers always fitting in IntPtr. You cannot depend on a smaller space. The CPU could get more address lines in the future. When this happened between Windows 8 and Windows 8.1, no backwards compatibility flag was added.
In fact you got both positive and negative pointers in x86, but storing pointers in IntPtr worked anyway because of the no-mans-land at 0x7FFF0000 and the null trap range at 0x00000000.
I don't think you're trying to do tagged pointers, but if you are, the only acceptable way to do tagged pointers is the bottom two bits.
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
add a comment |
Due to specifications on x64 you can depend on userspace pointers always fitting in IntPtr. You cannot depend on a smaller space. The CPU could get more address lines in the future. When this happened between Windows 8 and Windows 8.1, no backwards compatibility flag was added.
In fact you got both positive and negative pointers in x86, but storing pointers in IntPtr worked anyway because of the no-mans-land at 0x7FFF0000 and the null trap range at 0x00000000.
I don't think you're trying to do tagged pointers, but if you are, the only acceptable way to do tagged pointers is the bottom two bits.
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
add a comment |
Due to specifications on x64 you can depend on userspace pointers always fitting in IntPtr. You cannot depend on a smaller space. The CPU could get more address lines in the future. When this happened between Windows 8 and Windows 8.1, no backwards compatibility flag was added.
In fact you got both positive and negative pointers in x86, but storing pointers in IntPtr worked anyway because of the no-mans-land at 0x7FFF0000 and the null trap range at 0x00000000.
I don't think you're trying to do tagged pointers, but if you are, the only acceptable way to do tagged pointers is the bottom two bits.
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
Due to specifications on x64 you can depend on userspace pointers always fitting in IntPtr. You cannot depend on a smaller space. The CPU could get more address lines in the future. When this happened between Windows 8 and Windows 8.1, no backwards compatibility flag was added.
In fact you got both positive and negative pointers in x86, but storing pointers in IntPtr worked anyway because of the no-mans-land at 0x7FFF0000 and the null trap range at 0x00000000.
I don't think you're trying to do tagged pointers, but if you are, the only acceptable way to do tagged pointers is the bottom two bits.
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
edited Mar 26 at 15:14
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
answered Mar 26 at 14:48
JoshuaJoshua
25.6k5 gold badges50 silver badges108 bronze badges
25.6k5 gold badges50 silver badges108 bronze badges
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
add a comment |
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
To clarify, the change in Windows 8.1 was removing internal limitations in order to make the full 47-bit range of x64 available to user-mode addresses. That's not directly related to the previous statement that "[t]he CPU could get more address lines".
– eryksun
Mar 26 at 15:25
add a comment |
In Windows, the maximum virtual memory address is 7FFF'FFFF'FFFF'FFFF, i.e. it is not possible to allocate memory beyond this address. Historically, the first 64-bit processors from AMD and Intel (as per AMD64 specs) supported only addresses of 48 bits. Hence the limit.
See more details here:
http://www.alex-ionescu.com/?p=50
and
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
1
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,IntPtrwould be adequate even if we had the full 64-bit range split equally between user and kernel mode.
– eryksun
Mar 26 at 14:23
add a comment |
In Windows, the maximum virtual memory address is 7FFF'FFFF'FFFF'FFFF, i.e. it is not possible to allocate memory beyond this address. Historically, the first 64-bit processors from AMD and Intel (as per AMD64 specs) supported only addresses of 48 bits. Hence the limit.
See more details here:
http://www.alex-ionescu.com/?p=50
and
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
1
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,IntPtrwould be adequate even if we had the full 64-bit range split equally between user and kernel mode.
– eryksun
Mar 26 at 14:23
add a comment |
In Windows, the maximum virtual memory address is 7FFF'FFFF'FFFF'FFFF, i.e. it is not possible to allocate memory beyond this address. Historically, the first 64-bit processors from AMD and Intel (as per AMD64 specs) supported only addresses of 48 bits. Hence the limit.
See more details here:
http://www.alex-ionescu.com/?p=50
and
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
In Windows, the maximum virtual memory address is 7FFF'FFFF'FFFF'FFFF, i.e. it is not possible to allocate memory beyond this address. Historically, the first 64-bit processors from AMD and Intel (as per AMD64 specs) supported only addresses of 48 bits. Hence the limit.
See more details here:
http://www.alex-ionescu.com/?p=50
and
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
answered Mar 26 at 13:49
NickNick
2,40213 silver badges15 bronze badges
2,40213 silver badges15 bronze badges
1
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,IntPtrwould be adequate even if we had the full 64-bit range split equally between user and kernel mode.
– eryksun
Mar 26 at 14:23
add a comment |
1
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,IntPtrwould be adequate even if we had the full 64-bit range split equally between user and kernel mode.
– eryksun
Mar 26 at 14:23
1
1
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,
IntPtr would be adequate even if we had the full 64-bit range split equally between user and kernel mode.– eryksun
Mar 26 at 14:23
The limit for x64 user-mode code is 7FFF'FFFF'FFFF. Bits 47-63 have to be either all 0 (user mode) or all 1 (kernel mode). Interesting as that is,
IntPtr would be adequate even if we had the full 64-bit range split equally between user and kernel mode.– eryksun
Mar 26 at 14:23
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55358289%2fmay-windows-64-bit-allocate-virtual-memory-over-7fffffffffff%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Interesting question... +1 and favorite from me, I'm curious about the answer too.
– EJoshuaS
Mar 26 at 13:32
IntPtr is fine, the x64 memory model splits the address space in two with the upper half exclusively reserved to the OS kernel code.
– Hans Passant
Mar 26 at 13:34
Don't depend on this. The last time the limit was raised there was no bwcompat flag.
– Joshua
Mar 26 at 14:45