One possible solution
Posted Dec 4, 2006 16:44 UTC (Mon) by bluefoxicy
In reply to: One possible solution
Parent article: Virtual Machines and Memory Protections
I've written a paper about this, but can't seem to solve the problem of deadlocks between native/JIT conflicts and mutexes; or ensure that I can properly track native code.
Picture that native code malloc()'s unmanaged memory; and managed code allocates managed memory. We know what memory managed code is accessing; so we can handle cache synchronization and memory address translation between the processes. Native code, of course, can't be tracked; we have to basically hold all memory in the process running the native code.
The problem comes when one thread locks a mutex, then enters JIT'd code (in the other process); and then a native code path locks the same mutex. The JIT'd code suddenly can't pull memory over (we're assuming native code may be altering any memory, managed or unmanaged); and the native code is waiting for a mutex that won't be open until the JIT'd code is run. These threads deadlock.
Possibly the socket/shm buffer/etc communication could be used, under the assumption that actual memory access timing isn't entirely important. Mutexes are checked/set in native code, so we'll be at the memory storage point; and when mutexes don't block stuff, there's no timing synchronization to worry about.
Oi! The answer's been in front of me the whole time! Your wording gave me the push I needed, thank you!!! :)
http://bluefox.kicks-ass.org/stuff/bluefox/misc/vm_twopro... is the draft copy of the paper, I'll amend it later with uncached remote memory access.
to post comments)