how JVM works
Roedy Green
I have been away from low level coding too long to answer this
question.
The JVM is implemented as a DLL on Windows. This means if you are
running multiple instances of the JVM, only one copy of the read-only
code has to be in RAM. Each instance gets its own writeable heap.
But how does a modern CPU map the various DLLs into the address space
of a given instance? If they all map to the same slots in a common
address space of all programs, what stops a program that did not load
a DLL from using its code if it is visible in its address space?
Or do the DLLs map to different virtual addresses for each instance
each in their own segment? so that the instance can see only its own
DLLs?
--
Roedy Green Canadian Mind Products
http://mindprod.com
Doing what the user expects with respect to navigation is absurdly important for user satisfaction.
~ anonymous Google Android developer
Joshua Cranmer
> But how does a modern CPU map the various DLLs into the address space
> of a given instance? If they all map to the same slots in a common
> address space of all programs, what stops a program that did not load
> a DLL from using its code if it is visible in its address space?
The standard answer for shared libraries is that the read-only portions
of the library--i.e., .text, .rodata, etc. are loaded as read-only pages
in virtual memory, and each process that needs it has a pointer to this
page. Note that these pages are only created when they are loaded by the
DLL.
Looking at the PE format, it appears that it isn't PIC, although it also
appears that being non PIC messes up the page-sharing characteristics.
To make it short: the OS does magic at the virtual memory layer to make
it work. As far as a process can tell, each process has its own copy of
the DLL; the OS plays a lot of games to make sure that this lie is
believable.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Roedy Green
<Pidg...@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :
>
>The standard answer for shared libraries is that the read-only portions
>of the library--i.e., .text, .rodata, etc. are loaded as read-only pages
>in virtual memory, and each process that needs it has a pointer to this
>page. Note that these pages are only created when they are loaded by the
>DLL.
so every loaded DLL is visible to every process?? And appears at the
same virtual address to every process?
So DLLs are all public? Any process can examine the code of any
loaded DLL?
Roedy Green
<Pidg...@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :
>
>Looking at the PE format, it appears that it isn't PIC, although it also
>appears that being non PIC messes up the page-sharing characteristics.
PE = Portable Executable (actually Windows proprietary).
PIC = position independent code. Code that can be shifted around in
RAM and it still works without patching.
I long time ago I read about chip, perhaps it was the 432 Ada chip,
that had a scheme to force calls to go only to official entry points
in library code. As I recall the overhead was so heavy, the feature
was never used.
In the olden days the problem was handled by having the equivalent of
a DLL live in its own segment. It did not need to insert somewhere
into the flat virtual address space.
Joshua Cranmer
> On Wed, 13 Apr 2011 17:31:41 -0400, Joshua Cranmer
> <Pidg...@verizon.invalid> wrote, quoted or indirectly quoted someone
> who said :
>
>>
>> The standard answer for shared libraries is that the read-only portions
>> of the library--i.e., .text, .rodata, etc. are loaded as read-only pages
>> in virtual memory, and each process that needs it has a pointer to this
>> page. Note that these pages are only created when they are loaded by the
>> DLL.
>
> so every loaded DLL is visible to every process?? And appears at the
> same virtual address to every process?
No. Each process has its own virtual memory space. DLLs try to load to
the same virtual address, but can be shunted to other positions if
necessary. The OS kernel plays some games to try to share the virtual
memory taken up by a DLL between multiple processes if possible.
In essence, the low-level architecture that most program sees is, by and
large, a complete fabrication; the processor and the OS kernel play a
lot of tricks to make this fiction actually work. A process's model is
that it is the only thing that exists in memory, and it gets to use all
of the "memory" and other resources dedicated to it by itself. The OS
kernel and hardware conspire to make this work by having the kernel
provide tables to list what memory a process actually has access to,
which the hardware uses to map virtual memory onto real memory.
> So DLLs are all public? Any process can examine the code of any
> loaded DLL?
Hell no, that would be a security risk. A process only gets access to a
DLL if it loads it itself. Except if the DLL is loaded in memory, some
of that memory may be mapped to multiple processes at once.