Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Multiple JVM's - One Shared Library

 
Kent Garner
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Background:
I have a java process that makes JNI calls via a shared library (ie. libJNI.so ). This shared library provides wrapper calls into legacy code also stored in a shared library (ie libLegacy.so).

When I run multiple instance of this java process ( multiple JVM started ), the native code in the shared libraries appears to be isolated between the JVM's. I would expect the shared libraries to share memory space, however, global variables allocated within the shared libraries (in particular the libLegacy.so library) appear to be independant from one JVM to the next.

Question:
Does anyone know how the memory in the shared libraries are managed in regards to the multiple JVM's. Should I assume that each java process will have its own instance of the shared library and that it will be isolated from the other JVM's?

Thanks In Advance for your help.
-Kent
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 15715
73
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shared libraries are always "independent" for different processes that use the same library. The operating system loads the code of the shared library only once, but for each process that uses the library, there's a separate data segment in memory.

It works like this for all processes, not only for Java processes.

If the data in the shared library (global variables etc.) would be shared for all processes, you would get into trouble very quickly - the data of different programs on the computer would get mixed up.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jesper de Jong:
Shared libraries are always "independent" for different processes that use the same library.


Well... no, actually. That's generally the default, but it's not the only possibility. There's a specific compiler directive I remember from my distant past that tells LINK.EXE (Windows) to map specified data into a shared segment. If you do this in a DLL, that DLL's data is shared between processes. There may be a way to do this on some UNIX platforms, too.

Anyway, it would take some research, but you should be able to find out how to build the DLL so that the memory would be shared.

Whether this is a good idea, or rather would leave your software as a smoking ruin of despair, is a question I shall leave up to you.
 
Kent Garner
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for both of your responses. I would prefer that the memory space remain independant. The global variables reside in the legacy libraries and I was contemplating my options in regards to having to rewrite much of it.

I too have had some experience with windows DLL's in which global variables were shared between applications. That was a while ago. I was getting concerned that I maybe coding myself into a corner. I could not find anything that discussed my senerio exactly and I was looking for something definitive.

I my case, your answers have reinforced my test results. Although the global variables that I was working with all seemed to have the same address across each instance of the JVM, the contents of the variables remained different. Therefore, I would conclude that they indeed were actually stored in the respective data segment of each process; and the addresses were simply identical offsets into each data segment.

Thanks Again, Kent
 
When it is used for evil, then watch out! When it is used for good, then things are much nicer. Like this tiny ad:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!