If your hardware supports 5-level page tables and your kernel is reasonably
modern you can get addresses today where only the top 8 bits are zero:
The following program prints:
Size 64T, addr = 0x2000000000000
Size 128T, addr = 0xffba0bca5a6000
The high hint to mmap is important - if you don't have that then the kernel
is backwards compatible and won't give out high addresses beyond the 48 bit
limit. This is why V8 still works on such hardware, but it limits the
amount of virtual memory you can use.
#include <errno.h>
#include <stdio.h>
#include <sys/mman.h>
int main() {
unsigned long size = 1ULL << 46;
for (int i = 0; i < 2; i++) {
void* addr = mmap(
reinterpret_cast<void*>(1ULL << 49),
1ULL << 46,
PROT_NONE,
MAP_PRIVATE | MAP_ANONYMOUS,
0,
0);
printf("Size %dT, addr = %p\n", (int)(size >> 40), addr);
if (addr == reinterpret_cast<void*>(-1)) {
perror("mmap");
return 1;
}
size <<= 1;
}
return 0;
}
On Wed, Aug 6, 2025 at 9:24 AM Olivier Flückiger <ol...@chromium.org> wrote:
> Yeah, we are not clinging to that design. It really should be a normal
> compressed pointer. Then we'd have space for a separate mark bit and
> argument count like on 32 bit architectures. Last I checked there were some
> technical issues with getting the correct base to uncompress the pointer
> and it's also kinda performance sensitive. That's why nobody has addressed
> it so far.
>
> That said, I don't think we have to worry about user space pointers in
> that range according to
> https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt .
>
> *oli
>
>
>
> On Mon, Aug 4, 2025 at 1:04 PM Erik Corry <erikco...@chromium.org> wrote:
>
>> Seems like this will soon be a problem for Linux too. My /proc/cpuinfo
>> says:
>>
>> address sizes : 52 bits physical, 57 bits virtual
>>
>> so it looks like we can't assume the high 16 bits are zero for much
>> longer.
>>
>>
>> On Tuesday, April 22, 2025 at 5:21:16 PM UTC+2 kebesoftwar...@gmail.com
>> wrote:
>>
>>> Per the nearly-approved AIX commit conversation (
>>> https://chromium-review.googlesource.com/c/v8/v8/+/6320599 ), I would
>>> like to address V8's mishandling of illumos/amd64 VA48 available address
>>> space. The problem is rather straightforward: illumos amd64 processes
>>> have their 48-bit available VA space split into two parts.
>>>
>>> Per the original amd64/x64 4-level paging spec: the low 47 bits of
>>> address space: 0x0 -> 0x00007fffffffffff are available, AND SO IS the high
>>> 47 bits of available address space: 0xffff800000000000 ->
>>> 0xffffffffffffffff. Notwithstanding carve-outs toward the extremes of the
>>> 64-bit address space (i.e. not too close to 0 or to 0xffffffffffffffff),
>>> memory mappings can come from either of those ranges.
>>>
>>> For pointer-compression that shifts 16 bits to the left, the easy thing
>>> to do is to check the highest-order compressed-pointer bit, and fill the
>>> top 16 with 1s upon decompression. Decompression is done in
>>> CodeStubAssembler::LoadCodeObjectFromJSDispatchTable(), and while I had
>>> my first-attempt implementation picked-apart as part of my experiments with
>>> Node, the idea is sound.
>>>
>>> Also, the choice made in the JS Dispatch Table to mark a free pointer
>>> with 0xffff in the top 16 bits will not work in an amd64 address space
>>> using all of the available VA space, because half of it lives in address
>>> space starting with 0xffff. A change of marking bits (I used 0xfeed in the
>>> first-attempt) and better clearing/checking (using logical-and) solves this.
>>>
>>> The assumption of only-low-47-bits of virtual address space runs up
>>> against two problems. The first is expanded available virtual address
>>> space beyond 0x0000800000000000. The aforementioned IBM/AIX changes hint
>>> at this possibility: All 48 lower bits are available with a fixed non-zero
>>> 16-bit prefix. The second is that at least for amd64, address space will
>>> appear in both the high-end and the low-end of the 64-bit address space.
>>>
>>> Already available in some hardware is VA57, which resembles the
>>> aforementioned VA48 except that the low available space grows to 0x0 ->
>>> 0x007fffffffffffff, and the high available space grows down to cover
>>> 0xff80000000000000 -> 0xffffffffffffffff. Operating systems may offer the
>>> entirety of both ends of VA57 to a process.
>>>
>>> I would like to help correct this in V8 so its downstreams, especially
>>> Node, can work properly in environments that offer full address space to
>>> processes. I'm reading up on https://v8.dev/docs/contribute , and
>>> please consider this email my following of, "Ask on V8’s mailing list
>>> for guidance".
>>>
>> --
>> --
>> v8-dev mailing list
>> v8-dev@googlegroups.com
>> http://groups.google.com/group/v8-dev
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-dev+unsubscr...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/v8-dev/1ca103a0-8623-430a-83f4-58ee712b329en%40googlegroups.com
>> <https://groups.google.com/d/msgid/v8-dev/1ca103a0-8623-430a-83f4-58ee712b329en%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> --
> v8-dev mailing list
> v8-dev@googlegroups.com
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-dev+unsubscr...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/v8-dev/CAPfE2j2Z%2BZOmz2YH2DUAO9axJcc1XhKECCDjVtTK8gwyHRDESQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/v8-dev/CAPfE2j2Z%2BZOmz2YH2DUAO9axJcc1XhKECCDjVtTK8gwyHRDESQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/v8-dev/CAHZxHpiBxkLHNKXV5_SQUMyCfXC6xt036d0v%3D5BcYwgzscs6sw%40mail.gmail.com.
