[Info-vax] OpenVMS I64 V8.1 "Evaluation Release"?

[glen herrmannsfeldt]

Johnny Billquist <bqt at softjar.se> wrote:

(snip, I wrote)
>> IA32 still has the segment selector system that was added with
>> the 80286. While there were many complaints about the size of 64K
>> segments, that isn't so much of a problem at 4GB. A task can
>> have up to 8192 segments, each up to 4GB.

> Yes. But the question is if the CPU forms a 45 bit address that it then 
> sends to the MMU. If it's just a 32-bit address, done by adding the 
> segment selector (16 bits) with a 32-bit offset, and then truncating 
> that to 32 bits, which is then fed to the address translator in the MMU, 
> then it don't matter that you have segments, and so on. That is what my 
> comment was about, and I don't know how the IA32 actually do, so I can't 
> say much more.

Yes, the 32 bit MMU makes it harder. I never completely understood PAE,
which is the system that was supposed to be used for addressing larger
physical memories. It should have been possible to use invalid bits
and update the MMU at interrupt routine speed, much faster than 
disk access speed. As far as I know, nobody ever tried that.

> As an example, only slightly related, the PDP-11 have an MMU that forms 
> a 22-bit address by taking the high 16 bits from the MMU PAR register, 
> and adding the low 13 bits of the virtual address. This means that you 
> can get a physical address that would seem to be larger than what can be 
> addresses by 22 bits. But it don't happen. The address is truncated to 
> 22 bits in the end anyway.

Plan ahead in case larger address buses come in the future.

(snip)
> Way more than 2 or 3 times. My typical example is a process with 
> multiple threads. Each thread needs its own stack. But how much space 
> would you want to allocate for the stack for each thread?

I remember for some time, running OS/2 2.0 and using the MS compilers
and linker that would allocate 4K to the stack. Realizing that it
was virtual, I tried some really large stacks, way more than even
the size of my swap disk. Eventually, I got one so big that it didn't
work, but some larger than the swap disk did work. 

(snip, I wrote)

>> If you do something, such as matrix inversion, that makes many
>> passes through a large array you quickly find that you can't
>> do it if it is bigger than physical memory.

> Right. But most people actually don't do this most of the time. 
> They do run a web browser, though...

As far as I know, web browsers don't make especially good use
of virtual memory. I sometimes use either a Win2K machine or a
Mac PPC/10.5.8 machine, both with 1GB real memory and plenty of
swap. The Mac is especially bad, and Firefox is worse than Safari,
in the use of memory. After not so long the Mac is swapping on
every link. I then exit, restart, and use the "reload previous session"
link to get back to where I was before. Somehow they keep too much
old stuff in memory, and not such that it can stay swapped out.

(snip)
> Unix used to always require swap. It was defined in the 
>configuration file for the kernel build, and was not optional.

Even if it was NFS mounted, as on diskless Suns.

(snip, I wrote)

>> With matrix operations, they tend to run sequentially through
>> blocks of memory. I once wrote a very large finite-state
>> automaton that pretty much went randomly through about 1GB of
>> memory. No hope at all to swap.

> it will be paging all the time. This is a classic in computer science, 
> as an easy way to grind a system down to almost a standstill, as it will 
> be paging all the time, and do very little work. But it will work, and 
> it will produce results (eventually).

Depending on the matrix size and MTBF of the disk drive...

(snip)

> And even more so on VMS, where quotas will stop you from ever getting 
> close to that amount of memory. You'll get your working set, and then 
> you'll page. Unix is a bit more "liberal", but it too will not give you 
> all that memory, ever...

Well, I have my own VMS machine, so I can set the quotas where I want.

Reminds me, though, of once trying to figure out how much virtual
memory was available by allocating it and counting. Then, on an HP-UX
machine, tried:

for(;;) malloc(1000);

which, after not so long, crashed the machine. 

(I am not sure of the exaxt number in the malloc, but at some point
the system couldn't allocate memory for some important use and 
just gave up. You aren't supposed to be able to crash unix running
as an ordinary (non-root) user, but sometimes.)

-- glen