0
struct A { int i; };
...
A *p = (A*) (8); // or A *p = 0;
p->i = 5;    // Undefined Behavior according C/C++ standard

However, practically most of the system would crash (segmentation fault) for such code.

Does it mean that all such Architectures/Systems have a hidden check for pointer indirection (i.e. p->) to verify if it's accessing a wrong memory location ?

If yes, then it implies that even in perfectly working code we are paying the price for that extra check, correct ?

iammilind
  • 68,093
  • 33
  • 169
  • 336

5 Answers5

2

There are generally no extra hidden checks, this is just an effect of using virtual memory.

Some of the potential virtual addresses are just not mapped to physical memory, so translating things like 8 will likely fail.

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
2

Yes, you are paying the price for that extra check. It's not just for pointer indirection, but any memory access (other than, say, DMA). However, the cost of the check is very small.

  • While your process is running, the page table does not change very often. Parts of the page table will be cached in the translation lookaside buffer, accessing pages with entries in the buffer incur no additional penalty.

  • If your process accesses a page without a TLB entry, then the CPU must make an additional memory access to fetch the page table entry for that page. It will then be cached.

You can see the effect of this in action by writing a test program. Give your test program a big chunk of memory and start randomly reading and writing locations in memory. Use a command line parameter to change the size.

  • Above the L1 cache size, performance will drop due to L2 cache latency.
  • Above the L2 cache size, performance will drop to RAM latency.
  • Above the size of the memory addressed by the TLB, performance will drop due to TLB misses. (This might happen before or after you run out of L2 cache space, depending on a number of factors.)
  • Above the size of available RAM, performance will drop due to swapping.
  • Above the size of available swap space and RAM, the application will be terminated by the OS.

If your operating system allows "big pages", the TLB might be able to cover a very large address space indeed. Perhaps you can sabotage the OS by allocating 4k chunks from mmap, in which case the TLB misses might be felt with only a few megs of working set, depending on your processor.

However: The small performance drop must be weighed against the benefits of virtual memory, which are too numerous to list here.

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • It seems odd that your answer clearly is "no", yet you start with "yes". You are not paying for the extra validity check, it's needed to implement virtual memory. – David Schwartz Jan 14 '12 at 06:21
  • @DavidSchwartz: I consider the page permission check to be part of virtual memory, so yes, the check has a cost because virtual memory has a cost. You don't have to agree with that, but you don't have to argue about semantics. – Dietrich Epp Jan 14 '12 at 06:39
  • He asked if working code pays a cost for an *extra* validity check that causes invalid code to fault. It does not. The extra validity check has no cost because there is no extra validity check. The validity check is not implemented as an extra check but part of checks needed to make valid code work. It's not just a semantic issue, someone who doesn't read your answer closely and critically may wind up with an impression that's the opposite of the truth. – David Schwartz Jan 14 '12 at 06:41
  • @DavidSchwartz, this answer is nicely detailed (already +1 all the answers). The only difference with other answers is, Epp has considered the cost of *"check"* as part of validation, which is also not wrong – iammilind Jan 14 '12 at 06:47
  • @DavidSchwartz: In practice, eliminating the address check would require putting the processor in a mode where it uses physical addresses or creating a page table which does so. Both eliminate the costs associated with page tables (small, static page tables are essentially free). – Dietrich Epp Jan 14 '12 at 06:50
  • 1
    Your answer is detailed and excellent. However, for some bizarre reason, it starts with the word "yes" when the answer is "no". Even if not for the validity check, modern OSes would *still* use page tables because virtual memory has many, many other benefits. There is *no* cost to the "extra check" because the check comes free with virtual memory, which is used for other reasons. If you want to have your answer be confusing, so be it. – David Schwartz Jan 14 '12 at 06:52
1

No, not correct. Those exact same checks are absolutely needed on valid memory accesses for two reasons:

1) Otherwise, how would the system know what physical memory you were accessing and whether the page was already resident?

2) Otherwise, how would the operating system know which pages of physical memory to page out if physical memory became tight?

It's integrated into the entire virtual memory system and part of what makes modern computers perform so amazingly well. It's not any kind of separate check, it's part of the process that determines which page of physical memory the operation is accessing. It's part of what makes copy-on-write work. (The very same check detects when a copy is needed.)

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
1

A segmentation fault is an attempt to access memory that the CPU cannot physically address. It occurs when the hardware notifies an operating system about a memory access violation. So I think there is no extra check as such If an attempt to access the memory location fails the hardware notifies the OS which then then sends a signal to the process which caused the exception. By default, the process receiving the signal dumps core and terminates.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
1

First of all, you need to read and understand this: http://en.wikipedia.org/wiki/Virtual_memory#Page_tables

So what typically happens is, when a process attempts to dereference an invalid virtual memory location, the OS catches the page fault exception raised by the MMU (see link above) for the invalid virtual address (0x0, 0x8, whatever). The OS then looks up the address in its page table, doesn't find it, and issues a SIGSEGV signal (or similar) to the process which causes the process to crash.

The difference between a valid and invalid address is whether the OS has allocated a page for that address range. Most OSes are designed to never allocate the first page (the one starting at 0x0) so that NULL dereferences will always crash.

So what you're calling an "extra check" is really the same check that occurs for every single page fault, valid address or not -- it's just a matter of whether the page table lookup succeeds.

mcmcc
  • 822
  • 6
  • 12