This is different from the JVM stuff the OP mentioned...
Starting with Java 1.5, its JVM supports the concept of "shared memory", which has nothing to do with sharing data between related programs, such as parent/child.
What it does is that, when a JVM tries to load a module/class, Java will first check whether the same class/module has already been loaded by another JVM. If it is, instead of reload the class/module, the loaded one will be used/shared between JVM's.
| [reply] |
Wow. Yet another reason to completely avoid Java altogether. Just the security issues alone make this undesirable, let alone the synchronization, the memory dirtying, and the potential for deadlocking.
Yes, I understand that this is only supported for a certain set of modules, presumably ones that have been "vetted" by some authoritative group. All this means is that there's another entry to hack Java applications by replacing one of these libraries with a nefarious version. And, before you say "That can't happen", the people who designed Windows weren't stupid ...
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
| [reply] |
Just to notice, as I said in UPDATE2 of the main post, it does it only for some small set of core libraries.
| [reply] |
Yes, but this only works for children of the same parent.
When I say shared library, I mean the memory being shared by unrelated processes. For instance, perl script X uses A, perl script Y uses A, they run in different environments of the same machine (one in apache and the other in console, for instance), if A is shareable and script X run before, when script Y runs, A won't be loaded again.
| [reply] |