Commits on Sep 12, 2021

1. Deadlock during rundown using interpreter. …

   Identified deadlock between finalizer thread and rundown enumerating
   all interpreter method. Since rundown will query for method name
   in callback when iterating interpreter methods, interp_jit_info_foreach,
   that might lead to additional loader activity. The hash map in
   interpreter keeping the methods is locked with default JIT memory manager,
   but since the callback might end up in mono_class_create_from_typedef
   that will take loader lock, we get the following lock order on that
   code path, memory manager->loader lock. Finalizer thread invokes
   OnThreadExiting using interpreter and that might end up with a reverse
   lock order, loader lock->memory manager on that code path, so these
   two have a potential to deadlock. This is not a problem under JIT
   or AOT since the JIT hash table is lock free therefore not causing
   any deadlocks due to lock order between memory manager and loader lock.
   
   Could be fixed by changing into a lock free hash table in interpreters
   for interp_code_hash might be to risky at this point. A more safe fix
   is to take a copy of the pointers while holding lock and then iterate
   using local copy (simple array of pointers). Since this method is
   only called during rundown, only when using interpreter, and only
   include the pointers (InterpMethod *) we use with the callback,
   it will have some temporary memory impact (allocating an array
   of pointers), but will mitigate the deadlock since we can safely
   call iterator callback without holding the lock. It will also
   improve interpreter performance in situations where we run session
   rundown, since lock will be held a much shorter amount of time.

   

   lateralusX committed Sep 12, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for fea15f4
   • Browse repository at this point

   Copy the full SHA

   fea15f4 View commit details

   Browse the repository at this point in the history