From owner-freebsd-java@FreeBSD.ORG Wed Mar 7 20:18:59 2007 Return-Path: X-Original-To: freebsd-java@freebsd.org Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 508C816A405 for ; Wed, 7 Mar 2007 20:18:59 +0000 (UTC) (envelope-from lists@intricatesoftware.com) Received: from mail1.intricatesoftware.com (static-64-115-215-92.isp.broadviewnet.net [64.115.215.92]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE1B13C4C4 for ; Wed, 7 Mar 2007 20:18:58 +0000 (UTC) (envelope-from lists@intricatesoftware.com) Received: from seraph.intricatesoftware.com (relay@localhost.intricatesoftware.com [IPv6:::1]) by mail1.intricatesoftware.com (8.13.8/8.13.4) with ESMTP id l27KIlpx027938; Wed, 7 Mar 2007 15:18:49 -0500 (EST) Received: from localhost.intricatesoftware.com (truk@localhost.intricatesoftware.com [127.0.0.1]) by seraph.intricatesoftware.com (8.14.0/8.14.0) with ESMTP id l27KIjob015470; Wed, 7 Mar 2007 15:18:45 -0500 (EST) From: Kurt Miller To: freebsd-java@freebsd.org Date: Wed, 7 Mar 2007 15:18:44 -0500 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703071518.45121.lists@intricatesoftware.com> X-SMTP-Vilter-Version: 1.3.4 X-SMTP-Vilter-Virus-Backend: clamd X-SMTP-Vilter-Status: clean X-SMTP-Vilter-clamd-Virus-Status: clean X-Spamd-Symbols: ALL_TRUSTED,SPF_HELO_PASS X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Score: -1.4 X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 X-Its-A-Nuisance: This is spam X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean Cc: "Arne H. Juul" Subject: Re: patch: fix and re-enable curthread hash lookup X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2007 20:18:59 -0000 On Thursday 22 February 2007 6:10:55 pm Arne H. Juul wrote: > I've analyzed the currently disabled code that implements a faster method > to find the current (Java) thread object by getting hold of the stack > pointer and doing a lookup in a hash table. This used to fail on thread > exit sometimes because the invalidation wasn't done properly; I've also > changed some of the parameters for the hash code and upped the size of the > hash table so it should be more optimal. > > Finally I've added a "near hit" feature that should make the lookup faster > when a thread is crossing back and forth over a stack page boundary; > earlier this would always trigger the slow path, but now it compares the > current stack pointer with the low and high stack boundaries and gets a > hit if the hash table entry still points at the right thread object. > > This patch is still experimental, so if people can take a look at it and > tell me about any problems they can spot that would be much appreciated. Hi Arne, I've been testing your patch. So far so good. Interestingly, OpenBSD tends to be more susceptible to the original race condition problem. Prior to disabling the fast case, I could not complete a build of the jdk without a crash due to the race. Typically the crash occurred with javah or CompileProperties. In an effort to test your patch thoroughly I first enabled the old fast case and confirmed I could reproduce the original problem. As before I couldn't complete a build without a crash. After applying your patch I was able to complete several builds without issues. Next I wrote a script that executed several javah and CompileProperties commands in a loop and let that run for about 12 hours. About 300K commands completed without issue. I repeated the above steps on OpenBSD/amd64 with the same results. For FreeBSD however, I can't get the old fast case to crash the jvm. I know the race can cause the jvm to crash on FreeBSD too, but only because I analyzed some javah crash reports posted to this list. I suppose my hardware doesn't generate the timing needed to trip over the race. Anyway, I'll apply the patch and run the javah/CompileProperties test but I suspect that will go fine too. -Kurt