This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

In D49913#1139036, @markj wrote:

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

I personally think that such library (which is fine with LA57) but the main process is not is too unlikely to exist. It needs to be too hermetic in the aspect of never leaking the memory addresses outside the internals of the library. The overall practice is to assume that there is only one allocator in the process, and whatever memory you have, it can be free()-ed. This is engraved even into C++ and Rust. Of course GC-ed runtime are not such, but C libraries loaded into them with FFI are.

I did not follow too closely (was off), but wouldn't it be more prudent to have la48 have priority over la57 when both flags are present? Two of the inline comments I added are changes needed if you choose so.

In D49913#1139212, @olce wrote:

I did not follow too closely (was off), but wouldn't it be more prudent to have la48 have priority over la57 when both flags are present? Two of the inline comments I added are changes needed if you choose so.

If both flags are present, it is more a user error than a useful configuration. I documented it only for completeness.

In D49913#1139253, @kib wrote:

If both flags are present, it is more a user error than a useful configuration.

Certainly. But shouldn't we be conservative on a user error?

In D49913#1139047, @kib wrote:

In D49913#1139036, @markj wrote:

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

I personally think that such library (which is fine with LA57) but the main process is not is too unlikely to exist. It needs to be too hermetic in the aspect of never leaking the memory addresses outside the internals of the library. The overall practice is to assume that there is only one allocator in the process, and whatever memory you have, it can be free()-ed. This is engraved even into C++ and Rust. Of course GC-ed runtime are not such, but C libraries loaded into them with FFI are.

What about a library which maps an NVDIMM and provides some block-addressed I/O interface to it? Such a module does not need to expose the mapping to any other components.

In D49913#1141075, @markj wrote:

In D49913#1139047, @kib wrote:

In D49913#1139036, @markj wrote:

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

I personally think that such library (which is fine with LA57) but the main process is not is too unlikely to exist. It needs to be too hermetic in the aspect of never leaking the memory addresses outside the internals of the library. The overall practice is to assume that there is only one allocator in the process, and whatever memory you have, it can be free()-ed. This is engraved even into C++ and Rust. Of course GC-ed runtime are not such, but C libraries loaded into them with FFI are.

What about a library which maps an NVDIMM and provides some block-addressed I/O interface to it? Such a module does not need to expose the mapping to any other components.

But also such module does not need LA57. NVDIMMs are quite modest in sizes, comparable with NVMe/SATA SSDs. LA57 is still about VA, and not physical memory.

The possible beneficiaries of LA57 are things like GC runtimes. I can list e.g. recent chrome changes that allocate 2Tb UVA for V8 objects, or directly JVM for huge processing. In all that cases I do not see the scenario with isolated module realistic.

In fact, the use of the canonical bits for tags should be considered bug, and so far I am aware of only two bugs: in jemalloc, and in go. Both do not fit into the module model.