Re: Java Memory question
blmblm@myrealbox.com wrote:
Lew wrote:
From the point of view of the application (JVM in this case) the presence of
virtual memory is transparent - it all just looks like RAM and the application
doesn't mess with where it is. By the time the application does access the
memory, it's been swapped into physical RAM, so the application is dealing
only with physical RAM.
But (to my way of thinking) somewhat indirectly, since the addresses
presented by the JVM to the hardware are virtual, no?
No. The addresses presented to the OS by the JVM are just addresses; only the
OS figures out if they're currently loaded from virtual memory or still need
to be.
What you're calling "virtual" memory is still physical - the application
accesses it via the actual electronic memory chips.
Eh. The contents of virtual memory live *somewhere* physical --
either in actual memory (RAM) or on disk (swap space).
They're in RAM by the time the program uses it.
[*] I started to write "happily", but the possible performance
consequences of using more virtual memory than can be held in
physical memory are -- not happy, are they? Possibly it doesn't
Sure they're happy. The consequence is that you get to run programs that
otherwise wouldn't fit into memory.
*PERFORMANCE* consequences. Have you ever used a system that was,
in operating-systems-textbook-speak, "thrashing"? I have, and ....
*Oh*. I really didn't do a good job of saying what I meant! :
What I should have written was not "using" but something along
the lines of "actively using", because what I had in mind was
something like what o/s textbooks call a "working set" (the parts
of a process's address space that are more or less in active
[*] use at a particular point in time). If the combined working
sets of all active [*] processes won't fit in physical memory,
then the result is -- not happy, from a performance point of view,
though everything may still run.
Oh, that's just a performance consideration due to swap thrashing, but has no
bearing on the fact that RAM access is still physical. The time is to put the
information into RAM for that access, and then swap it out for the next guy,
then back in, then out. What it's swapping into and out of is, gasp! -
PHYSICAL RAM!
[*] I'm not thinking of a better word to use here, though this is
admittedly vague. Maybe the idea comes across anyway?
happen much these days, but it hasn't been that many years since
I encountered such situations in the wild, so to speak.
It happens all the time, in fact right now at this very moment on the computer
you are using to read this.
Sure, but I hope only if you mean "using" in the broader sense rather
than "actively using" ....
The problem is when you use more virtual memory than you have secondary
storage to back it up.
Well, that's *a* problem, and I agree that in some sense it's
a worse one than thrashing, since it means you can't run the
desired combination of applications at all.
The whole *point* of virtual memory is to allocate
more memory than you have physically installed, otherwise there'd be no need
for it.
Sure .... I suspect we're arguing past each other here, or something,
as a result of my sloppy wording ("using" when I meant something more
restricted).
None of that matters. The fact is that memory is physical. All that swapping
or whatever you're discussing is waaaaay outside the ability of the
application (the JVM) to detect. All the application (the JVM) sees is
physical RAM. The OS takes care of putting stuff in that RAM in time for the
access.
It's all physical RAM to the application, the fact that milliseconds earlier
it might not have been there notwithstanding.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg