3 ms·

One of the main legitimate use cases for this feature is managing how the compiler interprets the lifetimes of runtime objects that are explicitly paged to disk

One of the main legitimate use cases for this feature is managing how the compiler interprets the lifetimes of runtime objects that are explicitly paged to disk. Many code bases rely on undefined behavior where the compiler coincidentally produces the expected behavior, which usually works, but I have seen occasional bugs in the wild from when it doesn't. You can use std::launder to guarantee that the compiler correctly interprets the lifetime of objects with these properties.

kazinator 3y ago
> explicitly paged to disk Example would help. Most paging nowadays is implicit, transparent to the program. Are you talking about some old-school overlays or something? Multiple objects in mass storage are mapped to the same address in memory, multiplexed in the time domain?
- zamalek 3y ago
  > Example would help. Almost any database.
- jandrewrogers 3y ago
  Paging is not transparent in high-scale and high-performance databases when using direct I/O to disk. It is not possible to make it transparent on many larger servers even if you wanted to because the silicon does not support a large enough virtual address space. This is a pretty common design problem in databases, or anything with huge amounts of data and storage really. There were magic incantations that compilers informally respected to induce the correct behavior but it wasn’t always reliable and technically not a bug when it wasn’t. This provides an official and simple way to achieve the same effect without obscure magic.
  - loeg 3y ago
    Are high performance databases embedding non-POD C++ objects in explicitly paged memory?
    - jandrewrogers 3y ago
      Most of your runtime objects are expected to be pageable in databases designed to support very high storage density because it is necessary as a matter of robustness and persistability. Even single runtime metadata structures may not reasonably fit in RAM in some cases. There are constraints on these objects (e.g. no vtables) but they are typically not PODs. Even if they were PODs, changing the types and instances of types at a specific memory address without destroying the objects residing there can have side-effects. The compiler does not expect a live memory address to be overwritten with an arbitrary bucket of bits by a DMA operation. DMA doesn't respect lifetime and ownership models as understood by a compiler, so it is a bit of a Deus Ex Machina as far as the compiler is concerned and is assumed to never happen.
      - deleted 3y ago
        [deleted]
      - deleted 3y ago
        [deleted]
secondcoming 3y ago
'paged to disk' I assume you're not talking about virtual memory here, but serialisation to disk or the network
- jandrewrogers 3y ago
  Direct I/O from and to user space, no serialization. There are significant size and performance limits when using virtual memory to give objects a consistent address, hence why it is sometimes avoided.

kazinator 3y ago

> explicitly paged to disk Example would help. Most paging nowadays is implicit, transparent to the program. Are you talking about some old-school overlays or something? Multiple objects in mass storage are mapped to the same address in memory, multiplexed in the time domain?

zamalek 3y ago
> Example would help. Almost any database.
jandrewrogers 3y ago
Paging is not transparent in high-scale and high-performance databases when using direct I/O to disk. It is not possible to make it transparent on many larger servers even if you wanted to because the silicon does not support a large enough virtual address space. This is a pretty common design problem in databases, or anything with huge amounts of data and storage really. There were magic incantations that compilers informally respected to induce the correct behavior but it wasn’t always reliable and technically not a bug when it wasn’t. This provides an official and simple way to achieve the same effect without obscure magic.
- loeg 3y ago
  Are high performance databases embedding non-POD C++ objects in explicitly paged memory?
  - jandrewrogers 3y ago
    Most of your runtime objects are expected to be pageable in databases designed to support very high storage density because it is necessary as a matter of robustness and persistability. Even single runtime metadata structures may not reasonably fit in RAM in some cases. There are constraints on these objects (e.g. no vtables) but they are typically not PODs. Even if they were PODs, changing the types and instances of types at a specific memory address without destroying the objects residing there can have side-effects. The compiler does not expect a live memory address to be overwritten with an arbitrary bucket of bits by a DMA operation. DMA doesn't respect lifetime and ownership models as understood by a compiler, so it is a bit of a Deus Ex Machina as far as the compiler is concerned and is assumed to never happen.
    - deleted 3y ago
      [deleted]
    - deleted 3y ago
      [deleted]

secondcoming 3y ago

'paged to disk' I assume you're not talking about virtual memory here, but serialisation to disk or the network

jandrewrogers 3y ago
Direct I/O from and to user space, no serialization. There are significant size and performance limits when using virtual memory to give objects a consistent address, hence why it is sometimes avoided.