Is there any way we can access other JVM's Heap memory? Will this be possible if I know the memory reference/address?
views:
189answers:
5
+1
A:
The closest thing that meets your needs is probably a distributed object cache such as Coherence or Terracotta. With these technologies different JVM instances can share objects.
Adamski
2010-05-05 09:25:06
Yeah I heard about Coherence. In distributed programming duplicate objects(Contants or master data) are maintained accross the servers, Is Coherence used to over come this?
learner
2010-05-05 09:43:47
A:
No, that's completely impossible. If you want shared memory, use threads.
Michael Borgwardt
2010-05-05 09:25:45
@instantsetsuna: learner wants shared memory. Threads share memory. Running "different applications" within the same JVM works quite well using threads. Since the question provides no reason for wanting separate JVMs, using multiple threads within one JVM looks like the best solution by far.
Michael Borgwardt
2010-09-28 07:27:13
@Michael: learner asked "Is there any way we can access other JVM's Heap memory?" S/he wants to access *another JVM's* memory. So, correct me if I'm wrong, but I don't think using threads is the right answer.
instantsetsuna
2010-09-29 06:42:15
@instantsetsuna: You're wrong. If you want shared memory, using threads is the right answer. It *might* be that learner is in a situation where it's absolutely necessary to use separate JVMs, but it's far more likely that this is yet another example of someone having a goal X, making an underinformed decision that the first step towards X is Y and then asking how to get Y to work when it turns out to be problematic.
Michael Borgwardt
2010-09-29 08:17:16
A:
What you want to do sound impossible. If you want to access data of another java program and can't implement som interface in the program in question (such as some RMI interface,or somsocket) the closest thing I can come to think of is to go through a debugger or the JVMTI
The JVM TM Tool Interface (JVM TI) is a new native programming interface for use by tools. It provides both a way to inspect the state and to control the execution of applications running in the Java virtual machine (JVM). JVM applications running in the TI supports the full breadth of tools that need access to JVM state, including but not limited to: profiling, debugging, monitoring, thread analysis, and coverage analysis tools.
aioobe
2010-05-05 09:25:50
TI is really meant to be used by tools like JConsole. If your business logic depends on it, I'd say that's a major code smell.
Andrzej Doyle
2010-05-05 09:33:33
A:
Not directly, in the manner you seem to be implying. You would need to have the "other" JVM expose access to these objects via some kind of service like RMI/SOAP, or through distributed object methods like Terracotta, and then call the relevant service methods to obtain the object.
Even then, in the vast majority of cases you would end up with an object with the same value, but which was distinct (i.e. calling setFoo on your object would not change the corresponding object in the other JVM). If you want to do this, you would need to go with something like Terracotta which will handle the magic for you.
But as with a lot of these questions, if you want to do this you should probably rework your design. Different processes should be able to coordinate between themselves without requiring on mutating the exact same instances of an object... :-)
Andrzej Doyle
2010-05-05 09:26:29
A:
Is there any way we can access other JVM's Heap memory?
I imagine you are thinking of doing something like creating a shared memory segment and mapping it into the address space of two JVMs.
It won't work. You could use JNI to create and map the shared segment, but you won't be able to convince the two JVMs to use that memory as heap memory. And if you got past that hurdle, it would all go horribly wrong due to the respective JVM's memory allocators and garbage collectors interfering with each other.
Will this be possible if I know the memory reference/address?
That won't make any difference.
Stephen C
2010-05-05 09:35:19