User: Password:
|
|
Subscribe / Log in / New account

One possible solution

One possible solution

Posted Dec 4, 2006 16:44 UTC (Mon) by bluefoxicy (guest, #25366)
In reply to: One possible solution by roc
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.


(Log in to post comments)


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds