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

[Johnny Billquist]

On 2012-03-22 23.33, glen herrmannsfeldt wrote:
> Johnny Billquist<bqt at softjar.se>  wrote:
>
> (snip, I wrote)
>> 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.

Not likely. To actually use more than 22 bits of physical memory, the 
MMU would have to be redesigned in an incompatible way. It's just an 
"accident" of the fact, that you actually can go slightly above 22 bit 
addresses with the current solution. It won't go far above 22 bits. 
About 8K beyond 22 bits actually.

> (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.

:-)
Stack, on most machines, aren't really allocated until actually used.
(Well, apart from some small fragments)

> (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.

I'd say that the correct expression would be that web browsers don't 
make especially good use of memory.
They are not aware of the virtualness of it. That is what the OS deals with.
But they seem to allocate more than they free, suggesting that they 
actually leak memory. And they references scattered data all over the 
place, given time, making it rather sluggish eventually.
But web broswers are heavily using threads, and I suspect part of the 
reson for the observed memory usage is in fact because of leaking 
threads, which is even worse than leaking memory.

> (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.

That was when you no longer were required to have swap configured in the 
kernel.
Probably one of the driving reasons to change the design, and lift that 
restriction. Since, after all, when you boot diskless, you have to be 
able to run programs before you even have any swap.

> (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.

That helps. But it will still not allow you to grab all physical memory 
for your one process. There are more processes running, who also wants 
to have resources. Not to mention the fact that the OS itself grabs a 
bunch of memory for its own use.

> 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.)

Nice. Isn't it fun with bugs in the OS?

	Johnny