From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Persistance Problem Solved by Memory-Mapped Files?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 14:46:40 GMT

In article <1a9uh5INN4o4@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <d8_p1zq.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
>>I'm wondering whether the problem of persistant objects could be
>>solved by use of memory-mapped files to store the C++ data structures
>>used by C++ programs. Comments?
>
>Not really.  Memory-mapped files raise the problem of making object
>representation independent of the address space in which the object
>resides.  Pointers between objects have to be replaced with offsets from
>the base of the file.  

	You're making a hidden assumption here: you're perhaps too familar
with linear address machines. On the 386 one could map a file to
a segment. A pointer already consists of a selector for the segment (file)
and an offset into the segment (file). Such pointers would not have
to be 'replaced' since they already have the right form. The problem is
reduced to associating selectors with files consistently.

>Linkage to virtual member functions would have to be
>done differently; if the vtbl lives in the shared memory then the function
>pointers will have to be done in an process-independent manner, but if the
>vtbl lives in the per-process memory then the vptr will have to be
>process-independent.  You can't assume that functions will be in the same
>place in each process, since an object library may be linked into many
>different programs.

	Again you are making assumptions about the style of machine
you are used to. It would have to be done differently for UNIX, yes.
In lowly Windows, a form of code, the Dynamic Link Library (DLL)
is automatically shared. It is easy to imagine a system on the 386
where all code segments are shared and access via the Global
Descriptor Table (GDT) in which case the pointers into the
code are guarranteed to be the same for all processes.
Thus, perhaps on some systems, you *can* assume the functions
will be in the same place for each process.
>
>Also, memory-mapped files only work if all the cooperating processes share
>a file system that supports it.  I'm not sure how reliable writing to
>memory-mapped files is when NFS is in use (I don't think each write to the
>mapped memory results in an NFS write, so multiple copies of the file could
>get out of sync).

	Again, on the 386 this is trivia, since the VM system buffers the
files exposing the same PHYSICAL memory to all processes. 
(At least it could be so configured) There is
no way the pages can 'get out of sync', although naturally processes
sharing data segments must coordinate their access to critical
sections (with locking and so forth).
>

	The 386 provides advanced features which greatly simplify
operating system design. Perhaps at the expense of processor
speed. The principal hardware limitation is the number of
accessible segments per process (4K in the GDT and 4K in the LDT
from memory), and of course the VM page size (4K).

	The real limitation on this processor is the lack of
operating software designed to take advantage of the hardware facilities.
Segmentation has often been criticised. However the 8086 processor
did not really support segmented memory, merely a split addressing
scheme. The 286 supported segments, but the size limit of 64K
is unsuitable for large blocks of data (such as large documents),
or, more importantly, a large stack.

	The 386 has none of these limitations, imposing a segmentation
scheme onto a linear address space which is then virtualised. The
virtualisation and half the segmentation is mapped on a per
process basis. Interprocess calls are supported by call gates.

	The capabilities of this machine are underutilised
in even the new 386 operating systems. Both OS/2 and Windows NT
to the best of my knowledge are basically 'flat model' systems
to accommodate the linear architecture of non-segmented processors,
and also because few programming languages have any understanding
of segmentation (memory classes).

	Perhaps I am mistaken, but I thought the von Neumann machine
was dead. The 386 is an extension of the Harvard architecture
(two segments, one for code and one for data) into multiple
segments.

	Segmentation appears to me to offer advantages for
memory management over linear addressing schemes. For example
dynamic extension/compression of the stack, dynamic linkage of code,
shared code, interprocess shared memory, transparent global
heap compaction, etc.

	The 386 has all the traditional limitations of a linear
real memory system--but these limits occur at the segment table
level, one level higher than on a linear addressing system.
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------