Date: Wed, 7 Mar 2007 15:18:44 -0500 From: Kurt Miller <lists@intricatesoftware.com> To: freebsd-java@freebsd.org Cc: "Arne H. Juul" <arnej@pvv.ntnu.no> Subject: Re: patch: fix and re-enable curthread hash lookup Message-ID: <200703071518.45121.lists@intricatesoftware.com> In-Reply-To: <Pine.LNX.4.62.0702222353520.12961@decibel.pvv.ntnu.no> References: <Pine.LNX.4.62.0702222353520.12961@decibel.pvv.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703071518.45121.lists>