Accessing outside the memory allocated by the program. (Accessing other app's memory)

The simple answer (less I'm mistaken), no. Generally it's not a good idea for 2 reasons. First is because it causes a trust problem between your program and other programs (not to mention us humans won't trust your application either). second is if you were able to access another applications memory and make a change without the application knowing about it, you will cause the application to crash (also viruses do this).

A garbage collector is called from a runtime. The runtime "owns" the memory space and allows other applications to "live" within that memory space. This is why the garbage collector can exist. You will have to create a runtime that the OS allocates memory to, have the runtime execute the application under it's authority and use the GC under it's authority as well. You will need to allow some instrumentation or API that allows the application developer to "request" memory from your runtime (not the OS) and your runtime have a way to not only response to such a request but also keep track of the memory space it's allocating to that application. You will probably need to have a framework (set of DLL's) that makes these calls available to the application (the developer would use them to form the request inside their application).

You have to be sure that your garbage collector does not remove memory other then the memory that is used by the application being executed, as you may have more then 1 application running within your runtime at the same time.

Hope this helps.

... true unless your run in in a runtime or CLR.

Phillip 2010-04-11 16:04:07

@Philip: even a runtime or CLR cannot access the address space of another process; at least not without help from the operating system. Only the operating system, in general, can map physical addresses belonging to another processes virtual address space into your process.

John Saunders 2010-04-11 16:14:48

Well I disagree with you here. While I can say that it does require a relationship between the runtime and the operating system, the runtime generally requests the memory space on behalf of the application. Because the runtime is the caller for the creation it still has ties to the memory space and can monitor and control it. (usually shared control with the application) But I would also believe this depends on the runtime itself. I've never dealt with runtimes that handle the way you explain but just because I've never seen them doesn't mean they don't exist.

Phillip 2010-04-19 00:15:42

@Philip: I don't believe that the fundamentals of virtual memory have changed since I learned them. If a physical address is not mapped into the virtual address space of a process, then it cannot be accessed by the process. A process cannot, in general, modify its own virtual address space. Only the OS can do that - not a runtime.

John Saunders 2010-04-19 00:28:11

I think I'm being misunderstood. Let me ask this, because maybe my understanding if incorrect. If a process has requested memory from the OS and the OS grants the process the memory it asked for, and that process turns around and starts another process which it is the parent of, does the child process allocate memory from the OS by itself, or does the parent process "give" the child memory from it's (parent) own address space that the OS already gave it. From what I understand a process can give a child process it's parenting memory from it's own pool. Am I wrong?

Phillip 2010-04-19 02:17:23

@Philip: It would depend on the OS. It also has nothing to do with "allocation", and everything to do with page maps. In the classic Unix-style fork and join, the child process would get copies of the parent processes address space. These would be "copy-on-write", so they would only be copies. As soon as they were written, the shared pages would be replaced by private copies of themselves.

John Saunders 2010-04-19 02:52:43

@Dani: in the case of a debugger, you'll find it's using OS assistance and high privilege to access the other address space.

John Saunders 2010-04-11 16:15:44

@John - Of course, you can't do it without these...

Dani 2010-04-11 16:50:21

In some cases the debugger is running through a host process. the host process spawns both the application and the debugger. Since the host owns the memory space it provides it to both the application and debugger as a shared space each able to manipulate the memory as it sees fit (again this requires a host process which means the application doesn't directly own the space)

Phillip 2010-04-19 00:18:23

ansaurus

tags:

views:

answers:

Accessing outside the memory allocated by the program. (Accessing other app's memory)

related questions