From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 36715BDCB for ; Wed, 31 Aug 2005 14:26:53 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7VCQqVH016013 for ; Wed, 31 Aug 2005 14:26:52 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA32641 for ; Wed, 31 Aug 2005 14:26:52 +0200 (MET DST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7VCQpa5016740 for ; Wed, 31 Aug 2005 14:26:51 +0200 Received: by wproxy.gmail.com with SMTP id 68so101920wra for ; Wed, 31 Aug 2005 05:26:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ArsPCTsX2xY0KCAXX7EeclGmn9QnzJSDg3G5OaflFQ4ajWx8sln9h4GEZROY7IzjMyp8Gqa3qurWmbcVllLMnCPPzSZIC2eKgMEjEescRejKGABOcvoq9m27NM6lr2+3HdDLUgsfAqluK4uJUAeAHnDAIXWdL1nY130LP2+0nXg= Received: by 10.54.130.10 with SMTP id c10mr647150wrd; Wed, 31 Aug 2005 05:26:50 -0700 (PDT) Received: by 10.54.154.7 with HTTP; Wed, 31 Aug 2005 05:26:50 -0700 (PDT) Message-ID: <891bd339050831052665d380b2@mail.gmail.com> Date: Wed, 31 Aug 2005 08:26:50 -0400 From: Yaron Minsky Reply-To: yminsky@cs.cornell.edu To: Caml Mailing List Subject: Odd behavior with GC and Mutex.lock Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Miltered: at concorde with ID 4315A20C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4315A20B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 threads:01 synchronized:01 threads:01 minor:01 delayed:01 delayed:01 yaron:01 thread:02 thread:02 chunk:02 mutex:03 mutex:03 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.3 I've been running into some very odd behavior with the GC and Mutex.lock. We have an application where a bunch of threads are all pushing updates through a synchronized queue, so all of the threads are contending for a global lock. Under some rare circumstances, we've seen very odd GC delays coming up, and we're at a bit of a loss to explain them. =20 The basic situation is that when the system comes under unusually high GC load, we will sometimes see one of the threads take a long time (on the order of half a second) when it tries to acquire the lock. We instrumented the acquisition of the lock as follows: let pre_stat =3D Gc.quick_stat () in Mutex.lock mutex let post_stat =3D Gc.quick_stat () in The thread that gets delays shows hundreds or thousands of minor collections and 5-10 major collections between the calls to Gc.quick_stat (). What's also weird is that it's always the same thread that gets blocked, and other threads are not blocked during this period. They seem to be able to acquire and release the lock without problems. And the thread that does get delayed isn't even the one causing the unusual load (although the delayed thread does do a big chunk of allocation that is immediately unreachable right before it gets blocked). I can't come up with a reasonable explanation for how this might happen, and I'm hoping someone with a deeper understanding of the GC than I might be able to help. Yaron