Hi Denis,

22 Dec 98, Denis Tonn of 1:153/908 wrote to Eddy Thilleman:

DT> Memory is virtualized in OS/2. 

Memory = virtual memory?

DT> This means that when you allocate memory, it does not always
DT> exist in RAM. Portions of it will, as the program is actively
DT> using that memory area, but unused (or infrequently used) will
DT> not be backed by RAM pages until it is needed.

As I understand now:
---------------------------------------------------------------------------
allocation = reservation of memory addresses
unused memory which is not used before is reserved but not really allocated
(=allocation from the program's point of view means virtual allocation)
memory which is in use or used before is allocated
---------------------------------------------------------------------------
is that correct?

DT> RAM is the portions of "memory" that are being actively used.

RAM = physical memory? RAM pages are portions of physical memory?

DT> The concepts of "address space" and "memory" are
interlinked.

Because "address space" can be anywhere in virtual memory?

DT> This will be different depending on the code that is running,
DT> the system address space, 

Could you please define the term "system address space"?

DT> a DLL with protected data (Warp 3 GA and OS/2 2.x only), 

What's "protected data"? Is protected data not possible in Warp
4? Isn't that used? If a DLL uses protected data, that DLL won't run in
Warp 4? 

DT> or an application (process name).

application code within an OS/2 .EXE file, not in a DLL?

DT> Each process in OS/2 effectively has a separate LDT and page
DT> tables. 

DT> There is a guaranteed minimum of 64MB of "private" address space

Why guaranteed? Is that 64MB an arbitrary amount of private address space?
Why "private" between quotes?

DT> Keeping the shared code/data at the same location in all
DT> processes means the same pointers (and loader fixups) can be
DT> used in all processes. 

So pointers to shared code/data don't have to be changed? So pointers to a
DLL don't have to be swapped when process switching occurs, keeping speed
as high as possible?

DT> Now, there is a concept of "instance data" allocated in the
DT> "shared address arena". 

That's clever! While the code in a DLL and its data structure is the same
for all processes, the actual data this DLL code produces may be different
for each process and thus this data is kept apart for each process in its
own piece of memory but occurs on the same address for each process.

DT> There is also an area of the "shared arena" that is not
DT> "tiled", thus allowing multiple small (16 bit only) DLL's to
DT> occupy the same RAM page. 

This is only useful for different 16-bit DLL's, this seems to have the same
function as for instance data in the shared arena: let process specific
(different) DLL code to occupy the same address. If this was the same DLL
code it would be shared across processes anyway whithout swapping this.

DT> The aaaa is an example of a common read only piece of code in
DT> the executable (same process name). 

I thought that one process name is linked to one PID, not an executable
file? What say above seems to imply that one process name is linked to one
executable file? Because I think that one process name can only be
exclusively linked to one PID or exclusively linked to one executable file
and not to one of each at the same time, one of them excludes the other?

DT> This is not controllable by the programmer, although the user
DT> can affect this. 

Why? This has to occur in runtime? How can a user affect this and why not
the programmer?

DT> Warp server SMP and the Aurora beta allow applications to
DT> "allocate" in the area above the 512MB limit 
DT> (up to a config.sys controlled limit of 3.0GB total). 

Why a config.sys controlled limit? Is there a system wide price to be paid
for allocating above the 512MB?

DT> specify that memory usable by 16:16 code be allocated in the
DT> region below the 512MB address line (the "compatability
DT> region") when it allocates it.

So pointers to memory below the 512MB can be converted from 32-bit to
16-bit format in exact the same way as in OS/2 v2, Warp 3 and 4?

DT> The memory above the 512MB line has a similar organization
DT> into "private" and "shared" regions as the
memory below the
DT> 512MB line.

A similar organization? That implies that the memory above the 512MB has a
slightly different organization than the memory below the 512MB?

DT>  Enough for now.. Ask away..

I seem to understand the rest. I've saved your two messages for future
reference. If I've more questions, I'll ask.

Cheers   -=Eddy=-  
 Email: eddy.thilleman{at}net.hcc.nl

...  * <- Tribble  ~ <- Very drunk Tribble
--- MBM v4.14