in reply to Re: Shared libraries^Wmodules in Perl
in thread Shared libraries^Wmodules in Perl

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.

  • Comment on Re^2: Shared libraries^Wmodules in Perl

Replies are listed 'Best First'.
Re^3: Shared libraries^Wmodules in Perl
by dragonchild (Archbishop) on Sep 13, 2005 at 00:27 UTC
    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:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Wow. Yet another reason to completely avoid Java altogether.

      You are right there. I was running a java based tv guide program called "freeguide" and it took a whopping 276 megs of virtual memory. I'm working up a Tk version to replace it.


      I'm not really a human, but I play one on earth. flash japh
Re^3: Shared libraries^Wmodules in Perl
by ruoso (Curate) on Sep 12, 2005 at 20:57 UTC
    Just to notice, as I said in UPDATE2 of the main post, it does it only for some small set of core libraries.
    daniel