399:
needed for another purpose, the kernel uploads it (again, no fault). The only differences there are 1) it's read from or written to the "swap area" (swap partition or swap file/page file/whatever your OS calls it), 2) it's not written back unless the page frame is needed for another purpose, and 3) the pages, being anonymous, don't serve as entries in a cache. So "accessing a memory-mapped file does not necessarily lead to a page fault" is not a point of distinction between "virtual memory" in the sense of "anonymous pages don't all have to be in physical memory" and memory-mapped files.
290:
that if any of the addresses in that address space are backed by physical memory, all are - i.e., a system where all code and data is in physical memory at all times, or where an entity given its own address space is either entirely in physical memory or entirely out of physical memory, i.e. swapped in or swapped out, at any given time). There is no requirement that each process, if the OS even has a notion of processes, have a separate virtual address space, as the current second paragraph of
368:. I insist only that they are distinct. Accessing a memory-mapped file not necessarily leads to a page fault. On reading the file, an entire page may be already downloaded. On writing to an already downloaded page, the page is just marked as altered (no fault). Then, after a suitable amount of time, the kernel uploads it (again, no fault). Then, the page is not necessarily discarded but may remain in the RAM as a file cache. It is not exactly the same way as the
74:
53:
22:
420:
says, in the introductory paragraph, "In computer operating systems, paging is one of the memory-management schemes by which a computer can store and retrieve data from secondary storage for use in main memory. In the paging memory-management scheme, the operating system retrieves data from secondary
398:
Accessing, for example, the stack or heap does not necessarily lead to a page fault, either. On reading from the stack or heap, an entire page may be downloaded. On writing to an already downloaded page, the page is just marked as altered (no fault). Then, if the page frame containing that page is
275:
There's the concept of those some or all of those "not-physical" addresses not necessarily being mapped to physical addresses, with attempts by the machine to refer to them trapping to code that would, for example, load data from backing store into main memory and changing the map so that the address
935:
the pagefile implies that there is a specific relationship between pages of v.a.s. and page locations in the pagefile that's set up when the region is created, but that's not the case. Such relationships are only established if and when things have to be written to the pagefile. In addition, you get
647:
The example is too NT-oriented, and should probably be rewritten to discuss the general concepts of anonymous pages and file-mapped pages either without referring to the NT specifics or with references to specifics from other OSes as well. The "on 32-bit MS Windows" and "on 64-bit MS Windows" stuff
744:
provide such a mapping if a reference is made to the address")? In the former case, the address space, for most if not all non-segmented systems, would include address 0, and would consist of a small number of regions (typically 1 or 2, e.g. 2 in x86-64 with current implementations); in the latter
537:
You persuaded that there is no essential difference (probably, I distinguished "virtual memory" from "paging" insufficiently). But a redirect from VAS to the "virtual memory" article can be a bit confusing: a VAS has not necessarily to contain any "virtual" (i.e. not yet mapped to physical) memory.
289:
There's the notion of the range of not-physical addresses to which instructions, on a machine with some form of address mapping, can refer. On a machine with virtual memory, that would be called the virtual address space; I'm not sure what it would be called on a machine without virtual memory (so
926:
You are correct. You don't need a pagefile to use v.a.s. that isn't mapped to exes or dlls or etc. And the notion that (in
Windows terms) VirtualAlloc'd v.a.s. is "mapped to the pagefile" is incorrect. (There is such a thing as a "pagefile-backed section", but still, it isn't really "mapped to the
522:
4GB into the address space if pointers are 32 bits, which might be considered another difference, but, in both cases, the addresses backed by "swap space" or by a file are "virtual" in that there's no guarantee that they're in memory and a fetch from or store into the region might result in a page
340:
There's the notion of memory-mapped files, which are generally implemented by assigning a section of the virtual address space to a region of a file and arranging that page faults in that region fetch backing store from the file and, optionally, arranging that dirty pages in that region be written
868:
is not an OS concept. Virtual addressing is implemented in hardware. As far as I know, virtual addresses have never been implemented in software, except perhaps as a research project. The OS relies on the processor to supply the mechanism. In short, you can have a VAX without VMS, but not VMS
812:
have an address space smaller than the maximum amount of memory the CPU can address, or as you mention an address space can have holes. The hardware defines the maximum and the OS can further restrict it. Another question - is the concept of "address space" relevant to segmented systems such as
261:
There's the concept of instructions referring to addresses other than physical addresses. This could be used in a system that keeps all code and data in memory, without even swapping entire processes, much less swapping segments or paging. That's what, for example, "base and bounds" registers
349:
cases where a portion of the address space needn't be backed by physical memory and a reference to that portion of the address space causes a fault where the fault handler fetches the data from some form of backing store, which might be a memory-mapped file. I'm unaware of any consensus that
936:
a page fault the first time you touch both process-private and mapped virtual pages, just like you will if you touch a page that isn't defined yet. It's just that in the latter case the PF can't be resolved, whereas in the other two, it can be. That entire discussion needs to be rewritten.
876:
allocated by the OS, or the demand-paged memory services the OS provides. For example, on the i386 architecture the virtual address space is 2, but in ye olde
Windows no single process was ever allotted more than 2 because 2 GB was reserved for the OS.
968:
memory the machine can address. All four possible combinations of "/3GB switch on or off" and "4 GB chipset or not" are possible and efficacious; the location of the U/K boundary in virtual address space is not directly related to how much RAM you have.
600:
restricted to "modern" operating systems such as the ones listed (and I'm not sure what renders OpenVMS or UNIX or even
Windows NT "modern", as they date back to somewhere between the late 1970's and early-to-mid 1990's); they date back at least to
341:
back to the file. Whether that's distinct from "virtual memory" is a question of whether "virtual memory" refers only to what, in a system with paged virtual memory, are sometimes called "anonymous pages", i.e. pages
512:
includes files in disk storage as well as "swap space". In most OSes that support memory-mapped files, explicit calls must be made to map regions of files into the address space (but I don't think that's the case in
752:
Or, to put it another way, in the diagram on the page, are the gray areas part of the virtual address space (in which case it's defined by the hardware) or not (in which case it's defined by the software)?
731:
768:
It seems to me that it's a combination. The architecture defines the maximum possible size and the software decides what to actually make available. "Would" or "does" is more appropriate.
634:
and the "licensed internal code" on which it runs; IBM i, at least, uses other mechanisms to isolate processes (as did, say, OS/VS2 SVS, which I think used the "storage key" mechanism).
446:
And a definition of "virtual memory" that includes both anonymous pages and pages from memory-mapped files would be one where the following sentences from the opening paragraph of the
649:
517:- I think every file has a region of the (single) address space permanently assigned to it), which might be considered a difference, and, in some systems, you can't necessarily map
880:
Every reference in this article referring to files and virtual memory should be removed. Some are completely wrong. (The best that can be said for the reference to malloc is
345:
backed by a memory-mapped file (such as, say, stack and "heap" pages) but, instead, backed by pages in "swap space" (swap partition, swap file/pagefile, whatever) or refers to
230:). Although on modern systems the virtual memory operates in the context of VAS, it has not necessarily to use it (cf. ancient "swapping" mechanism when a process was
183:
762:
901:
172:
The article could be merged with virtual memory, as its entire content barring the first sentence is about virtual memory, not specifically virtual address space.
583:, in the fashion of the first sentence of the opening paragraph, rather than used to refer to the range of not-physical addresses to which instructions can refer.
372:
usually operates, but it expands a usable VAS portion likewise. Could you offer a definition of virtual memory which entirely absorbs memory-mapped files?
927:
pagefile".) First, again, you don't need a pagefile at all to create private committed address space (or even pagefile-backed sections!). Such v.a.s. is
429:
to memory-mapped files - the pages in the file are retried from secondary storage (the file) for use in main memory, and are retrieved in units of pages.
132:
243:
990:
661:
852:
822:
795:
777:
685:
547:
532:
381:
359:
493:
to be designed as though there is only one kind of memory, "virtual" memory, which behaves like directly addressable read/write memory (RAM).
951:
978:
957:
945:
1034:
996:
122:
276:
range in question refers to the physical memory in question. That's what's generally considered "virtual memory", and is what the
162:
1029:
872:
The virtual address space is the range of addresses the processor is capable of addressing. It's not to be confused with the
840:
326:
187:
1015:
630:
provide "security through process isolation" but that do provide virtual memory and a global virtual address space, such as
179:
98:
704:
538:
Should "virtual address space" become a quasi-independent section with a definition of that kind of memory address space?
149:
911:
Even in the windows-specific example, I don't believe the references to the page file are required to make the point.
813:
Multics? Still another - are there any systems besides SVS that use a single shared address space for all processes?
313:. Each program thus appears to have sole access to the virtual memory. However, some older operating systems (such as
226:
mechanism to enhance the usable memory for a process. The most common and most famous one, but not the only one (cf.
920:
726:
960:, the /3GB switch and "4 GB chipsets" are not directly related to each other. The former controls the division in
1039:
964:
address space between user mode and kernel mode, per-process and system-wide. The latter has to do with how much
81:
58:
983:
198:
is the thing which gave a prominence to virtual address spaces, but these two are not more the same thing than
33:
786:
Yes, "by the hardware and the OS" is "a combination", so you're saying it's "by the hardware and the OS".
652:- if people want to know that level of detail about NT, they should look in Microsoft's documentation.
97:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
470:
21:
839:"are there any systems besides SVS that use a single shared address space for all processes?"
167:
158:. For example, it talks about 4GB address space. It could be different on other architectures.
94:
916:
818:
773:
700:
681:
543:
478:
474:
377:
239:
39:
736:
Is the virtual address space defined by the hardware (as in "all addresses for which the OS
579:
heard "virtual address space", without an "a" or a "the" in front of it, used to refer to a
848:
791:
758:
657:
528:
490:
482:
355:
175:
740:
a mapping") or by the hardware and the OS (as in "all addresses for which the OS actually
8:
1004:
714:
306:
897:
885:
227:
203:
912:
814:
769:
696:
677:
539:
373:
235:
219:
1012:
906:
844:
787:
754:
653:
524:
351:
263:
215:
329:
that run all processes in a single address space composed of virtualized memory.
722:
447:
291:
277:
211:
195:
1023:
974:
941:
893:
310:
199:
889:
486:
318:
234:
uploaded to the disk). Leave articles distinct, just specify what is what.
159:
521:
of a file into the address space, e.g. you can't map all of a file : -->
305:
Most modern operating systems that support virtual memory also run each
1008:
1003:
commonly use the binary prefixes (Gi, Mi, etc) for computer units, see
718:
650:
Knowledge is not a manual, guidebook, textbook, or scientific journal
90:
884:.) In its place should be a discussion of address translation. Cf.
970:
937:
86:
73:
52:
606:
602:
364:
I do not insist that "virtual memory" and "memory-mapped files"
417:
369:
314:
676:
Yes it is a mess. I fixed the lead, but more work is needed.
864:
The answer to the OS woulda-coulda question is: No. Virtual
631:
610:
514:
322:
732:
What is, and what isn't, part of the virtual address space?
155:
266:
page is referring to when it discusses memory addresses.
931:
the pagefile if you have one, but to say that it is
564:
The "virtual address space" page is a bit of a mess:
85:, a collaborative effort to improve the coverage of
154:This article has references that are specific to
1021:
252:OK, there are several concepts to discuss here.
749:include 0, and might include several regions.
206:. "Virtual address space" is one of (several)
695:Is there a consensus on the merge proposal?
350:"virtual memory" refers only to the former.
19:
956:Despite the edit comment that accompanied
709:So, um, shouldn't this proposal be on the
596:The concepts discussed on this page are
1022:
327:single address space operating systems
648:should probably be removed entirely;
952:Re the /3GB swtich and 4 GB chipsets
79:This article is within the scope of
15:
421:storage in same-size blocks called
38:It is of interest to the following
13:
262:provide, and is arguably what the
14:
1051:
1035:Mid-importance Computing articles
222:. "Virtual memory" is a specific
321:) and even modern ones (such as
72:
51:
20:
127:This article has been rated as
107:Knowledge:WikiProject Computing
1030:Start-Class Computing articles
745:case, for most OSes, it would
110:Template:WikiProject Computing
1:
705:22:01, 12 December 2014 (UTC)
101:and see a list of open tasks.
902:23:18, 30 October 2014 (UTC)
218:space" which is opposed to
7:
1016:09:52, 21 August 2017 (UTC)
999:: note that Knowledge does
921:07:31, 28 August 2013 (UTC)
853:19:52, 27 August 2013 (UTC)
823:19:07, 27 August 2013 (UTC)
796:16:29, 27 August 2013 (UTC)
778:15:39, 27 August 2013 (UTC)
763:18:03, 26 August 2013 (UTC)
686:02:04, 26 August 2013 (UTC)
662:20:10, 26 August 2012 (UTC)
548:19:12, 28 August 2012 (UTC)
533:09:12, 27 August 2012 (UTC)
382:07:17, 27 August 2012 (UTC)
360:20:10, 26 August 2012 (UTC)
244:12:43, 26 August 2012 (UTC)
150:Assumptions that need a fix
10:
1056:
626:There are systems that do
194:Certainly, the concept of
133:project's importance scale
979:17:26, 15 July 2016 (UTC)
946:18:00, 15 July 2016 (UTC)
888:and this discussion from
727:17:26, 20 July 2015 (UTC)
163:13:30, 24 July 2007 (UTC)
126:
67:
46:
188:06:18, 29 May 2008 (UTC)
1040:All Computing articles
984:Computer unit prefixes
886:this page from caldera
95:information technology
28:This article is rated
479:computer data storage
475:computer architecture
309:in its own dedicated
82:WikiProject Computing
483:random-access memory
477:'s various forms of
715:Talk:Virtual memory
210:implementations of
228:memory-mapped file
220:physical addresses
113:Computing articles
34:content assessment
1014:
869:without a VAX.
425:." That applies
204:space exploration
190:
178:comment added by
147:
146:
143:
142:
139:
138:
1047:
1011:
994:
212:memory addresses
173:
115:
114:
111:
108:
105:
76:
69:
68:
63:
55:
48:
47:
31:
25:
24:
16:
1055:
1054:
1050:
1049:
1048:
1046:
1045:
1044:
1020:
1019:
995:In response to
988:
986:
954:
909:
734:
469:This technique
366:never intersect
264:logical address
216:logical address
170:
152:
112:
109:
106:
103:
102:
61:
32:on Knowledge's
29:
12:
11:
5:
1053:
1043:
1042:
1037:
1032:
985:
982:
953:
950:
949:
948:
908:
905:
882:not even wrong
862:
861:
860:
859:
858:
857:
856:
855:
830:
829:
828:
827:
826:
825:
801:
800:
799:
798:
781:
780:
733:
730:
693:
692:
691:
690:
689:
688:
669:
668:
667:
666:
665:
664:
640:
639:
638:
637:
636:
635:
619:
618:
617:
616:
615:
614:
589:
588:
587:
586:
585:
584:
568:
567:
566:
565:
559:
558:
557:
556:
555:
554:
553:
552:
551:
550:
503:
502:
501:
500:
499:
498:
497:
496:
495:
494:
489:), allowing a
458:
457:
456:
455:
454:
453:
452:
451:
448:virtual memory
437:
436:
435:
434:
433:
432:
431:
430:
407:
406:
405:
404:
403:
402:
401:
400:
389:
388:
387:
386:
385:
384:
335:
334:
333:
332:
331:
330:
298:
297:
296:
295:
292:virtual memory
284:
283:
282:
281:
278:virtual memory
270:
269:
268:
267:
256:
255:
254:
253:
247:
246:
196:virtual memory
180:132.204.221.34
169:
168:Merge proposal
166:
151:
148:
145:
144:
141:
140:
137:
136:
129:Mid-importance
125:
119:
118:
116:
99:the discussion
77:
65:
64:
62:Mid‑importance
56:
44:
43:
37:
26:
9:
6:
4:
3:
2:
1052:
1041:
1038:
1036:
1033:
1031:
1028:
1027:
1025:
1018:
1017:
1013:
1010:
1006:
1002:
998:
992:
981:
980:
976:
972:
967:
963:
959:
947:
943:
939:
934:
930:
925:
924:
923:
922:
918:
914:
904:
903:
899:
895:
891:
887:
883:
878:
875:
874:process space
870:
867:
854:
850:
846:
842:
838:
837:
836:
835:
834:
833:
832:
831:
824:
820:
816:
811:
807:
806:
805:
804:
803:
802:
797:
793:
789:
785:
784:
783:
782:
779:
775:
771:
767:
766:
765:
764:
760:
756:
750:
748:
743:
739:
738:could provide
729:
728:
724:
720:
716:
712:
707:
706:
702:
698:
687:
683:
679:
675:
674:
673:
672:
671:
670:
663:
659:
655:
651:
646:
645:
644:
643:
642:
641:
633:
629:
625:
624:
623:
622:
621:
620:
612:
608:
604:
599:
595:
594:
593:
592:
591:
590:
582:
578:
574:
573:
572:
571:
570:
569:
563:
562:
561:
560:
549:
545:
541:
536:
535:
534:
530:
526:
520:
516:
511:
510:
509:
508:
507:
506:
505:
504:
492:
488:
484:
480:
476:
472:
468:
467:
466:
465:
464:
463:
462:
461:
460:
459:
449:
445:
444:
443:
442:
441:
440:
439:
438:
428:
424:
419:
415:
414:
413:
412:
411:
410:
409:
408:
397:
396:
395:
394:
393:
392:
391:
390:
383:
379:
375:
371:
367:
363:
362:
361:
357:
353:
348:
344:
339:
338:
337:
336:
328:
324:
320:
316:
312:
311:address space
308:
304:
303:
302:
301:
300:
299:
293:
288:
287:
286:
285:
279:
274:
273:
272:
271:
265:
260:
259:
258:
257:
251:
250:
249:
248:
245:
241:
237:
233:
229:
225:
221:
217:
214:, a case of "
213:
209:
205:
201:
200:rocket engine
197:
193:
192:
191:
189:
185:
181:
177:
165:
164:
161:
157:
134:
130:
124:
121:
120:
117:
100:
96:
92:
88:
84:
83:
78:
75:
71:
70:
66:
60:
57:
54:
50:
49:
45:
41:
35:
27:
23:
18:
17:
1005:WP:COMPUNITS
1000:
987:
965:
961:
955:
932:
928:
910:
890:bottom up cs
881:
879:
873:
871:
865:
863:
809:
751:
746:
741:
737:
735:
710:
708:
694:
627:
597:
580:
576:
518:
487:disk storage
426:
422:
416:The page on
365:
346:
342:
280:page covers.
231:
223:
207:
171:
153:
128:
80:
40:WikiProjects
958:this change
913:Peter Flass
815:Peter Flass
770:Peter Flass
713:talk page,
697:Peter Flass
678:Peter Flass
540:Incnis Mrsi
471:virtualizes
374:Incnis Mrsi
294:points out:
236:Incnis Mrsi
174:—Preceding
30:Start-class
1024:Categories
866:addressing
845:Guy Harris
788:Guy Harris
755:Guy Harris
654:Guy Harris
525:Guy Harris
352:Guy Harris
319:OS/VS2 SVS
997:this edit
933:mapped to
929:backed by
581:mechanism
481:(such as
104:Computing
91:computing
87:computers
59:Computing
991:Maggyero
966:physical
894:Jklowden
450:article:
232:entirely
224:OS-level
208:hardware
176:unsigned
962:virtual
907:Example
607:TSS/360
603:Multics
523:fault.
491:program
427:exactly
307:process
131:on the
711:target
418:paging
370:paging
325:) are
315:OS/VS1
160:Raanoo
93:, and
36:scale.
1009:intgr
1007:. --
810:could
742:would
632:IBM i
611:TENEX
577:never
575:I've
515:IBM i
423:pages
323:IBM i
975:talk
942:talk
917:talk
898:talk
849:talk
819:talk
808:You
792:talk
774:talk
759:talk
723:talk
719:SamB
701:talk
682:talk
658:talk
609:and
605:and
544:talk
529:talk
485:and
378:talk
356:talk
317:and
240:talk
202:and
184:talk
156:IA32
1001:not
971:Jeh
938:Jeh
841:Yes
747:not
717:? —
628:not
598:not
519:all
347:all
343:not
123:Mid
1026::
977:)
944:)
919:)
900:)
851:)
843:.
821:)
794:)
776:)
761:)
725:)
703:)
684:)
660:)
546:)
531:)
473:a
380:)
358:)
242:)
186:)
89:,
993::
989:@
973:(
940:(
915:(
896:(
892:.
847:(
817:(
790:(
772:(
757:(
721:(
699:(
680:(
656:(
613:.
542:(
527:(
376:(
354:(
238:(
182:(
135:.
42::
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
